In the last post, I discussed the actions of the developers on the project. In this post, I will talk about the other half of the story. After one of the developers finishes their task or topic branch and they email the integrator (me), I check my emails usually at the end of the day and start my integration process. The single integrator process is great because it provides a forced code review gate that slows the commits to the master branch and forces a level of quality control and provides a natural time for this. It works great with geographically dispersed teams and helps everyone be highly effective with their time coding and reviewing while maintaining the best flexibility.

Configuration

My configuration file looks like the following:

  [core]
    repositoryformatversion = 0
    filemode = true
    bare = false
    logallrefupdates = true
    ignorecase = true
  [remote "origin"]
    url = evin@my.ip.address.to.git:/var/git/application.git
    fetch = +refs/heads/*:refs/remotes/origin/*
  [remote "mike"]
    url = evin@ip.address.to.git:/var/git/application.git
    fetch = +refs/remotes/mike/*:refs/remotes/mike/*
  [remote "chris"]
    url = evin@ip.address.to.git:/var/git/application.git
    fetch = +refs/remotes/chris/*:refs/remotes/chris/*
  [remote "mo"]
    url = evin@ip.address.to.git:/var/git/application.git
    fetch = +refs/remotes/chris/*:refs/remotes/mo/*
  [branch "master"]
    remote = origin
    merge = refs/heads/master

As you can see, I have 3 developers that send me branches for review. Each of them have their own root branch that all their topic branches are attached.

Integrator Process

First, you do the following:

  git checkout master
  git pull origin master

This is to make sure you are on the most current master branch (this should always be the case). Now, look at each of the emails for the topic branch for each of the developers:

  git branch topic_branch
  git merge <username>/topic_branch
  git diff
or
  gitk

The reason for the local topic branch is that it makes a staging area for the merge to make sure the changes are good and wont break anything. This is where you would run the unit test and any integration tests that you have made or just do so manual testing. Always do the code review at this point. For new members of my team or developers that aren’t used to the technology or code base, I try to do this in person if possible. It really helps you understand peoples coding styles and creates an easy way to give good feedback.
If merge is okay and code acceptable, then do the following:

  git checkout master
  git merge topic_branch
  get branch -d topic_branch

NOTE: You use a the lowercase -d, this checks to make sure your merge has fully been incorporated in the HEAD. This is a good simple check that everything went as planned when you delete. If, on the other hand, the code is not acceptable and you want to reject the merge, you would do the following:

  git checkout master
  git branch -D topic_branch

NOTE: You use an uppercase -D in this case because that forces a delete of the branch regardless of the merge state. And don’t forget to follow up with an email or conversation on why the change was rejected in a detailed manner. After you have integrated all the topic branches from the various developers, you need to do one last thing:

  git push origin master

This allows all the other users to get the latest and greatest when they pull from the master repository in the morning or when you make your integrations. The very last thing that I do is because our project has a slave READ-ONLY Subversion repository that is a part of a wider integration build process. I wrote a simple Ruby script called Git2svn that slaves the svn repository to the current master branch in git. I have open sourced the script on Github. You can check it out here.