Git – Micro Commits and Workflow

Recently I moved my blog and some old posts about git got re-posted to Planet GNOME.   One in particular was where I was not sold on the micro commit model of git at the time (more than 3 years ago!).

I postulated that more detailed, longer commit messages are good for others to understand the changes you made in the future.   However with git you can easily write a more detailed message at a later date (by re-basing, altering commit, more details in the merge message, etc) before the code is pushed or submitted as a patch – and only if its really needed.  This means you don’t have to interrupt your local workflow which allows you to code fearlessly.  SVN and CVS made commits a heavy weight process that required more care which led me to be biased in this area at the time.

I do believe it is import to have a good model for your git workflow though, I’ve been trying a work flow publish by Vincent Driessen and while its a bit of overkill for an individual project, the steps are easy to remember and well defined.  Only thing I’m not sure of is if merging without fast forward will cause problems over time, but in the short term grouping commits and keeping that knowledge is useful.

This entry was posted in Development and tagged . Bookmark the permalink.

5 Responses to Git – Micro Commits and Workflow

  1. Jannis says:

    We’re using a somewhat similar workflow over at Xfce, based on our Release Model.

    It is a bit different than the one you linked here in that we only have one main branch for developing (so master = develop). It also doesn’t specify how features are merged (cherry-pick, rebase plus normal merge, merge using squash or whatever else there is). Personally, I think that squashing individual commits from a feature branch into a single commit is a bad idea because it sort of makes bisecting less useful (problems are typically easier to identify if commits are small).

    Something I found interesting when writing our release model document was how to solve the issue of synchronized releases (like we have with stable releases of Xfce and like GNOME has, too) where the releases of individual components are aligned. That’s why our release model puts the work flow of individual components into a bigger project’s context and incorporates concepts such as string/code freeze and early lifecycle support (ELS) branches.

    What the branching model you linked leaves out is that branches of projects developed in teams may as well be named after the person that work on them. So feature branches could be called “user/feature”. This can be very handy when dealing with permission control in a pseudo-distributed project with an official main repository and also helps identifying who is responsible.

    I generally like how distributed version control has generated new possibilities with regards to release management and has inspired people to rethink their work flows. Thanks for sharing this one. I’m going to read it again to see if there’s anything we at Xfce can benefit from.

  2. Matthew Barnes says:

    A habit that has worked well for me for long-running private feature branches is to split your commits by file or class or directory such that you have a fixed set of commits representing your progress on the feature. My workflow then consists of constantly refining this fixed set of commits by generating micro commits that preserve the partitioning I’ve chosen. I then append these micro commits to the fixed set of commits through interactive rebasing and “fixup” commands. Periodically I also rebase the feature branch against the main development branch to pick up new commits from other developers and resolve conflicts right away. Because I’m working with a fixed set of commits, usually split by file, conflict resolution is much easier. And finally if I hit a milestone and want to snapshot my progess in case I screw something up later, I create a new branch off my feature branch.

    git has really revolutionized the way I develop software.

  3. Pingback: Tweets that mention Git – Micro Commits and Workflow | JP Rosevear --

  4. vitriolix says:

    Nice thing about following Vincent Driessen’s model to the T like we do at work is that now you cam use Gitflow to wrap git in a much cleaner interface based off Vincent’s concepts:

  5. Pingback: Micro Commits |

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s