I have a branch
feature/non-conflicting-change that I want to merge into
release/version_1.1 and its upstream,
We have automatic merges turned on, along with automatic branch deletion for merges from
If I know my branch will go cleanly into these two branches, it would be much more convenient to submit two pull requests from the same branch.
Currently, however, when the first one is merged the branch is deleted and the second pull request is auto-declined by Bitbucket (even if you push the branch again, you can't re-open it).
Would it be possible for auto-deletion to check to make sure the branch isn't involved in another open pull request before deletion? This should let the second pull request delete the branch when it is auto-merged.
I understand that you have a cascading merge enabled for your repository's branching model.
I don't quite understand how the first (feature) branch is relevant to the second PR that goes from release/x.y HEAD to develop. What is the reason Bitbucket gives you for declining the 2nd cascading PR?
It isn't cascading merge (that's diabled), it's workzone's auto-merge paired with automatic branch deletion.
We have auto-deletion turned on in workzone for merges from
feature/** branches. In this case, the user needs to merge their changes into both the
release/version_1.1 branch as well as the upstream
Most of the time the workflow would be to to the merge locally and submit two pull requests from two branches, however it may be the case that for a trivial change the merge could be done cleanly from the same branch to both target branches.
So this workflow is:
release/version_1.1- no conflicts
develop- no conflicts
The question is whether workzone could be fixed to skip branch deletion after pull request 1, since the branch is involved in another open pull request.
Does that make more sense?
Thanks - it makes sense. The current functionality mirrors bitbucket's core delete-source-after-merge feature. Core Bitbucket code does not check if there are other (than self) outgoing PR from a branch.
We've created a feature request for Workzone - please vote to help it getting prioritised.
Have you pondered adopting a branching model that is closer to the promoted so called 'git-flow'. If you were to branch feature/tinyFix off release/version_1.1 and let release/version_1.1 flow into develop then you can safely delete feature/tinyFix after the first merge.
We use git-flow but due to the nature of our release cycle release branches are very long-lived (they have a very long pre-release verification/bugfix cycle). That's more or less beyond our control. This results in a state where because develop is also undergoing active development, merges from release to develop are not trivial enough to automerge from release branches to develop, so we don't use that feature.
We actually got workzone to enforce this using pull requests. A "git admin" group must approve the PRs and we won't approve a PR for the release branch without an open PR for the merged develop branch.
Hey Atlassian community, I help lead engineering at Sentry, an open-source error-tracking and monitoring tool that integrates with Jira. We started using Jira Software Cloud internally last year, a...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs