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

caspg · on Feb 4, 2020

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 · on Feb 4, 2020

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.

adamzapasnik · on Feb 4, 2020

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.

fasouto · on Feb 4, 2020

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.

forgotmypw1 · on Feb 4, 2020

start with readme. one commit per logical set of changes. just like later.