Merge option with rebase autosquash

It would be nice to have an autosquash option in github merge button, this will help people to check for corrections in github review.
Send a PR

 - Test commit
Fix the PR after the review with fixup!:

 - Test commit
 - fixup! Test commit

And, if the PR is approved and merged the history could be:

 - master old commit

 - Test commit

Right now we have already some good merge options here

But rebase with –autosquash option, and not a normal squash or merge could help us to do better reviews and catchup corrections around the commit history. 


I want to make sure I understand what you’re requesting. How is what you’re proposing better than doing a rebase with autosquash before the PR is merged and then using the standard merge options?

1 Like

When doing rebase with autosquash before the PR you must _force push _if any fixup comes up.

If you can rebase with autosquash on GitHub, no force push is needed.


I, too, would like to see an --autosquash option in the web interface.

Github’s support for working with forced pushes is less than stellar. In general it’s hard to figure out what changed between revisions and in turn this makes it harder to keep track of comments. Only for providing a comparison point, Gerrit supports a workflow where forced pushes are more common, only that it does not call it that, nor are those necessary. In Gerrit each revision gets its own pseudo-branch so it’s possible to compare between revisions as if you were comparing branches. In Github by contrast this does not exist, so there are two options:

  1. Add new commits, never force-push. If the intention of the developer is to merge a single commit, they can choose to squash the whole thing and all the PR noise disspaears. If they don’t do this and simply merge the PR as is, you end up with a lot of PR noise in the repository (“fixing linter errors”, “addressing comments”, “fix build error”, “merge master into …”, etc).

  2. Locally fix the commits, force-push. This keeps a clean history, but it makes it harder to work with the web UI.

Option 1 also makes it hard to create a PR that contains multiple clean steps: “adding API for this”, “using new API for that”, etc.

If Github supported the git convention of “fixup!” it would be possible to use 1. and simply rebase and squash when it’s time to merge the PR into the target branch. This would make it easier to keep track of the changes and comments, and works better with the existing web UI.


Hi, Please check @mem answer, I couldn’t describe it better.

Indeed, @mem nails it. Fixup commits allow iteratively working on things and providing a clear timeline of changes to reviewers while enabling a clean commit when rebasing. If Github enabled the “–autosquash” option when doing rebase&merge on the web UI, we wouldn’t have to go through the hassle of locally rebasing and force-pushing before merging once the PR is approved, and the commit message would be cleaner than when using squash&merge.

In addition, commit suggestions via the review UI should use the fixup convention rather than generic and not so meaningful messages.

1 Like

I agree with all of this, and want to add another reason I think having an autosquash feature would be beneficial.

If you have the option ‘Dismiss stale pull request approvals when new commits are pushed’ enabled, then doing an autosquash locally and force-pushing will dismiss all approvals, which means that reviewers need to re-approve.

If a reviewer wants to ensure that this force-push didn’t change anything to the final state (which is not a bad idea), they can fetch the updated repository and compare the commits mentioned in ‘x force-pushed from a to b’ and ensure that there are no file differences between a and b (which saves a complete re-review). This adds a lot of extra work for reviewers.

If github had an option to do an autosquash before merging this would solve the whole re-approve issue.


In addition to this, it’s easy to forget to merge in the --fixup commits and then you’re sort of stuck with them (rewriting history on shared branches is often painful; we just leave them there).

Allowing the autosquash and/or blocking (or at least warning!) when there are unsquashed --fixup commits before merging would be great.

1 Like

Also, in addition to what was pointed out, I am bringing two points that show us that this feature is highly desirable:

  • The community has been using this workflow by other means, like with the tibdex/autorebase.
  • Other communities like atlassian and gitlab are also trying to have this workflow integrated with the web UI.