3 simple steps to avoid recurring merge conflicts
Until recently I made my (otherwise joyful) developer life a lot harder than it needed to be, and no it’s not what you’re thinking, I haven’t run out of coffee. It’s much worse, and I’m sure others have come across this as well. Yes that’s right, recurring merge conflicts.
To be more precise, I’m talking about recurring merge conflicts caused by disparate changes to version files such as pom.xml or package.json
But where do these unintended merge conflicts come from you ask?
Well, if you maintain at least 2 major release versions of your code tree concurrently, version merge conflicts are easy to introduce.
Whenever a version is incremented in a downstream branch it can’t be merged with an upstream branch that has conflicting version updates.
3 simple steps to avoid future version conflicts
1. Lock the version string for major release branches
Stop updating the version string in the release branches and lock it deliberately. For release/1 and release/2 in the above example the version string could be <version>1.x</version and <version>2.x</version> respectively.
2. Update version and release using a ‘dead end’ version branch
Create release-only branches that will never get merged back into another branch. Increment the version string in this branch. Build the release artifact from this branch.
3. Propagate changes downstream with ease
Changes can now be propagated downstream from a ‘bugfix’ branch to ‘release/1’, further on to ‘release/2’, and all the way down to ‘main’. As version changes are not propagated, no version-based merge conflicts will appear.
Nobody likes merge conflicts, especially when they are caused by something that could easily be avoided. So take a moment to check on your team’s git-flow and pull requests, and see if there are any version string updates across multiple release and master branches. But before you do, remember;
- Lock the version string in active release branches
- Create one-way version release branches to set the version string and build the artifact
- Propagate changes downstream with ease across release branches.
