In our workflow, we protect our release branches to only accept commits via pull requests. This is creating a problem is we have a merge conflict with an automatic cascading merge. The merge conflict pull request gets created, but we're not sure what the proper workflow is to resolve these merge conflicts.
So far, we've been cutting a new feature branch from master, merging the original feature branch into the new feature branch, merging the target branch for the cascading merge that's failing into the feature branch, resolving the conflicts, and submitting a new pull request to the target branch that the cascading merge is failing on.
This works, but seems awfully convoluted. Is there a better way? Also, the instructions on resolving merge conflicts in Bitbucket are completely wrong if a target branch is a protected branch (you cannot commit to it directly), causing a ton of confusion.
Let's say I have a restricted release and master branches, requiring two PR approvals before a branch can be merged into these targets. I have made a change in a feature branch, approved the PR and merged the feature into release branch "release/1.3". The subsequent cascading merge to "release/1.4" fails due to a conflict. We solved this with the following strategy:
This community is celebrating its one-year anniversary and Atlassian co-founder Mike Cannon-Brookes has all the feels.Read more
Bitbucket Pipelines helps me manage and automate a number of serverless deployments to AWS Lambda and this is how I do it. I'm building Node.js Lambda functions using node-lambda ...
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