Git merge strategy for maven project hotfix releases with multiple branches

Question

What is the best practice to deal with recurring merge conflicts that are caused by preparing maven releases in a git flow environment with multiple hotfix branches?

(See http://nvie.com/posts/a-successful-git-branching-model/)

In this case multiple hotfix branches are needed to maintain at least two revisions of the application. Fixes for oldstable are regularly merged into the newstable hotfix branch. Those merges between those release branches are causing the recurring merge conflicts that i'll try to explain below:

The pom.xml artifact version of each branch is unique.

Example:

master                  - <version>1.2.0</version> (Contains the latest release)
  \ 
  dev                   - <version>1.3.0-dev-SNAPSHOT</version> (Contains changes for the next release)
  |\
  | hotfix-oldstable    - <version>1.1.1-hotfix-SNAPSHOT</version> (Contains new hotfixes for the oldstable version)
  |   \ 
  |   release-oldstable - <version>1.1.1-SNAPSHOT</version> (Is used to prepare the release)
  \
   \
    hotfix-newstable    - <version>1.2.1-hotfix-SNAPSHOT</version> (Contains new hotfixes for the newstable version)
     \ 
      release-newstable - <version>1.2.1-SNAPSHOT</version> (Is used to prepare the release)

---

My current workflow works like this:

Prerelease merge:

1. Merge hotfix-oldstable in release-oldstable
2. Update the version in release-oldstable using the maven release plugin. This effectively changes the pom.xml artifact version.
3. Merge hotfix-newstable in release-newstable
4. Merge release-oldstable in release-newstable (Causes a conflict - described later on)
5. Update the version in release-newstable using the maven release plugin.

Stabilize release branches:

After that step both release branches need to be stabilized. This is an important step because makes it mandatory to merge the commits from oldstable to newstable since the newstable version is most likely also affected by the issues that were detected in the oldstable version. The merge from release-oldstable to release-newstable causes a conflict since the pom.xml was modified in both branches.

Of course this could be circumvented by using cherry-picks but i am searching for an alternativ solution.

Perform release:

1. Perform maven release in release-oldstable. This also changes the pom.xml.
2. Perform maven release in release-newstable. This also changes the pom.xml.

Post Release merge:

1. Merge release-oldstable into hotfix-oldstable
2. Update the version in hotfix-oldstable and add "hotfix" classifier to the version.
3. Merge release-newstable into dev, master and hotfix-newstable
4. Update the version in dev (Add "dev" classifier and raise version).
5. Update the version in hotfix-newstable and add "hotfix" classifier to the version.

Now the process is repeated for the next release.

Prerelease merge:

1. Merge hotfix-oldstable in release-oldstable (no conflict because release-oldstable was merged to hotfix-oldstable in the post release merge)
2. Update the version in release-oldstable using the maven release plugin. This effectively changes the pom.xml artifact version.
3. Merge hotfix-newstable in release-newstable (no conflict because release-newstable was merged to hotfix-newstable)
4. Merge release-oldstable in release-newstable This step causes a conflict because the pom.xml was changed in the pre release step and merged in the "stabilize release branches" step.
5. Update the version in release-newstable using the maven release plugin.

---

At the moment i can only think of these options:

• Use git cherry-pick -x in hotfix-newstable for each commit that is made in the hotfix-oldstable branch
• Use git rere (http://gitfu.wordpress.com/2008/04/20/git-rerere-rereremember-what-you-did-last-time/) (I haven't tried that. I'd love to hear from somebody how that worked out so far)
• Use a custom script to merge the conflicts in the pom.xml
• Change the way how to deal with maven versions between different branches.

---

Update:

I ended up choosing the last option. I added a pre-build script which updates the pom.xml versions for hotfix branch builds. The script just adds a classifier to the pom.xml version tags using the maven release plugin update-versions goal. This effectively prevents changes to pom.xml files in the hotfix branches and makes merging a lot easier.

Dishonor

Answer 1

Have you considered moving away from Git Flow? The project I work on used it when we first started using Git; however, it got to the point that it was getting in the way more than it was helping. The issue of using it to do hotfixes of previous releases is what finally caused us to decide to drop it once and for all. In retrospect, it was good decision and we should have done it sooner.

Today, we just do simple feature branches merged to master along with tags. We haven't had any problems and hofixes of previous releases is no longer such a pain.

Brucite

Could you please explain how you push your changes in the, let's say, develop branch into your master branch? Do you do this automatically in the release process? – Muzzle

When we stopped using GitFlow we stopped using develop. We only have master, short-lived feature and release branches, & tags. master is always the latest/greatest, releasable, code. New features are developed in feature branches. GitHub Pull Requests are used to review the changes; they are merged to master when they are ready. When it's time for a release, we create a release branch; master can continue progressing along while also providing stability for the release. When it's ready to release, we tag it & delete the branch. – Brucite

Answer 2

Perhaps this is also a solution for you? Have a look at my answer here: https://mcmap.net/q/579413/-git-merge-conflict-only-on-version-tag-in-pom-xml

Blackleg

Answer 3

I found another tool that allows handling of merge conflicts of versions in pom.xmls in a very clean way.

https://github.com/ralfth/pom-merge-driver

Dishonor