So, one thing I'm still a bit fuzzy on is the recommend granularity of 
commits, and I'm wondering if anyone can help me out.

For example, let's say we're adding a new feature to a software application 
that's going to require two small updates to the code on 10 pages, what 
would the recommended commit process be?

- Perform both updates on all 10 pages and commit everything all at once (1 
- Perform 'small update #1' on all 10 pages and then commit, then do the 
same for 'small update #2' (2 commits)
- Make both of the small updates to each page and then commit by page (10 
- Update and commit every single change, in every file (20 commits)

And yes, I know that the first two are bad practice, they're mostly here 
for comparison.

The last one is by far the most thorough, but is it overkill? It seems to 
me that if you commit every single change separately eventually you're 
going to be spending more time committing and explaining the commits than 
actual programming. Or is this just what you have to deal with if you want 
to do things properly?

And if that *is* the way to go, how do you tie the 20 updates together so 
that the log shows a logical start and end point for the feature addition 
as a whole?

I'm in the process of completely revamping my development process, and I 
would really like to get better at committing, so if anyone has any info 
that would help it would be greatly appreciated.

You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
For more options, visit

Reply via email to