HN Explorer

Ask HN: How to commit properly when starting out a project?

4 points by m712 ↗ HN
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?

5 comments

[ 6.0 ms ] story [ 28.7 ms ] thread
forgotmypw1
start with readme. one commit per logical set of changes. just like later.
fasouto
I 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.
adamzapasnik
Imo 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.

caspg
A 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.

seanwilson
When 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.