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

Issues

Issue #6106 open

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

Alex
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 (78)

  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 Stuart.Jones@UnicornTraining.com or Vikki.Price@UnicornTraining.com 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 sophie.kemp@paulsmith.co.uk.

    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: https://confluence.atlassian.com/bitbucketserver/pull-request-merge-strategies-844499235.html).

    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. Log in to comment