As you've noticed, there are no rules to what makes a commit, but here is one
way of thinking about it:
Every time you make some kind of advance in the project, make a commit. That
advance could be the fixing of a bug. It could be the removal of a compile
warning. It could be fixing a typo. Do this as often as you can, and you'll
have a rich set of historical changes. In addition, having more commits
stacked up gives you more options when rolling back. Use commits for your own
convenience - don't worry about cherry-picking yet. If two changes have
absolutely nothing to do with each other, they shouldn't be part of the same
Once you reach some kind of significant milestone or decide to push, then
consider flattening some of those commits into one commit. At this point, it
makes more sense for your commits to be larger, so that one commit would
correspond to a complete bug fix for example. But don't combine multiple bug
fixes into one commit because of the cherry-pick reason you raised.
There is another reason, too: bisect. Imagine some time in the future when you
need to use git-bisect to find a commit when a bug first showed itself. At
that point, it would be really nice if every single commit built properly.
On Jan 25, 2010, at 9:54 PM, Luisgo wrote:
> Hi all,
> I've been using git for over a year now and have nothing but great
> things to say about it. But every once in a while I start thinking of
> my workflow and how to improve it along with my use of git and other
> things. A questions that I keep trying to answer is what a commit
> should be. I know what it is technically but in theory what should I
> commit? A feature? My daily changes? What if it's a change I haven't
> I read about, for example, cherry-picking commits and can't help
> thinking my commits are not really cherry-pickeable. I often commit
> partial changes and not "whole features". I do create branches per
> feature but you can't really cherry-pick a branch, can you? If one
> should commit only done features, what's the best practice to protect
> partial changes and not risk them by not committing them?
> I may be thinking too much. Sorry.
> How do you define a commit?
> You received this message because you are subscribed to the Google Groups
> "Git for human beings" group.
> To post to this group, send email to git-us...@googlegroups.com.
> To unsubscribe from this group, send email to
> For more options, visit this group at
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To post to this group, send email to git-us...@googlegroups.com.
To unsubscribe from this group, send email to
For more options, visit this group at