Hi Luisgo,

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

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.

Paul


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
> finished?
> 
> 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 
> git-users+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/git-users?hl=en.
> 

-- 
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 
git-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/git-users?hl=en.

Reply via email to