AutoMapper Git workflow – dealing with bugs/issues

Along with the switch of VCS to git came the ability to have much improved workflows that simply weren’t possible in CVCS like TFS or SVN.  The nice thing about Git over CVCS is that because of its power, I can choose the workflow I want to use depending on my situation.  Most, if not all of this comes from the fact that local branches are cheap, and the commit model of git.

A couple of the things I wanted to shoot for was a clean history and isolating work.  With OSS development, I’m juggling a lot of different threads at once.  Feature requests come in, bugs come in, new work is going on, pull requests come in, patch files/code detritus comes in, and I don’t want work on any one thing to conflict with the other.

And since work on each thing is very asynchronous in nature, I want to match my git workflow to the actual interaction workflow that I use in the real world.  But first, let’s look at how we can visualize our local repository.  That’s a huge step in dealing with different kinds of workflows.

Visualizing the repository

I prefer git extensions over gitk and git log –graph.  Gitk is a bit of a pain to deal with, and git log attempts to use all the ASCII powers of the interwebs to display a graph of commits.  For example, here’s the current AutoMapper commit graph (locally):

image

Note anything?  A clean, linear history.  I absolutely detest bizarre, convoluted histories, where I see a tangled web of commits.  I have a few different workflows, but all start with a basic rule:

Always branch before doing ANY work.

Because branches are so, so cheap in git, branches become THE way to create parallel workflows.

Bug Workflow

When I get an issue from CodePlex, twitter, the mailing list or anything, I want to create a workflow that allows me to try and reproduce the issue, but without messing up the mainline master branch.  Many times, I’ll have conversations back and forth with other folks over the course of days or weeks, as I try and fix an issue.  In those cases, that branch can potentially stick around for a long time and NEVER come back to the master branch.

So first things first: An issue comes in, so I create a branch:

git co –b “SomeIssue”

This builds the following picture in my local repo:

image

Remember, a branch is really just a lightweight, named pointer to a commit.  The “git checkout –b” means to create a branch and checkout that branch immediately.  “git checkout” is analogous to the “svn switch” command, except git branches are MUCH simpler than SVN branches.

Next, I make some commit locally to that branch, and usually do something like:

git add .

git commit –m “Some commit message”

This now produces the following picture:

image

At this point, I usually go two routes.  If I can fix the actual issue, then I’ll want to integrate my changes back to the master branch.  If I can’t reproduce it, need more information or whatever, I’ll just leave it alone.  The really cool thing is that it doesn’t matter.  At any time, I can checkout master, start a new branch and continue on.  Let’s see what it looks like if there are additional changes that happen on the master branch:

image

We now see that master is basically ahead of SomeIssue.  I might have other branches hanging around as well.

So let’s suppose I want to integrate the SomeIssue branch back to master.  Now, if there have been upstream changes and changes locally to master, I’ll want to do a “git pull –rebase”.  This is similar to an “svn update”, and “get latest” in TFS.  However, there aren’t any changes, so what I really want to do is a rebase, from the SomeIssue branch to the master branch:

git rebase master

This results in the following history now:

image

Rebase is different than merge in that it re-applies commits from one branch to another.  What I’ve done here is basically re-play the commits from the SomeIssue branch onto the master branch, so that there is a clean, linear history.

With that done, I’ll do the normal local build.  Finally, I’ll checkout master and rebase or merge, the result is the same (a fast-forward merge):

git checkout master

git rebase SomeIssue

And now my history looks like this:

image

Now that my branch is “done”, I’ll delete that branch:

git branch –d SomeIssue

And my history now shows SomeIssue is gone:

image

Because a branch is merely a lightweight pointer to a commit, it’s really no big deal to delete a branch, as the creation and deletion of branches does NOT affect the commits in any way.

Now that my branch is integrated into a clean timeline (without any merge commits), I can push master back to origin.

So that’s it, my basic bug workflow is:

  • (from master): git checkout –b “SomeIssue”
  • do work, git add and git commit –am “Some commit message”
  • git checkout master
  • git pull –rebase
  • git checkout SomeIssue
  • git rebase master
  • git checkout master
  • git rebase SomeIssue <- this is just a fast-forward merge at this point
  • git push origin master
  • git branch –d SomeIssue

This workflow gives me a couple big advantages.  First, I can work on bugs/issues that may never have a resolution, and that’s just fine.  In fact, in the original history shown at the top, you can see a couple of branches that went off and never came back.  They may never in the future either, and that’s okay.

Several times, I’ll be working on one bug, stop, and work on another.  The first bug might have failing tests/compilation, but all that work is on a branch so it doesn’t conflict with other parallel work.

And now that I have two bogus commits in my timeline, I’ll just do a “git reset –hard HEAD~2” and rewind time like nothing happened :)

For more information about how branches and rebase works, check out the free online Pro Git book:

http://progit.org/book

Related Articles:

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

About Jimmy Bogard

I'm a technical architect with Headspring in Austin, TX. I focus on DDD, distributed systems, and any other acronym-centric design/architecture/methodology. I created AutoMapper and am a co-author of the ASP.NET MVC in Action books.
This entry was posted in AutoMapper, git. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • http://MurrayOn.NET/ Mike Murray

    How well does a workflow like this work in Mercurial?

  • http://www.lostechies.com/members/bogardj/default.aspx bogardj

    @Mike

    I dunno, I haven’t used Hg for anything else than pulling code.

  • Pete Harlan

    Hi,

    Thanks for writing the article; I hadn’t seen gitextensions before and it looks really nice.

    In this sequence of commands:

    git checkout SomeIssue
    git rebase master
    git checkout master
    git rebase SomeIssue <- this is just a fast-forward merge at this point

    That last rebase should really be “git merge SomeIssue”.

    Although “git rebase X” does fast-forward the current branch to X if the current branch is an ancestor of X (as in your example), that is just an artifact of how rebase is implemented. Conceptually it doesn’t make sense to rebase onto a branch that you’re an ancestor of, and I think your example would be improved by using merge there instead of rebase.

    You might even want “git merge –ff-only SomeIssue”, because if the merge isn’t a fast-forward then something is wrong. (Since you just rebased SomeIssue onto master, a non-ff merge could mean someone else is working in the same repo at the same time.)