Provide the option to use "git merge --ff-only" for pull requests (BB-7307)

Issue #6106 open
created an issue

I experimented with pull requests in my private repo. I did one commit into a feature branch, opened a pull request "feature->master" pressed "Merge". Master has not changed since feature branch start, so I expected "fast forward" merge to happen that would just append this one commit to master. I think this is default Git behavior -- do fast-forward merge when it can. Instead, Bitbucket did an extra Merge commit, having previous master tip and my branch commit as parents.

I think linear history is easier to read. It would be good to have fast forward merging by default when possible, or at least have an option to do so. To achieve this currently I have to merge this branch locally and then pushing to master, avoiding the whole "pull request" feature.

Or are pull requests intended to behave like this? If so, why?

Comments (98)

  1. Thomas Woolford

    @Alex If you have a fast-forward merge, you get linear history sure but then why are you even using a branch? As soon as you've merged, the record of your branch is hard to see. With a merge commit, It makes things explicit as to when the merge was made and by whom. I honestly think that this is the right thing for anyone taking Pull Requests (You're not just sitting there pulling yourself all day are you? ;)

  2. Alex reporter

    @Thomas Woolford no :) Thanks for the point, it makes sense.

    I thought I'd use pull requests as a tool to code-review a set of commits (branch), as opposed to reviewing individual commits. This branch can be discussed, rebased and cleaned up before integrating into master. I now see why no-ff is a good default setting for many cases, but I still see value in having a chance to do fast-forward merge sometimes. For example, if we are small team, pull requests come from project-aware team members (not outside), and there's no big point in keeping branch history (thus we can make it linear).

  3. Nick Baker

    I would also like the opportunity to allow a FF from a pull request. The linear history is nice while preserving the code review aspect of pull requests. I'd really like to see and option to to create a FF by rebasing the source branch (assuming no merge conflicts in the rebase). This would go a long way toward cleaning up our history.

  4. Gergely Nagy

    +1 And for us, it would be great if only ff merges are accepted. We want to enforce that the pull request is properly tested before merged, and don't allow merges if ff is not possible.

  5. Wojciech Jankowski

    +1 Especially in Gitflow workflow when somebody adds a few commits directly to 'develop' branch it should be ff-ded to origin 'develop' branch. In this case linear history should be certainly preferred.

  6. James Foster

    Just so everyone knows...

    If you want to do a fast forward from a pull request, just do it locally and push the destination branch back to bitbucket. Bitbucket will recognise that the destination branch is up to date with the source branch and the pull request will be marked as "Merged".

    This should be sufficient for those who prefer fast forward merges.

  7. Michael Clawson

    +1 Our pull requests are already rebased down to one commit (except for feature branches). It becomes ridiculous to have alternating work and merge commits in our history.

    Manually is an awkward option because QA does our merges. We want to do the --ff-only merge in the Pull request.

  8. Tim Searle

    Really after this feature. I want to configure Bitbucket to only allow fast-forward merges when merging pull requests, and fail otherwise and inform the user a rebase is required.

  9. Ian Dunkerly

    I am currently on annual leave, returning on 13/04.

    Please contact or if you require a response sooner.

  10. Simon Young

    I am currently out of the office on annual leave and I will respond to your email on my return on 13 April 2015.

    For any urgent issues in my absence please contact Sophie Kemp on 0115 968 2270 or email

    Kind Regards

    Simon Young Web Development Manager

    Paul Smith Limited The Poplars Lenton Lane Nottingham NG7 2PW

  11. Anton Ukhanev

    Could someone please explain to me why without the FF merge a pull request would be useless? You can still see the comments, and the commits are the same. Looks like I'm missing something, since as far as I can tell all it does is create a concrete point in history.

  12. Anton Ukhanev

    No need to clean. All that needs to be done is merge back. This is the strategy we use with releases: there are master, develop and feature/myfeature branches. As code gets reviewed and approved, code is merged from feature/myfeature to develop. When it's time for release, release-1.2.3 is created, and changes necessary for it are made there. In the meantime, features are being merged into develop. On the release date, we simply merge release-1.2.3 into master, then master into develop.

    Like this, each release has a dedicated point in history of both master and develop, they contain the same commits, and the merge commits have a reference to the original feature branch.

  13. Maxim Novikov

    @Anton Ukhanev

    If not fast-forward, each merge create a new commit (empty and useless) in your Git repo history. If you have a couple of people working on the same project and they commit relatively often (and each feature requires not a lot of commit per se), then about half of commits (which are caused by non-FF merges) in your history is garbage.

    There are multiple strategies to use Git for the development process, people approach the one which works best for them, not necessarily that one you have mentioned. Also, it is kind of unrelated to the current issue. When you merge non-FF, then you get a new empty and useless commit. The more you merge, the more such commits you get. Regardless of your general process.

  14. Anton Ukhanev

    @Maxim Novikov, each commit that your team members make on a feature branch stays as a single commit. When the feature is ready, the code is reviewed and approved, then the merge will result in one single additional commit on the develop branch, e.g. one per feature. Additionally, every release will also create one additional commit on the master branch. If during integration testing you need to merge multiple times into your develop branch, then I believe you should create a separate throw-away integration branch, and merge to it until the feature is ready, especially if you are in favour of "clean" history.

    That said, I do not intend to state that this is the only way of doing it, and that other ways, including those which use fast-forward merges, are invalid. Instead, my question was "why without the FF merge a pull request would be useless?". The no-FF pull request merges add a feature which make subsequent tracking of repository "events" possible. I acknowledge that there may be a need for a no-FF merge.

  15. Greg Manning

    The reason it is useless for some people, is that some people have decided that the benefit from using the bitbucket pull request feature is not worth the drawback of having the commit created that they don't want.

  16. John Camelon

    Polluting the log does not make the feature useless IMO but it definitely makes it unpleasant. I have to weed through 40% more commits than I would without the feature working this way.

  17. Maxim Novikov

    @Martin Thwaites

    Yeah, what I do for now to work this issue around is after the pull request merge:

    git checkout master
    git pull
    git rebase HEAD^^
    git push -f

    Which works, but certainly not pretty as you have to do it manually on every merge and basically rewrite the history.

  18. Michal Brzezinski

    @Maxim Novikov Sure, but as we can see here, currently it's not possible. So, until this feature is resolved is implemented, a possible workaround is to :

    1. don't click "merge" button (you can just close PR) and do merge via command line
    2. click "merge" button and then overwrite master branch history via command line

    So in both cases you have to use command line at some point and cannot handle all the stuff via UI, there is no way around it. And changing history of master branch is dangerous - what if you don't do it quick enough and between merging PR and rebasing someone commits? 1. option is just safer imho.

  19. Maxim Novikov

    @Michal Brzezinski

    It is possible in Bitbucket Server (ex. Stash). So this ticket is a request to support the same in a free version.

    PS I have never had any issues with rewriting the history actually. The only thing is the usability - you need to do more work that you could have. It's kind of irrelevant whether you do it "quick" enough or not. Git will not update things twice at the same time, one of the updates (pushes) will just fail.

  20. Michal Brzezinski

    Sure, I am all for supporting fast forward merge here, don't get me wrong. I'm was really surprised when I discovered it's not here.

    About git safety: git push -f is not safe by definition. Normal git push fails - but with -f you can do whatever you like and any changes by others will be overwritten. Anyway, it's not related to this issue se let's not discuss it further, I just wanted to suggest my workaround for lacking PRs on Bitbucket.

  21. olivier_farlotti

    The question is not "should we FF merge or not ?". The question is "as a user of GIT can I choose, for my own reasons, to do FF merges ?"

    In my team we decided to adopt a workflow (with master/dev/feat branch model) :

    1. JIRA
    2. Bitbucket branch
    3. pull on local, dev, commit/push as often as possible
    4. dev done, local rebase -i (single commit), rebase develop, then push
    5. pull request (great thing)
    6. merge from PR

    Initially we want a clean history.

    We can do it with GIT only. Why shouldnt we do it with BitBucket ?

  22. Antonio Aversa

    +1 having a linear history is very important to us: we are already putting a lot of effort into rebasing, rewording, squashing and reordering commits before any pull request, with the clear intention of getting a readable and simplified history. These merge commits just pollute the history and jeopardize our efforts in this matter.

  23. Sean Farley staff

    For sure. I was just using the other ticket as a catch all for 'different merge strategies' since implementing one would mean it'd be trivial to implement the others.

  24. Victor Escutia

    +100 I'd also love to see this option though it'd be even better to see the full stack of option the Server version provides unlike the Cloud version (check this out:

    Guys, I think everything is subject to opinion so arguing as to why we need it or why we don't need it is pointless, it's the whole discussion of what's better: no ff merging vs ff merging vs rebasing vs squashing all over again... Everyone has different needs, and I can even say that everyone has had at least once, the need of using all these different options, or at least that's the case when you work in large teams and on large projects. So let's stop discussing if it's wrong or not changing history, blah blah blah... that's not the point of this ticket.

    Back to the issue at hand, as someone said, the whole idea behind pull requests is to handle all the stuff via the UI and for that, we need to have all the options available Git provides in the UI, and is up to one to use them as one pleases! and those who really understand these options to really leverage from it to get a whole world of different possibilities. By the way, the paid version of the Cloud also only supports 2 options, so it's not only the case of the free version.

    So I guess what I'm saying is why the Cloud version has to support only 2 or 3 options out of the 5 pull request merge strategies the Server version is already supporting? It just doesn't add up.

  25. Maxim Novikov

    @Robin Stocker @Sean Farley

    It's been 4 years already... Any update?

    We have been evaluating BB vs. GitHub recently as we wanted to migrate to Cloud, and decided to go with GitHub mainly because it supports this feature. So we are now paying GitHub $450 a month for their Plus plan for 50 users, and BB is missing out (us, at least) because of not supporting "rebase only" workflow and SSO / SAML.

    Do you really think this feature is not a big deal? GitHub doesn't seem to think that way, and they got us as their customers (even though we use JIRA and Confluence, and would love to use the whole Atlassian stack).

    Also, I think the title of the issue is wrong now. Who cares about specific Git commands using the UI? The request was to support pull-request merges for the "rebase workflow", which is basically:

    Introduce an option to forbid non fast-forward merges and avoid creating additional merge commits

    How you implement it internally and which commands you would use on your backend (GitHub, for example, does it differently cherry-picking every commit instead, I think) is irrelevant for the request, and we (users) don't really care about it.

    GitHub's example:

    Screen Shot 2017-02-26 at 3.21.18 AM.png

  26. Evin Callahan

    I'd like to inquire about the status of this, can someone please provide an update?

    Here's our use case: we use tags as a way to tie a docker image, to a commit itself. So if we get an image built in branch A, I don't want to have to go recreate that same image again when it gets merged to branch B. That's what happens when the extra 'merge-commit' occurs, and there's no way of selecting a --ff-only option during merge time in bitbucket cloud. This causes us to have to rebuild the image when it just doesnt make sense to.

    I'm surprised I haven't seen this use case much in this thread, but supporting an option that git uses out of the box seems like a no brainer to me.

  27. Paul Wagland

    This functionality is close to what I want. What I would really love is the GitLab:

    Merge commit with semi-linear history

    A merge commit is created for every merge, but merging is only allowed if fast-forward merge is possible. This way you could make sure that if this merge request would build, after merging to target branch it would also build. When fast-forward merge is not possible, the user is given the option to rebase.

    Would it be possible to get this?

  28. Sean Farley staff

    It's something I'm working on but need to work with some designers and also some other projects I'm assigned. I'm trying to get this done soon but we'll see.

  29. Waldir Pimenta

    Just to add to Paul Wagland's comment above about a semi-linear history: this is described nicely in the post A tidy, linear Git history. The illustration used there explains the difference visually quite well, and I took the liberty to add a pure linear workflow to the diagram to demonstrate the differences between merge vs. rebase && merge --ff-only (linear) vs. rebase && merge --no-ff (semi-linear):

    merge vs. rebase-ff vs. rebase-no-ff.png

    GitLab supports this already, as Paul mentions, and it would be great if Bitbucket did as well.

  30. Andrew Howden

    There's a vote button in the top right. Please don't +1 this issue, instead, click the vote button.

    +1'ing generates emails to already cluttered inboxes. You're not exactly killing tree's by wasting paper, but you are generating countless vibrations, popups, alerts, noises and other flora and fauna that generally make our lives busier.

    Thanks for understanding <3

  31. Alec Sammon

    +1 !! I know there is much debate about if this is a good strategy or not, however we have some specific use cases that makes this essential for us.

    At the moment we are looking to move all our private repos to GitHub, unless BitBucket can give us some timeline on when this might be available.

    @Sean Farley - can you update us with some estimated timeline please?


  32. Dan Rumney

    I appreciate the work being done, but what's the critical challenge here? This is already available in Bitbucket Server and has been for a long time.

    The debate about whether ff merges are good or bad is irrelevant. That's an organizational decision that should be made by the team working with the repo. What's unclear is why this is not available on the Cloud version of a git instance when it's a standard git function.

  33. Vladimir Blagojevic

    It is harder and more time consuming to mark all the duplicates of this issue than implementing the feature altogether. I can not believe how many people have asked for such a simple thing, wrote all these comments...what a waste.

  34. Can Celasun

    Hundreds of people get email notifications for this issue, so please refrain from commenting if you don't have anything new to add. Everything that can be said about this issue has already been said over the past 5 years, so all we can do is wait.

  35. Maxim Novikov

    @Can Celasun What you have written as well, by the way. :)

    I personally think that it's better to write as many comments as we can, even if it's just +1. This is the only way to have at least a chance that the folks at Atlassian will eventually notice and do something about it. Also, it shows that there are other people who care and would like to get this feature supported (which is great).

    "Votes" or anything else is no help. And who doesn't want to receive updates/comments can simply click "stop watching" button at the top.

  36. Nenad Miksa

    @Maxim Novikov, I guess that Atlassian folks have stopped watching this issue or redirected their e-mail notifications to spam. Because this feature really shouldn't be difficult to implement. I guess they don't care and are OK with loosing some customers due to that (Github is still almost twice as expensive as Bitbucket premium and other competitors are practically non-existing).

  37. Waldir Pimenta

    I personally think that it's better to write as many comments as we can, even if it's just +1.

    I disagree, and I'm sure many here do as well. Have you considered that there might be a silent majority trying not to add to the noise by speaking up against the flood of +1 comments while not adding anything substantial to the discussion (which is what Can and I have now been forced to do)?

    This is the only way to have at least a chance that the folks at Atlassian will eventually notice and do something about it. "Votes" or anything else is no help.

    The evidence points quite to the contrary direction. Comments have been added for years now without influencing the outcome of the discussion. If we assume that votes have no effect, then by the same logic we should conclude that adding more comments doesn't either.

    And who doesn't want to receive updates/comments can simply click "stop watching" button at the top.

    So people are forced to either handle a constant stream of comments that don't advance the discussion, or be left in the dark regarding actual progress? I'm pretty sure every one who subscribed to the notifications for this issue wanted the actual news, not repeated comments restating the problem we all know already. Those leaving +1 after +1 are the ones misusing the notification feature, not the subscribers, so IMO there's no sense in shifting the burden to the latter, especially when this doesn't even accomplish anything with Atlassian.

    A final plea to everyone leaving +1 or similar comments: please, before pushing the "Comment" button, remember that every new post in this thread forces hundreds of people to deal with an extra message in their inboxes; and although it's a small effort individually, the cumulative effect is quite disruptive. So use this "power" with care and respect for everyone else's time.

  38. Garret Wilson

    I can see both sides. It's irritating as customer not to have essential features, and it adds insult to injury for Atlassian to ignore the votes of popular requests. (Those goobers won't even add Markdown to JIRA.) But Waldir has a good point that it leaves no way for someone to be notified of the status yet not be inundated by +1s.

    So here's another idea that might address both concerns: instead of adding +1, why not file a new issue for the same request? That way Atlassian is informed of its popularity, yet Atlassian, and not other users, is inconvenienced by these "pings" as it were. Sure, it's almost a little virtual civil disobedience, but I don't think it's unethical. Anyway, I'm just brainstorming --- maybe someone else has a better idea for getting Atlassian's attention.

  39. Henri Tremblay

    Here are my 2 cents. This feature is already available on premise. Not having it on the cloud means Atlassian is not using a cluster of the latest on premise versions to power their cloud. This is highly frightening and if I was Altassian, I would consider this to be a big big fail.

    More than that, this issue is now 5 years old. It means the on premise version and the cloud version as been diverging for that long at least. Deeply deeply frightening. Maintaining two separate versions of the same product must be costly. Which can explain why this issue has never came on top of the priorities.

    If you are a paying customer, I would suggest that you complain directly to Atlassian support. That's the best place to get attention.

  40. Log in to comment