0

I am setting up my branching model for my repository in Atlassian Stash. I have enabled automatic merges so that any updates as a result of pull request to current releases are propagated to master and to future releases (if they exists).

NOTE: The release branches are identified with their prefix "release/" and future branches are identified with the number "1.0.x < 1.1.x < 2.0.x and so on.

I am referring to the Atlassian document to refer to the conditions under which the automatic merging occur https://confluence.atlassian.com/display/STASH032/Automatic+branch+merging. The document mentions that "The merge must go via a pull request"

Case 1: To test this scenario, I created a pull request from a custom fix branch (that was branched off release/1.0.x) to release/1.0.x. As expected, the pull request was merged to release/1.0.x and auto-merged to master and future release branches; viz. release/1.1.x and release/2.0.x.

Case 2: I also tested the other scenario, where in I updated the release branch release/1.0.x directly (a commit on the branch instead of a pull request). As expected, the commit was not auto-merged to master and future releases (which is the expected result)

Case 3: Now, If I branch out of release branch to create another branch and then perform a pull request (similar to Case 1), the commits from this pull request get propagated along with the Case 2 commits.

Is there a way to not have the commits in Case 2 not propagated at all?

Thanks!

Dexter
  • 1,621
  • 3
  • 18
  • 38
  • I don't understand why is the result of case 2 is expected. I would expect changes to release branches to be propagated regardless of whether these changes made with pull-request or without. – mekarthedev May 29 '18 at 11:23

1 Answers1

-1

Ex-Stash developer,

Is there a way to not have the commits in Case 2 not propagated at all?

I'm not sure about your wording. Do you mean "Is there a way to have the commits in Case 2 propagated"? In which the answer is currently "no". It's not that it's impossible, but currently that is how it's implemented and there isn't really a way to toggle/fix the behaviour. My advice is to raise a PR for each release change, regardless of how small/trivial it is. Especially when it comes to release branches having another set of eyeballs on a change can only be a good thing. Otherwise you'll need to create an issue in JIRA.

charleso
  • 1,816
  • 14
  • 12