How to ensure 1 merge commit for BitBucket pull request No-FF strategy on restricted branch?

Question

I'd like to always have a no fast-forward effect on the base branch (creates merge commit always). Based on the following Bitbucket settings used by my team it appears sometimes 2 merge commits will need to be created in order for conflict-resolution.

Bitbucket Server Branch Settings

• Changes without a pull request - prevents pushing changes directly to the specified branch(es); changes are allowed only with a pull request. Branch Permissions

• Merge Commit (--no-ff) Always create a new merge commit and update the target branch to it, even if the source branch is already up to date with the target branch. Default Merge Strategy

Since the base branch can only be changed via pull-requests, and it always creates a merge commit on PR-merge, therefore it appears pull requests that require manual conflict resolution will have to have 2 commits.

Problematic Scenario example:

Here is the scenario: the base branch gets merged onto the feature branch to manually resolve the conflict, in this case the manually resolved conflicts result in a merge commit. Then after pushing the conflict-merge commit then the PR will be updated and ready to merge, and upon merging to base it would then create yet another merge commit (due to no-ff option). Technically only 1 of those 2 commits were needed. When done directly in git (without pull request and without locked down branch) this could have been achieved using no-ff by merging directly onto the base branch.

Is there something I'm missing here? Is there a way to achieve exactly 1 merge commit using Bitbucket Server pull request restrictions?

Answer 1

This is the expect result if you have set merge changes into the base branch via PR and with no-ff merge strategy.

Assume the base branch is master branch, and the pull request is for merging feature branch into master branch, and the commit history as below:

…---A---B---C---D     master
             \
              E---F  feature

If you resolve the merge conflict by merging master branch into feature branch with default merge strategy, and after completing the PR, then the commit history will as below (commit G is the first merged commit and commit H is the second merged commit):

…---A---B---C-------D---H     master
             \       \ /
              E---F---G  feature

In order to make the commit history look clearly, you can change the way to resolve merge conflict by git cherry-pick or squash merge strategy .

• If resolve the merging feature into master branch's merge conflicts with git cherry-pick :

   git checkout feature git cherry-pick D # resolve all conflicts git add . git cherry-pick --continue git push origin feature 

  After completing PR, the commit history will be:

   …---A---B---C---D-------M master \\ / E---F---D' feature 

• If resolve the merging feature into master branch's merge conflicts with squash merge:

   git checkout feature git merge master --squash # resolve all merge conflicts git add . git commit git push origin feature 

  After completing PR, the commit history will be:

   …---A---B---C---D-------M2 master \\ / E---F---M1 feature