On Jun 6, 2013 9:59 PM, "Greg Chetcuti" <g...@chetcuti.com> wrote:
>
> 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 commits)
> - 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
commits)
> - Update and commit every single change, in every file (20 commits)
> etc.

If I understand correctly, you're making two logical changes, each of which
touches several files.  Then of course you'll want to make two commits.
Put them in one commit and you're unnecessarily tying together unrelated
things.  Break them up into ten or twenty commits and you have a bunch of
half-done changes that don't actually work and need to be combined with
other commits before they actually make sense.  By putting each change into
a single commit you have a piece of working software after every revision,
which makes it easier to bisect when diagnosing a bug, for example.

-- 
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 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


Reply via email to