stash cascade merge propagates release branch pom.xml updates to 'develop'

[Ulrich Kuhnhardt [Comalatech]]

When stash automatic merge is turned on version changes to pom.xml in release/X.Y_REL are merged to 'develop'.

1. How can I avoid version changes to be propagated to develop?
2. It can cause a merge conflict if other feature branches off 'develop' have been merged back to develop in the same time span.

We really like the automatic merge feature - how's everyone dealing with this scenario? What's best practice here?

Thanks a lot. 

[Bryan Turner]

Ulrich,

When we create our release branches and update the version in pom.xml, we manually merge that up and discard the changes (we use git merge -s ours for that). Once that merge has been done once, all subsequent changes should automatic merge without reapplying the version change. We use a script to cut our releases in part to automate the process of doing that merge and discarding the changes. When cutting point releases (say, 3.7.1), we do that on a separate "release-3.7.1" branch (not "release/3.7.1", so the branch is not picked up as a "Release" branch by the branch model) so that we can do the same merge-discarding-changes back to the "release/3.7" branch (and then onto "release/3.8" and "master"). All of those merges are done manually, not using Stash.

Hope this helps,
Bryan Turner
Atlassian Stash

[Andrew Evans]

For our use case with small teams we find it easiest to briefly allow an exemption on PRs and switching off auto-merge when we create the branch and then commit the POM updates directly. This means we continue getting the auto-merge capabilities on the new patch branch.

[Stefan Saasen]

Bryan explained how we deal with this below. For a little bit of background, I've wrote about it a while ago, see "Merge strategies" on http://blogs.atlassian.com/2013/11/the-essence-of-branch-based-workflows/

[Gordon Waddell]

Not an answer but I think this duplicates my question here: 

https://answers.atlassian.com/questions/13418077