Menu
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:
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.
Now the process is repeated for the next release.
At the moment i can only think of these options:
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.
859
Maintenance or “hotfix” branches are used to quickly patch production releases. Hotfix branches are a lot like release branches and feature branches except they're based on main instead of develop . This is the only branch that should fork directly off of main .
The GitHub flow branching strategy is a relatively simple workflow that allows smaller teams, or web applications/products that don't require supporting multiple versions, to expedite their work. In GitHub flow, the main branch contains your production-ready code.
Git flow is a popular Git branching strategy aimed at simplifying release management, and was introduced by software developer Vincent Driessen in 2010. Fundamentally, Git flow involves isolating your work into different types of Git branches.
The release branch helps isolate the development of an upcoming version and the current release. The release branch's lifetime ends when a particular version of a project is released. Once this branch merges into the develop and main branches, it can be deleted.
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.
61
Perhaps this is also a solution for you? Have a look at my answer here: https://stackoverflow.com/a/26866992/1313037
26
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
