On Thu, 6 Jun 2013 22:49:24 -0700
PJ Weisberg <pjweisb...@gmail.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.
> 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.
But note that it's a normal Git practice to crunch a series of small
commits which introduce partial changes (and comprise non-working
states of a program) on a private feature branch, and then
"squash-merge" [*] them into a single pretty commit on an integration
branch which is to be published (i.e. pushed somewhere). You don't
*have to* take this route but some people prefer to do things this
way. One upside of this approach is relative ease of rolling back to
any committed state while you're exploring possible ways to implement a
feature by trial and error.
[*] Read up on the "--squash" option of the `git merge` command.
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 https://groups.google.com/groups/opt_out.