When I am just starting out a new project, usually I work on multiple things at once, like (in a web project) the routes, authentication, database models, etc. etc. So usually during the first few days of a project I don't commit at all and just keep adding new code. The result is that when I do commit 5 days down the line it's just a single "Bring the project up-to-date" commit that just pushes everything at once. What is the best practice for committing when just starting out a project? What do you recommend?
Ask HN: How to commit properly when starting out a project?
1–6 of 6 posts
Re: Ask HN: How to commit properly when starting out a project?
#2start with readme. one commit per logical set of changes. just like later.
Re: Ask HN: How to commit properly when starting out a project?
#3I like to commit small parts of code separately, but to be honest when you are starting a project and you are working alone I don't think is that important.
Re: Ask HN: How to commit properly when starting out a project?
#4Imo focus on code instead of commit history. I almost run into the same trap myself couple of times. Code history and quality! at the beginning hardly matters. At the beginning you don't need to follow any process, because there is nothing to base that process on (no code).
Just ship the code, your time matters more than a few fancy commit messages.
Re: Ask HN: How to commit properly when starting out a project?
#5A few times, I did what you described. I was working and experimenting for couple of days and after I was satisfied I "brought project up-to-date". But this caused me headaches a few times. It's hard to revert certain changes, hard to understand what was going on a couple of days ago.
Right now, I wouldn't work for 5 days without a single commit. Those "best practices" were invented to address concrete problems.
My advice is not to worry about commit history when you are starting. But definitely try to commit as often as possible. Group changes in logical chunks. Try to use meaningful commit titles and messages.
Re: Ask HN: How to commit properly when starting out a project?
#6When starting from nothing, usually I commit broken code with blank messages to a develop branch, then squash all the commits into master with a better description latter.
Not committing anything and losing it all by accident because you're obsessing about micro-commits and a clean history that nobody is ever going to read is a much worse alternative.
Small commits and good descriptions become useful once you have some foundation that's not in a high state of flux and you need to track what change broke something. You don't need this at the draft stage.