1. Bitbucket
  2. Public Issue Tracker
  3. master
  4. Issues


Issue #9589 open

Force fast-forward only merges on pull requests for specific branches (BB-10717)

Vitaly Polonetsky
created an issue

We don't like to merge branches into master without reviewing the merged output before the merge. So our flow for merging branches is as follows: 1. A feature branch is approved (pull request needs to be merged) 2. git merge --ff-only 3. If merge failed, switch to the feature branch and merge from master, wait for approval of pull request with the additional merge commit, start over

But it seems that there's no way to block a merge of pull requests in BitBucket, only if there's a merge conflict. Personally I use BitBucket and is happy with it, but unfortunately this collaboration feature is a showstopper for us in using BitBucket in our company.

Comments (32)

  1. Vitaly Polonetsky reporter

    I believe we are talking about different things. And the solution you propose does not solve the problem.

    If I mark a branch to prevent history rewrites, I can still push non fast forward merges into it. I won't be able to rebase or delete committed revisions.

  2. Toon Geens

    This matches our worfklow as well:

    Maybe I can try to describe this another way: Feature branches only get merged into master using --ff-only

    If it's a --ff-only merge, great, you are done! If it's not a clean fast-forward merge: 1. rebase the feature branch from master 2. then do a --ff-only merge from feature to master.

  3. Maxim Novikov


    It looks like Bitbucket always merges pull-requests with --no-ff option which is not convenient for those who try to keep the project history linear. Currently to work around this Bitbucket's limitation I have to rebase the master branch after each merge and force-push it to the remote.

  4. Ryan Poolos

    Any updates on the functionality? I really hate seeing all these merge commits. We already rebase our branches off dev before pushing for a pull request and it creates the merge commit no matter what we do.

  5. Geoffrey Chan

    Yeah, this is pretty annoying.

    We always rebase feature branches before merging into master to keep the commit log as tidy as possible. Pull requests are nice but the merge messages are annoying for some use cases.

  6. Nenad Miksa

    +1, we need that behaviour on all feature branches except for few configured branches that should be allowed to merge without being fast forward.

    Actually, it would be ideal for BitBucket to merge pull requests with following command:

    git merge feature/branch --ff-only --no-ff

    This will ensure that merge will fail if merge is not fast forward, yet merge commit will still be created.

  7. Matt Cruger

    +1 Bitbucket should offer this functionality the same way GitHub and GitLab do. Including auto squashing commits on feature branch when merge is done via pull request.

  8. Rhodri Pugh

    To add another real world use case to this, we have had bugs merged to master after successful pipeline builds on the PR because of semantic differences after the merge (that would have been prevented if --ff-only was enforced).

  9. Piotr Galas

    This is key feature in my opinion. I wondering why It has only about 60 votes. This is the reason why it is not implemented yet. Please vote it if you want this feature.

  10. Petr Jasník

    This feature is absolutely necessary for branching-workflow and its still not implemented (after 3 years). I like BB, but i do not recommending BB to my colleagues anymore because this "bug" and my team considering migration to different solution.

  11. Log in to comment