JGit-Flow and parallel hotfixes
When we started with Git and Git Flow at OMS, we adopted JGit-Flow originally developed by Atlassian for our Java/Maven projects (I later started maintaining a fork of JGit-Flow, but that is another story). JGit-Flow fixes all the cumbersome red tape of bumping versions in pom.xml, in addition to branching, merging and tagging final releases as the regular Git extension.
However, as we moved into production with our brand new project, we hit our heads in a brick wall that JGit-Flow does not support; we found ourselves in a situation where we had a bug in production that needed to be hotfixed. Some developer might start a hotfix with mvn jgitflow:hotfix-start and commit a partial fix, but before she could finish, a more serious bug is discovered. But alas — JGit-Flow prohibits starting a new hotfix branch when another already exists:
$ mvn jgitflow:hotfix-start[...]What is the hotfix version for "example"? (com.manamind.jgitflow.example:example) [1.0.1]: 1.0.1-more-urgent[...][ERROR] Failed to execute goal com.manamind.jgitflow:jgitflow-maven-plugin:1.0.0:hotfix-start (default-cli) on project example: Error starting hotfix: Error starting hotfix: a hotfix branch [refs/heads/hotfix/1.0.1] already exists. Finish that first!
We face two problems here:
- The hotfix version is determined when the hotfix is started, not when it is finished
- We are only allowed to have one open hotfix at a time
Our initial solution to this limitation is what we named “the masterfix solution”. When starting on what is supposed to end up as a hotfix, we branch off master into a branch that we call masterfix/<issue> using regular git branches, for example git branch -b masterfix/ISSUE-1
When the fix is ready for deployment, the developer opens a hotfix branch, and merges the masterfix into the hotfix. The hotfix may now be built as a Maven snapshot on the build server, uploaded to the Maven repository and deployed to a test environment. If the snapshot build is OK then the hotfix is finished and the developer can return to fix the first fix she already had started on.
If several masterfixes are ready at the same time, for example when the developer’s nice colleagues also fixed some issues, then they may be bundled into the same hotfix. However you should be careful when creating hotfixes — they should contain as few changes as possible.
There is a drawback to the masterfix model, however. Since we’re not using JGit-Flow for masterfixes, the Maven version in pom.xml is not bumped to a -SNAPSHOT release, and we cannot upload the fix in progress to the remote Maven repository. This is because it currently contains the final release number that is currently on the master branch.
A better solution for parallel hotfixes would be to set a temporary version in pom.xml when the hotfix branch is created and then determine the actual version when finishing the hotfix. At this point you should ask yourself: Haven’t I seen something similar to this? Yes, you have. The scenarios is exactly as named feature branches start out in JGit-Flow:
Currently, when finishing a hotfix branch, the fix is merged (via master) to develop and — if it exists — the release branch (which is use to stabilize the next regular release). If there are any other hotfix branches the fix must be merged to those as well.
Hopefully we can find the time to implement better support for concurrent hotfix branches into JGit-Flow. Feel free to contribute a solution if like. See this page for more information.
