Improving the git workflow

[Alexander Larsson <alexl redhat com>]

Now that we're all using git and hopefully most developer has started to
get a feel for it I'd like us to move to a more git-like development
model. For instance, it would be nice if we to a larger degree used
micro commits and patch series with clean histories. Local topic
branches and interactive rebases are a great way to achieve this, and
git-bz[1] is a great way to interect with bugzilla in this fashion.

For people not used to git or how e.g. the kernel community uses it let
me describe these things a bit.

Implementing a feature often required multiple changes that are in
themselves independent. For example, its not uncommon that a feature
consists of these changes:
* Move existing static function higher up so we can call it
* Extend an existing function by adding a new parameter to it
* Use the new parameter in one place to implement the new feature

Historically these would all end up in one patch in cvs/svn, but with
the cheap local commits and powerful features of git it would be better
if this consisted of three commits, first one that just moves code, then
we add the new parameter and pass in the default value for it
everywhere, then another commit that uses the new parameter to implement
the feature.

Advantages of this is: 
* Easier to review
* Nicer, easier to understand version history
* using git bisect gives you more fine-grained information

These kinds of commits leads naturally to the concept of patch series.
Instead of one single patch implementing a new feature you use
micro-commits as above and when done you use git format-patch to
generate a series of patches for review/commit (automatically keeping
author info and commit logs).

In order to easily handle something like this topic branches are often
used. A topic branch is a small, local only branch that contains only
the commits related to a small feature. You can then use this branch to
generate a patch series for review and/or commit, via e.g. git-bz (or
git format-patch). Since the branch is local the developer is free to
rebase it to e.g. rewrite history or move to a later base for the branch
without affecting any other checkout. 

History rewriting is interesting here. We can use git while developing a
feature and fix up things based on patch review, but at the end still
get a clean history. For instance, if one patch in a series has a bug
that gets caught in the review, then its pretty easy to commit a fix for
it and then use interactive rebasing of the topic branch (git rebase -i
origin) to squash the new commit into the commit that introduced the
bug, thus never showing this bug to the world in the final merged
history.

If you want to submit such a patch series for review, then git-bz is an
excellent way to manage patch attachements, both from the side that
attaches the patches and the side that commits them to git. I'd
recommend everyone to play with this a bit.


[1]
http://blog.fishsoup.net/2008/11/16/git-bz-bugzilla-subcommand-for-git/