
Ask HN: How to commit properly when starting out a project? - m712
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&#x27;t commit at all and just keep adding new code. The result is that when I do commit 5 days down the line it&#x27;s just a single &quot;Bring the project up-to-date&quot; commit that just pushes everything at once. What is the best practice for committing when just starting out a project? What do you recommend?
======
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.

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

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

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

