JPz'log Coin Coin and Plop da Plop

Making a stable release from a Subversion trunk… with Git

I must confess that the first time I tried Git I truly hated it. Really.

Now things have changed: Git has improved a lot in terms of usability and I have learned how to use it properly. I recently found a very nice use case for its "cherry-pick" command.

IzPack officially uses Subversion. Since Git provides bidirectional inter-operability with Subversion, I happen to use it a lot this way to get the best of both worlds.

A common practice in Subversion is to have the "trunk" as the "always in development" branch, and have separate branches for stable releases. This allows having maintenance releases while preparing future releases in the trunk. All you have to do is commit bug fixes to your "stable" branches and merge them back to the trunk. However for some reason we (IzPack developers) did not respect this policy, which led me to the conclusion that we would not be able to make a 4.2.1 release since everything (i.e., not just fixes!) went to the trunk.

Fortunately I had this idea to leverage Git and its non-linear history model to rebuild a stable branch on top of 4.2.0, so that we could prepare a 4.2.1 release (and even 4.2.2, who knows?) while 4.3.0 matures.

The big picture looks like this:

I maintain a public Git repository for IzPack on Github that I regularily synchronize with Subversion.

Once I got the Git commit that matched IzPack 4.2.0, I just had to create a branch using that commit number, which is something like:

git checkout -b 4.2 (hexa code)

The remaining of the process is fairly simple. I use the excellent GitX tool to browse the commits from the branch that matches the Subversion trunk (note that gitk is fine as well). I also have a browser next to me to review the JIRA issues and know if a given commit is a new feature, an enhancement or a bug fix.

When a commit matches a bug fix, I quote the commit number, and cherry-pick it:

git cherry-pick (hexa code)

In my case, the resulting "stable branch" that I have obtained has been pushed to Github.

Finally I would like to mention that... of course you can do that with Subversion, but in a much less friendly manner: do merges from your trunk back to your branch by picking the commits revision ranges. That's possible, but definitely exhausting (who said I loved trolls? )