git-svn work flow with Code Collaborator

I’m the default linux geek around here, and since I recently did some pre-publication review of a friend’s git book, I thought it was time to switch my at-work work flow over to git.  This step was taken with some trepidation due to the immaturity of various tools in the git ecosystem. For example our own product, a code review tool, has support for git, but not as much support as I would like.

Since our main repository is in Subversion, I had to use git-svn to interact with it (this intro was quite handy).  This post describes the work flow I came up with to make use of git-svn with Code Collaborator.

First off, I had to do the appropriate ‘git svn init‘ on my master branch to import the existing Subversion repository.  Since I plan on using this long-term I went ahead and pulled in all of history.  This took awhile, but since it is a one-time operation, that’s not a problem.

Once that was done, I was ready to work, so I branched off a topic branch (git checkout -b topic) to keep from sullying the master branch with work that might not be committed for some time.

I figured out what needed fixing in the code and then fixed it.  I went ahead and committed to git (git commit -am “topic description”) as I was going along to make sure I didn’t lose any work and could backtrack on some of my more experimental coding choices if need be. Once it was working and tested, it was time for a code review.

‘ccollab addgitdiffs new master‘ created a new review on our Code Collaborator server where my co-workers sternly criticized my Javadoc typos.  After fixing the typos and committing again, I submitted the new versions of the files to the code review (ccollab addgitdiffs #### topic^). 

By now my colleagues had gone on to other things, and I was able to do the same even as I waited on them, simply by making a new topic branch from the master (git checkout master ; git checkout -b topic2) where I could do work on a new code change. When I got to a stopping point in the new work, I went and checked the status of the code review and sure enough, this time my colleagues approved, giving me permission to commit those changes to the trunk.

First, though, I had to update to the latest version of the trunk by switching over to the master branch (git checkout master) and updating it to the latest from the Subversion repository (git svn fetch).  Then I could switch back to my topic branch (git checkout topic) and rebase it onto the updated master (git rebase master). 

Now I was ready to coalesce my code into one commit (git rebase -i and judicious s/pick/squash/) and then merge it onto the master branch ( git checkout master ; git merge topic ).  Once merged, I pushed it to the Subversion server ( git svn dcommit ) so that the rest of the team (and our continuous integration server) could pick it up.

Simple enough, right? I’m sure there are improvements to be made – I tend to stick to simple git commands that I know will work instead of the more complex versions that could probably combine several of the above steps. Further, there are some things that tooling could help with (including Code Collaborator), but overall it’s been pleasant to be able to switch what I’m working on more quickly than before (when dealing with multiple svn trees) and to track intermediate work on a single topic without worrying about ‘dirtying’ the main tree. I look forward to trying out the Eclipse git plugin and hopefully adding better git support to Code Collaborator.