Could you prevent auto-deletion of a branch involved in (another) open pull request?

[Dakota Hawkins]

Scenario:

I have a branch feature/non-conflicting-change that I want to merge into release/version_1.1 and its upstream, develop.

We have automatic merges turned on, along with automatic branch deletion for merges from feature/*.

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.

[Dakota Hawkins]

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.

[Ulrich Kuhnhardt _IzymesDev_]

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.

[Dakota Hawkins]

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 develop branch.

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:

• User submits pull request 1 from feature/tinyFix to release/version_1.1 - no conflicts
• User submits pull request 2 from feature/tinyFix to develop - no conflicts
• Pull request 1 is approved
  • Workzone auto-merges feature/tinyFix into release/version_1.1
  • Workzone deletes the branch feature/tinyFix
• Bitbucket declines pull request 2 because feature/tinyFix was deleted

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?

[Ulrich Kuhnhardt _IzymesDev_]

Dakota,

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?