What is the best practice for resolving recurring merge conflicts caused by preparing maven releases in a git thread environment with multiple patch branches?
(see http://nvie.com/posts/a-successful-git-branching-model/ )
In this case, several patch branches are needed to support at least two revisions of the application. Fixes for oldstable are regularly merged into the newstable hotfix branch. These merges between these release branches cause recurring merge conflicts, which I will try to explain below:
A unique version of the pom.xml artifact of each branch.
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 as follows:
Merge with preload:
- Combine hotfix-oldstable to release-oldstable
- Update the version in version-oldstable with the release maven plugin. This effectively changes the version of the pom.xml artifact.
- Combine hotfix-newstable in release-newstable
- Merging with version-oldstable in release-newstable (causes a conflict - described below)
- Update the version in release-newstable using the release maven plugin.
Unlock stabilization branches:
After this step, both release branches should be stabilized. This is an important step because it commits you to merge commits from oldstable to newstable, since the version of newstable is likely to also depend on problems found in the old version. Merging with release-oldstable in release-newstable causes a conflict because pom.xml has been changed in both branches.
Of course, this can be circumvented using cherry picks, but I'm looking for an alternative solution.
Run issue:
- Run the maven release in release-oldstable. This also modifies pom.xml.
- Run the maven release in release-newstable. This also modifies pom.xml.
Merger after release:
- Merge with version-oldstable in hotfix-oldstable
- Update the version in hotfix-oldstable and add the patch classifier to the version.
- Combine release-newstable in dev, master and hotfix-newstable
- Update the version in dev (add the classifier "dev" and raise the version).
- Update the version in hotfix-newstable and add the patch classifier to the version.
Now the process is repeated for the next version.
Merge with preload:
- Merge hotfix-oldstable into release-oldstable (no conflict since release-oldstable was merged with hotfix-oldstable in merge after release)
- Update the version in version-oldstable with the release maven plugin. This effectively changes the version of the pom.xml artifact.
- Combine patch-newstable into release-newstable (no conflict since release-newstable was merged with hotfix-newstable)
- Merge-oldstable into release-newstable This step causes a conflict because pom.xml was changed in the pre-release phase and merged in the "stabilize release" step.
- Update the version in release-newstable using the release maven plugin.
At the moment, I can only think of these options:
Update:
I decided to choose the last option. I added a pre-build script that updates the versions of pom.xml to build patch branches. The script simply adds the classifier to the pom.xml version tags, using the goal of updating the maven plugin version. This effectively prevents pom.xml files from being patched and makes merging easier.
source share