Issue #9589 open

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

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 (12)

  1. m_vitaly 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. m_vitaly reporter

    Issue #6106 is about allowing fast forward merges in pull requests. This issue is about forcing them, not allowing pull request merge if it's not a fast-forward one.

  3. 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.

  4. csbubbles


    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.

  5. 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.

  6. 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.

  7. Log in to comment