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 [email protected]. > To unsubscribe from this group, send email to > [email protected]. > 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
