Resolving pull requests with merge conflicts when using branch permissions in Bitbucket Server

Question

We've started using Bitbucket Server on our team, and want to enforce the use of pull requests to get commits from feature branches into our main integration branches. To enforce this, we turned on the branch permissions feature that prevents merges without a pull request for those branches. This works great, until we get a pull request that has a conflict.

In this case, the instructions say to manually fetch the head of the source branch and merge it to the target, then push this up. However, the merge commit gets rejected because by the branch permissions!

Are we missing something here, or is it not possible to manually merge when using branch permissions?

Jobin Kuruvilla [Adaptavist] · Answer

Yes, that can work. Or, you can directly resolve conflicts in the development branch, only when the merge issue is while merging to the deevlopment branch. That would require you to allow pushes directly to the development branch. It is a different workflow when compared to master. What you mentioned is the ideal route but that is a bit more work for developers (creating the extra branch, PR etc).

Julius Davies _GitBoost_com_ · Answer

I would use a "git merge --squash" to resolve the conflict, but it's a little tricky, because you merge into your local machine's "origin/master" but then force-push the result back to the feature branch.

Here's the steps (assumes branch you want to merge is known as "origin/feature/BRANCH_WITH_CONFLICT" on the server):

git fetch
git checkout origin/master
git merge --squash origin/feature/BRANCH_WITH_CONFLICT
... resolve conflict here ...
git commit
git push origin +HEAD:refs/heads/feature/BRANCH_WITH_CONFLICT

# Note:  the + is a shorthand for "--force".

(Yes, I do this all in "detached head" state).

The downside:  several commits get squashed into one.  Maybe you didn't want that.

Another thing to consider:  "origin/feature/BRANCH_WITH_CONFLICT" will no longer "git pull --rebase" nicely if others are still working on it.  You need to get everyone that has work in flight against this branch to do "git reset --hard origin/feature/BRANCH_WITH_CONFLICT" and then cherry-pick their work back onto it.  But probably this is an unlikely problem, since you were trying to merge it into master....

The upside:  you have a new branch with the important you work you needed, and it's now conflict-free and ready to merge via the PR screen.

eranamitai · Answer

I encountered the same problem, and I understand your answer. It would work technically, but my problem is that our feature branches are branched off master and then merged into the ongoing development.

If we merge target (development) into the feature branch, then I cannot later merge it into master if we decide that the change needs to go up as a hotfix.

I guess the only solution is to create a special branch off the feature branch, do the merge there, push it, then pull that branch into development?