3 simple steps to avoid recurring merge conflicts

[#1]

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;

1. Lock the version string in active release branches

2. Create one-way version release branches to set the version string and build the artifact

3. Propagate changes downstream with ease across release branches.

---

Want to take your team to the next level? Visit our Atlassian apps here or Book a Product Demo

Happy Coding!
Sean Manwarring
Head of Marketing at Izymes

Izymes’ mission is to eliminate boring from work. We build apps that turbo-charge team velocity through contextual automation.

[Mikhail Kopylov]

It's not quite clear what do the grey "release/1.x" and "release/2.x" mean.

If these are branches, they are not mentioned in the article. Moreover, it's not clear the difference between "release/1" and "release/1.x" branches.

If these are commits, and they contain a version change, like "<version>1.2.1</version>", it will has to be resetted to "<version>1.x</version" back with a next commit, but such version resetting commits are not mentioned and missed in the screen.