Provide the option to use "git merge --squash" for pull requests (BB-10142)

Issue #8995 resolved
Roy Truelove
created an issue

Issue #6107 was closed two days after it was opened, and since then has received many +1's to the point where it warrants revisiting.

While the original ticket asked for quite a bit of functionality, given the comments i'd suggest limiting the request to "The ability to squash pull requests".

Official response

Comments (215)

  1. Mike Staff

    +1 for a tickbox option. We just started using PR, triggered by a larger team, and this would be super helpful to keep the checkin history easier to read.

  2. Sean King

    +1 for squash merge option, currently we've got a script running to git reset --soft HEAD~[no of commits] && git commit && git push -uf origin branch all pull requests before merging via bitbucket, but that's pretty kludgy and results in a weird history. I think PRs + squash merging for all work is a standard enough workflow to warrant a toggle in bitbucket.

  3. Alex Rousskov

    @Jonathan Mooring, if you need more encouragement or ammunition against skeptics, please note that squash merge support fits the original "simplified interface for code review followed by quick and painless merges" requirement that you have provided in issue #6107. The current Bitbucket implementation actually does not:

    • "simplified interface": Adding a simple checkbox is not going to make the interface complex. As an added bonus, it would make it clear to the user whether the changes are going to be squashed. Currently, one has to search documentation or experiment to figure that out.

    • "code review": Perhaps you write perfect feature branches that contain a single commit and do not need review, only approval. Most folks are not that good. For them, "code review" usually means at least one polishing iteration and, hence, at least two commits. The resulting string of "addressed reviewer request" commits should not be merged separately, of course. Those commits have no stand-alone use or merit in most cases. And if a code review exposes a serious bug (that is later fixed during the same review process), then merging those buggy commits is a lot worse than just increasing commit noise! In summary, code review implies squash merges in most environments.

    • "painless merge": Talk about the pain of watching the master branch filling with polishing commits, fixes of bugs that should have never made it into master in the first place, commits with poorly written commit messages, etc., etc.! And how about the pain of doing simple merge actions (that ought to be automated via the review interface) by hand?!

    Supporting squash merges would also give Bitbucket an advantage over Github in this area. Unless Github starts supporting them first, of course. AFAIK, many Github projects have to torture their contributors with the same "squash your pull request after review" nonsense...

  4. Jessica Hamilton

    In the context of GCI (Google Code In), students submit pull requests for their work to be reviewed. And as this is often their first time with large open source projects, require a lot of follow up commits.

    To add manually squashing their own pull requests on top of teaching them everything else gets very tedious. Or having to do it ourselves (and not all of our mentors are git gurus familiar with having to do this either). We've literally had over 100 different students, and numerous pull requests.

    This feature should be high on your priority lists!!

  5. marc0s

    While it's not fixed, how do you guys do to to locally merge --squash and then close the PR at Bitbucket without declining it? Is it possible?

  6. Lee Robert

    My company opted to pay for github instead of bitbucket primarily because of the fact that there are tools such as pulley that squash and close github pull requests.

  7. David Pfundt

    @marc0s, When a feature is complete, we create a temporary "squash" branch off the main development branch. We then use git merge --squash origin/feature/XXX to squash it all into this branch. Our pull requests are then made off the squash branch. If we have more commits arising from the pull request, we will often re-squash and re-submit the pull request. Not ideal, but it's a workaround.

  8. Arnaud Vié

    I'm surprised this is not possible yet.

    An extreme case I encounter is having newbie developers, not familiar with git at all, willing to contribute to my project. Because they are not familiar with git yet, they will get mixed up, sometimes merging branches by mistake and even putting some commits in the wrong branch (as they forgot to checkout), etc. In the end, using revert commits, they fix it all up and send a pull request.

    Therefore, I get a pull request where the diff is all good, and I'd like to accept it, but the commit history is garbage. It'd really be nice to just tick an option to squash the diff into a single clean commit at merge, rather than ask newbies to rewrite their history. (rewriting history is something which requires a bit of understanding of git, which newbies obviously don't have yet)

    Anyway, it's only one specific use case, but I'm pretty sure this feature would be useful to a lot of people :-)

  9. Umang Dhawan

    +1. In my team, we create PRs for review and once approved, we manually merge squash it, and then decline the PR. Having ability to merge squash from bitbucket itself will be very useful!

  10. David King

    This would be a great feature to help the iterative nature of Feature Driven Development coupled with those of us desiring a clean commit history without any process workarounds.

    Please consider adding this feature I know many of us would be happy to beta test :-)

  11. Joshua Kugler

    I know there are lots of votes, and lots of comments, but I'm adding mine as well. This would be hugely helpful, as we enjoy using the web interface for doing review and final merges.

  12. Jay Banyer

    Any update here? This is, by far, the feature that I would most like to see added to BitBucket. Currently we either have to merge using BitBucket which means we get the full history of the branch, with all the revisions, corrections and reversions, or we can squash merge (which is what we want) outside of BitBucket then decline the pull request, which is ugly and misleading.

    BitBucket staff can we get some feedback please? Is there something that makes a squash merge option more complex than it seems?

  13. Max Wolter

    Just one more example of Atlassion ignoring user feedback for more than a year for a feature that would have a huge impact on customer satisfaction and would involve minimal work to implement.

  14. Arne nl


    Nobody mentions the 'merge commit clutter'. During the lifetime of a feature branch, multiple merges from master into the feature branch are necessary. You get these in your master history when merging a PR. Yuk!

  15. Darrin

    LOL +1 - I'm late to the party but what can I say - I don't want an onerous process and our history IS getting cluttered.

    Atlassian - 221 votes and about 2 years later. I suppose this feature doesn't lead to new customer acquisition but this really would be nice to make your current users happier.

  16. Roy Truelove reporter

    Two questions that pop out at me re: this:

    1) Against which commit would the squash occur?

    In some cases this is unambiguous :

    *    ( will squash to here )
    | \
    *  *
    |  |
    |  *
    |  |
    *  *

    But in some cases no:

    *    ( diverged here..)
    | \
    *  *
    | \|
    |  * ( upstream was merged here )
    |  |
    *  *

    Is it reasonable for BB to figure out that the squash should happen at diverged here, and also that during the rebase on top of the upstream that it should not conflict on code that was already merged onto the feature branch?

    2) Who should be the commit author?

    Quick answer is that it should be the user who's merging the PR, but the problem with that is that all original authoring information is lost. So if user 'joe' did all the work on the feature branch and user 'sally' did the merge, there's no reference at all to 'joe'.

  17. John Martin

    Hi Roy,

    At my previous company which did not use bitbucket we elected to make the last commit author the author of the squashed commit which shows up on the merge destination. So if 10 people worked on a branch the last person to commit to the branch is the commit owner. This is not entirely a big deal though, as the git merge --squash --author 'joe' command defaults to including the history of the commits as the comment for the squashed commit. Thus you achieve a very clean master git log (Which is our goal Atlassian!!), and still can understand the history of each change by looking at the commit comment.

  18. Alex Rousskov

    @Roy Truelove, git itself will answer your first question: BB does not need to know the answer. The BB implementation ought to run the equivalent of the git merge --squash branch command on the target branch and letting git decide what that means (while reporting errors back to the user). In other words, BB should do exactly what it does now when a merge button is pressed, but with a --squash option.

    Why do you think BB needs to make any decisions here? The only BB decision I could think of is validating that the pull request diff the user is seeing corresponds to the current target and feature branch states (if not, BB should ask the user to reload first).

    Your second question is valid:

    • If BB does not want to make commit authorship configurable, then the person executing the squashed merge must be used as the author! There is no other sane/safe "author" in this case. Since we are talking about purposefully forgetting the entire feature branch history, we must assume that any individual branch commit details are not important and are often harmful.

    • If BB wants to make commit authorship configurable, then the suggested default could be either the branch author if there was only one author for all branch commits or the current user (as discussed above). Providing an optional list of all authors (with the number of their branch commits?) would be nice.

    FWIW, the non-configurable implementation would address 98% of our company needs so I would selfishly recommend starting with that simpler option.

    So if user 'joe' did all the work on the feature branch and user 'sally' did the merge, there's no reference at all to 'joe'.

    Counter-argument: Committing references to joe while omitting references to bob (who also worked on the feature branch), is often worse than simply using the merge user as an author and, hence, not relying on git log for code authorship information.

  19. John Martin

    So the original request as highlighted was now posted 3 Years ago. Can we at least get a comment to find out if this will be scheduled? If not just mark it as won't fix and move on as done for the original issue.

    Original Reason for rejection: "Thomas. Pull requests are not intended to be a full replacement for git merge, but rather a simplified interface for code review followed by quick and painless merges."

    This is missing the point for this request considering SDLC in today's CI / CD world. My organization wants to use bitbucket as our audit log for code reviews. We also desire tracking for each change (Jira Item) to be cleanly merged on the master branch for operational support reasons. Git is a very nice way to keep our Developer Operations team updated with our Continuous Intergration and Continuous Deployment strategies. When things go wrong, being able to see the WHOLE change quickly makes a very important difference in the support role. This is our motivating perspective. It prevents us from using bitbucket as our authoritative source for code reviews. In order to use the squash feature all of our pull requests are now "Rejected" and we cannot use bitbucket for source review audit history.

  20. Michael Bean

    @Alex Rousskov put it quite well. There isn't much to implement. If people want to accept what git does for a squash, then they are prepared to accept the simplest and v1 implementation of a squash via BB. A second version could add more bells and whistles.

    If I worked at BB, I believe I would have implemented this by now using my free time.

    On the flip-side: If you want to squash, you can just use git to squash and then push it...and lose all per-commit review history. Yeah, current feature doesn't fit a squash model when auditing is involved.

  21. Felix H. Dahlke

    Wow, just wow. Just merged my first BitBucket pull request and I was actually forced to decline it in the end since I always use merge --squash to keep the history clean. Even if this issue isn't being solved, can we please at least get a way of closing issues WITHOUT declining them?

  22. Kevin Nagurski

    Agree. I'm trying to push through a move from SVN and code review using crucible to git and pull requests using bitbucket. Would it really be so difficult to add a tick box to the UI and the flag to the merge command?

  23. Sam

    For such a relatively easy thing to implement, and for something so many people care about, and for something competitors have already implemented, it's incomprehensible that the last comment from staff was two years ago. Shorting TEAM now.

    Oh, and +1

  24. Tri Nguyen

    Next time, you could just "Vote" for this ticket. You will be subscribed for updates, and as a bonus, not spam everyone watching the issue with emails of "+1" or "me too".

  25. Thomas Bruno

    We desire this functionally very badly due to continuous integration with Bamboo where most commits are typo fixes. Git repos that back Amazon OpsWorks are also extremely messy as commits drive deployment so we may have 10-20 commits just to bump a deploy. We'd like the Master branch to reflect only the over all changes of solid config releases that can be easily rolled back.

    Following Git Flow without this feature, and integrating with build/test systems such as bamboo makes git logs completely useless as they are filled with quick typo fixes and fixes for tests that developers don't know will fail until the commit is made and Bamboo attempts a build.

    I agree, this is getting to the point of ridiculousness. Nearly every simple feature request to Atlassian cross product is completely ignored this way. We will have to start researching other products if Atlassian can't step up to the plate for ANY one of our requests.

  26. Lucas Lacroix (Luke)

    This feature is sorely missed. We follow the typical Git workflow (code/review in a branch, merge to master). While the branch exists, JIRA correctly shows the association (we name our branches after the JIRA issue they are resolving). When we merge and then delete the branch, JIRA shows a single commit in the master branch and that commit is empty (no changes). This is because the commit contains the metadata about the merge and contains no changes. This means that other developers must go to the git log in order to see what changes were actually made.

    The solution, for us, is to squash the merge in to master. This allows other developers to see the changes from the JIRA issue without going to the log. It would be hugely beneficial if BitBucket would support this standard workflow.

  27. Metin OSMAN

    I used to work with Bitbucket, but since I have changed to another team I had to work with Github.

    The fact is that Pull Request reviewing is much better with Bitbucket, but I have discovered that Github offers the ability to squash before merging, and this is actually a killer feature when dealing with gitflow branching model.

    Now, I have to decide whether I should go on with Github or ask my boss to buy a Bitbucket licence.

    Atlassian products are great, but this kind of feature asked by the community, or clients which are postponed for years make me feel like I should go on with Github.

  28. Thomas Bruno

    We recently discovered which isn't as big of a player in the space but definitely listens to feature request and their customers (even the free customers). We've been pretty happy after the migration. Even get SSL on static repo website hosting that gitlab and others fail to do.

    We've had to move away, there are just to many issues that Atlassian will not address or even acknowledge.

  29. Michael Bean

    Right. I was just answering how I have lived without it. I didn't mean to say it was easier or preferable. I am a voter and watcher of this request, so you know what boat I am in.

  30. Garret Wilson

    Atlassian, let me give you an idea of the nonsense we have to go through simply because you refuse to give us functionality that we can get from GitHub. We have a repository that a developer has forked. After a lot of back and forth changes, we had a lot of commits that went in circles and had no business being in the history. So when it was all ready to merge, I clicked the "squash" checkbox... no, just kidding, of course I didn't do that, because it isn't there. Instead:

    1. I told the developer to do a "git reset --soft commit-id-of-fork-before-work".
    2. Then I told the developer to do a "git commit -m commit-message".
    3. Finally I told the developer to do a "git push" using the "--force" flag.

    But the developer had merged in changes from upstream, and the push was apparently two commits behind master, so the developer tried to merge from upstream again, and suddenly we get three commits, the last one empty, and so the developer tries to compensate by soft resetting to a commit before the original fork, and suddenly the entire pull request disappears.

    Atlassian, please don't say, "but the developer should have blah blah blah" or "but the developer should not have blah blah blah" or "but..." whatever. There is probably some magical Git procedure to work around the fact that you don't have this feature, and maybe all Git gurus know it, and maybe I should know it, and maybe the developer... look, Git is not simple!

    The point is that we shouldn't even be talking about all these messy Git workarounds to begin with. Bitbucket should have had a "squash" checkbox, and this story would have ended in the first paragraph.

  31. Alastair Wilkes staff

    Hi @Nick Fauchelle! I'm afraid I don't have much to add right now besides a reaffirmation that we agree that this is a key component of many workflows (like the one explained above by @Garret Wilson), so it's definitely something we want to add - sorry I don't have a firm timeline to offer right now, but we do plan to add this.

  32. Garret Wilson

    Just to update everyone on my missing pull request. I opened an issue with Atlassian, and they found that the pull request is still there, Bitbucket just thinks it has been merged---even though no one told it to merge, and even though it contains no commits whatsoever! The representative claims that he "brought this up to the dev team", but unsurprisingly I have heard nothing back.

    I specifically asked what the holdup was on this current issue (of implementing squash), and I said, "Instead of answering my question here, the polite thing to do to your customers would be to answer my question on issue #8995, as people have been asking that question for years with no response from Atlassian."

    As you might have guessed, the representative went quiet and stopped responding.

    This week another of my developers is working on a pull request. He misconfigured Eclipse and it rearranged a lot of imports (unrelated to the modifications), and I'd rather not have that in the history, so... here we go again. I'll tell the developer with do a soft reset, followed by a re-commit, followed by a forced push, followed by...

    Actually I'm leaning towards just telling the developer that we're switching everything to GitHub.

  33. Kevin Nagurski

    For those who really wanna stay with BitBucket and don't want to have to kill off pull requests, here's a work-around.

    1. Open the PR and do all the back and forth until you're happy and ready to merge
    2. Don't click the Merge button, but head back into your terminal
    3. Initiate an interactive rebase onto your target branch - git rebase --interactive master
    4. pick the 1st line and change all the rest to s (literally replace the word pick with a s)
    5. Fix conflicts (if any)
    6. Force push back to BitBucket - git push --force
    7. You now have a single commit that you can merge. You can even head back into your terminal, switch to your destination branch (probably master) and do the merge manually there (git merge super-awesome-branch)... it'll be a fast-forward and you can then push back to BB. BB will automatically close your PR.

    Rebasing is just shy of the most awesome thing in the world, but it's a shame we can't just click a checkbox to squash.

  34. gary

    Do this on the server side: configure the plugin.stash-scm-git.pullrequest.merge.strategy.KEY.slug=squash-ff-only

    so BitBucket merge will squash and ff every time

  35. Nick Fauchelle

    @benechols @aldango Been a month since the last "update". Ben flipped it almost a week ago and said nothing. Can we please get an update on this and if it's not going to be done this year or at all please let us know instead of just keeping this open.

  36. Dave Ungerer

    Hi Alastair Wilkes

    About 2 months ago you said you can't offer a firm timeline on this. We're hiring more developers and it's becoming a dealbreaker to work without this feature. I'd appreciate if you could give a firm timeline now. I'm hoping to save the effort of having to move to Github.

  37. Abhin Chhabra staff

    Hi all,

    I'm a Bitbucket developer and I've recently started working on implementing squash merging. We currently have squash merging working in our staging environment and the Bitbucket devs are testing it out. We're going to promote this feature to Beta status soon (in a couple of weeks, hopefully) and you'll be able to enable it for yourselves through the "labs" page.

    I'll try my best to report back on the progress of this feature periodically.

  38. Abhin Chhabra staff

    So far, it seems that this feature will be made available to everybody (so Standard). I'll definitely update this ticket if that changes, but I don't suspect it will.

  39. Lance E Sloan 【UMich】


    Thanks for moving this along, @Abhin Chhabra.

    This has been confusing, because I read these documents recently and I didn't understand why I couldn't find the merge-and-squash feature available on

    As it's been explained to me on Atlassian Answers, and Bitbucket Server do not have feature parity.

    I guess Atlassian renamed Stash to Bitbucket Server in order to bring the Bitbucket and Stash products closer together. However, in a case like this, it would have been better for the products to have kept different names. They should have just added "Powered by Stash" messages to the website.

  40. Abhin Chhabra staff


    As promised, squash merges can now be enabled in Bitbucket labs. We are still missing some functionality, but the development is far enough along to start soliciting feedback.

    How to provide feedback: To avoid spamming people who don't want to be involved in further discussions I propose we use this ticket for feedback.


    What currently works

    • Pull request merge dialog contains a dropdown that can be used to choose between having a merge commit and just squashing all your commits on top of the destination.
    • The default commit message changes based on how one wants to do the merge. In the case of squash merges, we use a combination of the commit messages of all the commits being squashed. Obviously, the user should probably edit this commit message, but the default is a good start.

    Known missing functionality

    • The merge dialog in the branch details page, branch list page and compare page does not yet support squashing. These will be rolled out in the coming weeks. (done)
    • Mercurial support for squash merges is planned, but will be implemented after all the merge dialogs are fixed. (we're planning on supporting obsolescence markers for this, so it'll be split into a separate beta feature later).
    • API support is missing.
    • Public documentation has not been updated yet (obviously this should be the last task).
  41. Umang Dhawan

    working great for us, however we are seeing cases when the developers forget to click squash, and it does a regular merge. Is there a way to enforce squash merge as the only merge option for a repo?

  42. Brandon Istenes

    Or better, set a repository or project default merge strategy? Impossible for a whole team to remember to change from default to "squash" with every PR merge.

    As a note, it might have been a better design to put the selection box on the PR page near the "Merge" button rather than on a click-through popup window.

  43. Abhin Chhabra staff

    @Umang Dhawan There is currently no option to do that, but we do want to implement merge strategy management. I can't give any timelines on that feature though. The first version of squash merges (this implementation) is merely the ability to choose squash merges, but that's definitely the end of development around this feature.

  44. Kevin Condon

    When I do a squash merge locally (so that I can set the author), I'd like BB to notice that and let me merge/accept the pull request without adding the unnecessary merge. I really like the auditing and communication we get from pull requests, but I want clean master history and the authorship attribution.

    Also, if I try to do a squash merge from BB after a local squash merge, BB just hangs with the merge button spinning. It will even delete the branch in that scenario if I told it to, and then if I recreate the branch the BB merge will show as merged.

    I suppose I'd most like to have the option to set the author for a squash merge in BB. Just default to the person doing the merge with an entry to set it to someone else; no special logic needed from BB. Bonus points for providing an author drop down menu with entries for the merge author and the set of authors who made commits to the branch.

  45. Bassam Khouri (OoO May 4 - June 3)

    Here's my opinion:

    When using the squash merge, in the commit that's put on the destination branch, set the Author field to the PR author and the Commiter field to the user that pressed the merge button. That will aligned with someone filter PRs via the UI.

  46. Log in to comment