Feature Request: Only allow for --ff merges for PRs

[nunojsa]

Right now, the only way there is for --ff merges is to use the "Rebase and merge" method. However there's something not optimal with this method. Assuming a feature branch has the following history:

commit 2: with commit hash-of-commit-1 ("some subject"), we need....
commit 1: some subject

The issue is that when we reference some other commits hashes that might be present on the feature branch, those hashes won't match anymore the commit after the rebase. Thus, in the master branch the git history won't be really optimal. If we have an option to only allow merges of PRs with --ff, we will keep the commit hashes while not having a new merge commit.

note: I do not want to start a discussion about having merge commits or not (some people like it some don't).

[mwgamble]

Another reason for supporting actual fast forward merges is that if a user has signed their commits, it will ensure those signatures are kept as part of the merge process. Right now the only solution for maintaining these signatures is to create a merge commit.

This obviously isn't an "answer" but apparently I have no other way of adding my feedback to this.

[masklinn]

A third reason for fast-forward merge is if the merge itself needs to contain a merge commit e.g. there are conflicts between the branches and the two can't be reconciled via a rebase, because they're concurrent branches of a project (say, 1.0 and 2.0).

Because Github's UI does not (as far as I know) support merging with conflict resolution, assuming you are not willing or able to disable branch protection you have to "double merge" the branch, with a completely useless and redundant second commit.

This is even more frustrating when you already

Require branches to be up to date before merging

so the fast-forward is valid by definition.

[mxr576]

Related:
#5524
https://github.com/marketplace/actions/merge-fast-forward-only
https://github.com/marketplace/actions/fast-forward-pr
https://stackoverflow.com/questions/60597400/how-to-do-a-fast-forward-merge-on-github

(Kudos to my colleague, @lekob, who collected these.)

[donquixote]

The issue title is a bit weird.
I'd rather call it "Allow fast-forward merges".
The current "rebase and merge" is not a fast-forward merge. It is a rebase, something very different.

To me a good idea would be like this:

• Provide new option for fast-forward merge, if possible.
• Provide option to create an annotated tag. This allows to store date and message without polluting the history with an actual merge commit. The tag could be signed by github, or by the github user.

[danlyons-home]

Building on this, I'd want three options:

• options to fast-forward merge on a pull request itself (both -ff and -ff-only)
• option on a repository and/or branch to change the default merge type in pull requests
• option on a repository and/or branch to disable one or more merge types in pull requests

In general, I never want a merge commit when a fast-forward is possible.

I also have a repository or two where I'd like to enforce --ff-only (at least for merges to main/master). Alas, I can only do so currently by making GitHub PRs off-limits, which is a shame.

[xmo-odoo]

In general, I never want a merge commit when a fast-forward is possible.

I just want to note that I personally disagree with this. Instead I never want a merge commit when a PR has a single commit. Or when the head of the PR is a merge commit (which might be necessary to resolve conflicts).

But I do usually want a merge commit to recapitulate the task when the PR has multiple commits: IME it's common to want to keep the task logically sectioned, but the information of it being a unit should be retained. That's where merge commits show their worth. This is orthogonal to the PR being fast-forward-able.

[dnitsch]

Not to mention that this would finally allow the build once principle to be actually followed if you use or wish to use short_sha as a version tag.
Gitlab Flow would be possible as well which is a much more desirable branching/release strategy for bigger organizations.

I believe this option is available in TFS (AzureDevops Server). as mentioned by @donquixote another merge option is the best way to go about.
it is currently possible to do this via commandline but then you need to allow "people" to push to protected branches.

[Elyytscha]

But I do usually want a merge commit to recapitulate the task when the PR has multiple commits

i would want to squash a pr with multiple commits to one, a branch should be named something like feat/* fix/* chore/* so when i name my branch it should already be clear what should be the one commit message coming from that pr, that makes it easy to really group features and fixes etc. into one single meaningful commit containing all changes made for this fix or feature etc.

[yesudeep]

While it would be great to have this feature built in, I've found success using this GitHub action:

https://github.com/marketplace/actions/fast-forward-merge

[oakkitten]

As a workaround, here's two workflows that allow fast-forwarding either via commenting /fast-forward or applying the label fast-forward, inspired by the comments above. I wish GitHub allowed triggering workflows via reactions on PRs! Anyway,

• these will merge the commits with the same hashes as in PR and no merge commit
• all checks will run as expected
• the PR will be marked as merged with the message such as

  your-repo-name (bot) merged commit 1234567 into main 10 minutes ago

You will need to set up an empty GitHub app for the purpose of generating access tokens. The default token that comes with a workflow, GITHUB_TOKEN, is not suitable as workflows using it cannot trigger other workflows. Here are some instructions to set up a GitHub app. I just named mine the same I named my repo, and you can also set up an avatar for it! So, you:

• set up the app with r/w repo permission (you might also want to add r/w workflow permission if you want to be able to merge PRs that change workflow files),
• add it to your repo,
• put its id and private key in LOKSMITH_ID and LOCKSMITH_PRIVATE_KEY secrets of your repo,
• and create a file .github/workflows/fast-forward.yml with one of the following (this assumes your main branch is called main):

Fast-forward via commenting `/fast-forward`

name: Fast-forward

on:
  issue_comment:
    types: [created, edited]

jobs:
  fast_forward:
    name: Fast-forward
    runs-on: ubuntu-latest
    if: |
      github.event.issue.pull_request &&
      github.event.comment.author_association == 'OWNER' && 
      contains(github.event.comment.body, '/fast-forward')

    steps:
      - name: Generate access token
        uses: tibdex/github-app-token@v1
        id: generate-token
        with:
          app_id: ${{ secrets.LOKSMITH_ID }}
          private_key: ${{ secrets.LOCKSMITH_PRIVATE_KEY }}

      - name: Fetch repository
        uses: actions/checkout@v3
        with:
          token: ${{ steps.generate-token.outputs.token }}
          fetch-depth: 0

      - name: Checkout pull request
        run: hub pr checkout ${{ github.event.issue.number }}
        env:
          GITHUB_TOKEN: ${{ steps.generate-token.outputs.token }}

      - name: Fast-forward & push
        run: |
          export PR_COMMIT=$(git rev-parse HEAD)
          git checkout main
          git merge --ff-only "$PR_COMMIT"
          git push origin main

Fast-forward via applying the label `fast-forward`

name: Fast-forward

on:
  pull_request:
    types: [labeled]

jobs:
  fast_forward:
    name: Fast-forward
    runs-on: ubuntu-latest
    if: github.event.label.name == 'fast-forward'

    steps:
      - name: Generate access token
        uses: tibdex/github-app-token@v1
        id: generate-token
        with:
          app_id: ${{ secrets.LOKSMITH_ID }}
          private_key: ${{ secrets.LOCKSMITH_PRIVATE_KEY }}

      - name: Checkout pull request
        uses: actions/checkout@v3
        with:
          token: ${{ steps.generate-token.outputs.token }}
          fetch-depth: 0

      - name: Fast-forward & push
        env:
          PR_COMMIT: ${{ github.event.pull_request.head.sha }}
        run: |
          git checkout main
          git merge --ff-only "$PR_COMMIT"
          git push origin main

That's it!

[ryanberckmans]

It would be really great for GitHub to execute on this feature request.

GitHub is nearly 15 years old, and there is still no way for a pull request merge to be fast-forward-only (linear history) AND preserve the same commits as pull request source branch.

Today, if you want to preserve commits in your development branch (and not squash them; squashing is great sometimes), you have two bad options

1. merge commits. This is bad because linear history is an excellent risk reduction mechanism for a production build.
2. rebase commits. These would be ok, except when github rebases the commits into linear history, the commit hashes change (they are new commits) even though the patch and metadata are identical. So your development branch itself constantly needs to be rebased on your production branch, because the commits being added to production are newly created by github rebase & merge.

What we need is a fourth option "Fast-forward merge", which requires linear history and only preserves (ie copies) commits from the PR source branch into the target branch.

Please, do this. Thanks!

[gdamore]

💯 * 💯 -- It is inconceivable that GH still hasn't implemented this.

I'd actually be almost as happy if they just made the rebase a "rebase or fast-forward" button, so that it fast forwarded when it can.

[sebandgo]

This is a must feature!

[punkbit]

This feature is a must and can be an advance option and selectable from the dashboard. I’ve been having to —ff-only on my own, as PRs from dev to main in GitHub is a source for headaches. It’s important, make it an experimental feature, let users have linear history please!

[slimshreydy]

Would be very useful to have this feature! We would use this to power a flow for merging commits from main to release. release is never be committed to directly, and ideally it is either strictly at or behind main but never ahead. We have a github action workflow that we run to sync commits from main to release, but unfortunately all three existing methods of merging (merge, squash, rebase) cause some kind of divergence in the history of main and release. The only true way we can keep the histories in sync is by merging main to release locally via git (which allows for an FF merge), and then push that branch, but then we lose the benefits of PRs and protected branches.

[jcgruenhage]

We have a very similar setup with test, qa and prod branches. That worked absolutely fine on GitLab (which we're migrating from), and also works fine on competing self-hosted projects like gitea and forgejo. Have you found a workaround for your setup?

[akloss-cibo]

...but then we lose the benefits of PRs and protected branches.

This isn't strictly speaking true. You can leave the branch protection in place and, as long as there's a PR open that has its requirements met, still push a fast-forward to the protected branch. But yes, only through the CLI, and yes, it's annoying there isn't a "fast-forward merge" option in the web UI. I haven't tried it yet, but it seems combining require linear commit history with disabling merge, squash, and rebase merges might be a sort-of nice solution.

[jcgruenhage]

You can't disable all three. Good to know that pushing a fast forward works when the PR has it's requirements met, that might be a feasible workaround for us.

[akloss-cibo]

Hmm... I wonder if you can use/abuse requiring signed commits to clobber the UI entirely. Of course it is super annoying that we're having this conversation about using unintended consequences of GitHub features to compose the reasonable behavior of "I want linear history".

[acwest]

I was assured by devs at github that they were working on this issue, but there were extensive layoffs shortly after that, so who knows...

[nscott]

I'm about to take my business to a competitor. This is one of the most core parts of an effective git workflow. This needs to be worked on.

[cortexcompiler]

BitBucket had this in 2018: https://bitbucket.org/blog/fast-forward-merges-bitbucket-cloud-default-like

[Qix-]

I had absolutely no idea that this was the case for years and I'm actually quite surprised that Github is doing something non-'standard' here. I didn't actually believe it when I first read about it and had to try it myself. Sure enough, Github is performing full replays of history instead of doing fast-forwards, resulting in different commits. My own personal workflow isn't particular impacted by this but thinking back to professional settings this is starting to paint a picture as to why rebases were so inexplicably problematic when people used the Github UI to do them as opposed to on the command line.

[Qix-]

Update: still somewhat floored this isn't possible on GH two years later. This is making multi-stage releases via review PRs impossible.

[13steinj]

It appears as if I can either

• merge with a merge commit <--> why would I want a merge commit that doesn't really tell me anything when there's no conflicts?
• rebase merge <--> clear to people who know git that it rewrites history
• squash merge <--> nice to have, but again, history is lost; git branch -d errors/warns

"require linear history" doesn't work either for this purpose.

This forces me to merge on the command line (which, by the way, instructions-as-described in enterprise server 3.5 don't actually force a merge commit, but the button does); which I don't know how this plays with "disable pushes to master".

I could have sworn that historically there was some kind of option that would perform a ff-merge, perhaps I've gone insane though.

I guess I'll have to write a bot / app for our CI for this custom procedure? That feels dumb.

[oakkitten]

I guess I'll have to write a bot / app for our CI for this custom procedure? That feels dumb.

Here's my attempt further up.

But I also want to note that if you merely don't have conflicts it doesn't mean that you can fast forward. To be able to fast-forward, your feature branch must be based on the last commit of your main branch. Unless you are willing to update your feature branch every time the main branch is updated, you can benefit from fast forwarding only when there's very few people developing very few feature branches on your project.

[13steinj]

To be able to fast-forward, your feature branch must be based on the last commit of your main branch.

Yeah that's fine. The main thing here is people sometimes make one-commit PRs / features, and doing another merge commit on top of this is silly and confuses people unnecessarily (as much as I'd love to say people should just learn git and good practices, I can't force them to).

I'm fine with merge commits, but if it can be fast forwarded, I'd prefer that. Maybe I want a rebase merge, which is fine too, but that detaches the history for things like git branch -d and should be used with careful intent.

Which is the same reason single commit squash doesn't solve the "I don't want an extra merge commit" problem, because it's really a "I want git to keep track of the history, and I don't want useless merge commits." Because people are lazy and don't fill out the message box; I'd rather have (in order, assuming no conflicts) ff, (rebase + ff or merge (with appropriate message preferrably) or squash) dependent on the individual scenario. If there are conflicts what I'd really want people to do is ladder-tree-stitch merge, but nobody has time for that so any option other than ff as long as the intent is clear and it makes sense.

[cortexcompiler]

If teams work with narrowly scoped microservices and use trunk-based development with short-lived feature branches, then rebasing your branch prior to creating and merging your PR tends to be trivial. This also ensures you control what the commits look like and specifically ensure any merge conflicts are dealt with the way you want. I think at a minimum adding a Fast-Forward merge option on the UI is a must. Allowing that to be enforced would be nice to have after that.

[mikkorantalainen]

As I see it, somebody trying to send pull request using the GitHub UI should be the one doing the rebase and GitHub could offer to do this automatically for them before they submit the pull request. If a merge could be done without a conflict, the rebase should result in perfectly identical state but with simpler history.

Rebasing your code to allow fast-forward should be the default and true merges should be reserved for special cases.

[acwest]

Generally if there are no conflicts, it is fairly trivial to rebase with main before commiting, and, in fact, the user interface already supports doing so automatically.

…

On Fri, Jul 14, 2023 at 6:09 AM oakkitten ***@***.***> wrote: I guess I'll have to write a bot / app for our CI for this custom procedure? That feels dumb. Here's my attempt <#4618 (comment)> further up. But I also want to note that if you merely don't have conflicts it doesn't mean that you can fast forward. To be able to fast-forward, your feature branch must be based on the last commit of your main branch. Unless you are willing to update your feature branch every time the main branch is updated, you can benefit from fast forwarding only when there's very few people developing very few feature branches on your project. — Reply to this email directly, view it on GitHub <#4618 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAANTD3OJECIVUXLNFGE7MDXQELF5ANCNFSM5AI3TFGQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.*** com>

[chrisnc]

It's mentioned elsewhere in this thread that the rebase merge in the web UI always rewrites the commits, even if a fast-forward were possible.

[mauricioklein]

Also, not all teams uses a merge to main strategy.

Some have an intermediary branch (e.g. staging, preprod, etc), and this would require a manual reconciliation of main's new commit hashes with the original commits in the intermediary branch.

[acwest]

To do the rebase and merge from the command line: git pull --rebase origin main git branch -D main git branch -m main git push origin main

…

On Sat, 15 Jul 2023, 15:30 Chris Copeland, ***@***.***> wrote: It's mentioned elsewhere in this thread that the rebase merge in the web UI always rewrites the commits, even if a fast-forward were possible. — Reply to this email directly, view it on GitHub <#4618 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAANTD43FZCUFKGWQPXF7O3XQLVTRANCNFSM5AI3TFGQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.*** com>

[chrisnc]

The command-line workaround has been discussed extensively here and elsewhere. This thread is a feature request for the GitHub web UI so this is not required. The situation being described is where the PR is already fast-forwardable and does not require a rebase. This can be done with one step:

git push origin origin/<branch>:<base>

[acwest]

My comment was more in reference to difficulties if there other commits the need to be rebased. The ui is able to handle this in the non-fast-forward case automatically, so it should be no difficulty to do so with fast forward. My example command was a demonstration that it is trivial to actually do, as long as there are no conflicts.

…

On Sat, 15 Jul 2023, 17:47 Chris Copeland, ***@***.***> wrote: The command-line workaround has been discussed extensively here and elsewhere. This thread is a feature request for the GitHub web UI so this is not required. The situation being described is where the PR is already fast-forwardable and does not require a rebase. This can be done with one step: git push origin origin/<branch>:<base> — Reply to this email directly, view it on GitHub <#4618 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAANTDY4VL2N3DWDX22PGE3XQMFY5ANCNFSM5AI3TFGQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.*** com>

[ian-twilightcoder]

The pull/rebase will break any commit signatures

[chrisnc]

Read the rest of the thread for why "it should be no difficulty" is not accurate. If GitHub's merge-with-rebase option would fast-forward when possible, it would be a little better, but it doesn't.

[acwest]

I'm saying with little difficulty on THEIR part. The fact that they haven't done it is the problem, but it is certainly doable

…

On Sat, 15 Jul 2023, 18:35 Chris Copeland, ***@***.***> wrote: Read the rest of the thread for why "it should be no difficulty" is not accurate. If GitHub's merge-with-rebase option would fast-forward when possible, it would be a little better, but it doesn't. — Reply to this email directly, view it on GitHub <#4618 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAANTDZ54AR25QRLLKYBCXTXQMLMRANCNFSM5AI3TFGQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.*** com>

[jwgcooke]

Is there any feedback from Microsoft/Github on this? This is a deal killer for us migrating off of Bitbucket and it is such a fundamental feature of git.

[acwest]

The last time I talked to an actual github dev was probably 2020 or so, and I don't think there has been any word from them since then...

…

On Wed, 2 Apr 2025 at 11:54, Gordon Cooke ***@***.***> wrote: Is there any feedback from Microsoft/Github on this? This is a deal killer for us migrating off of Bitbucket and it is such a fundamental feature of git. — Reply to this email directly, view it on GitHub <#4618 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAANTDZ7BESDTPYIRKGH2C32XQB3ZAVCNFSM5AI3TFG2U5DIOJSWCZC7NNSXTOSENFZWG5LTONUW63SDN5WW2ZLOOQ5TCMRXGAZDSMRU> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[acwest]

There has never been a good reason to NOT do fast-forward merges when it is possible. The only real reason I have seen for the current behaviour is that git hashes get regenerated, so some actions get triggered that wouldn't be, allowing for billing of more computer time...

…

On Wed, 2 Apr 2025 at 16:15, Mikko Rantalainen ***@***.***> wrote: As I see it, somebody trying to send pull request using the GitHub UI should be the one doing the rebase and GitHub could offer to do this automatically for them before they submit the pull request. If a merge could be done without a conflict, the rebase should result in perfectly identical state but with simpler history. Rebasing your code to allow fast-forward should be the default and true merges should be reserved for special cases. — Reply to this email directly, view it on GitHub <#4618 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAANTD2TYFRGCAKTAU5CYTD2XRAMLAVCNFSM5AI3TFG2U5DIOJSWCZC7NNSXTOSENFZWG5LTONUW63SDN5WW2ZLOOQ5TCMRXGA3DAOJT> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[magnus-lindstrom]

I would love if a maintainer could please comment on whether or not they are looking into fixing this issue or not in the future. Or if you want to do it but don't have the time currently.

[Qix-]

Github post-acquisition has nearly zero public outreach, publicly or privately. I wouldn't hold my breath.

[Louis-Bon]

Why do I land here in 2025, it's crazy

[prvg-sso]

+10000000000000000000000000000000000000000000000
again ...

[nandojve]

I'm wondering how many years are necessary to implement this.

[felixakiragreen]

We now have agent coding inside Github...

But still have no way to merge a branch into master, and have them maintain the same linear history. (Without an external action)

[acwest]

Back around 2019 or so, when I worked for a large enough company to actually have leverage on Github, their developers assured me this was a priority. Shortly afterwards I believe there were extensive layoffs at Github, and I was never able to talk to their devs again...

[mu88]

Oh GitHub, really? 🥴 I mean... REALLY? 😮 If I'd been sitting on a chair, now would be the moment to fall from it...

[lauren-martini]

Switched from GitLab to GItHub and was absolutely shocked that this is not an option. BitBucket supports -ff merges in PRs as well. Wild to see people discussing this issue years ago and have no resolution or even news.

[dominik-rubo-brutex]

For those who really need this feature, Gitea or one of its forks may be worth considering. I have found it to be nearly a drop-in replacement for GitHub, with some nice additional features, including this one. It's free and open source.

[simenkjernlie]

Just switched from Bitbucket and took this possibility for granted. Please include it.

[jcoelho-aurascape]

I was wondering why every time I synced main with the release branch I got this weird branch divergence behavior....
Hopefully github fixes this soon

[joe-cisar]

Don't hold your breath. Anyone know how to make this feature request go viral?

[rettichschnidi]

Anyone know how to make this feature request go viral?

My take: https://news.ycombinator.com/item?id=45057046

[acwest]

I was having some success at getting their attention by working for a very large company who pays them a LOT of money, but then they laid off everybody who was working on this

[AndreaPontrandolfo]

I was having some success at getting their attention by working for a very large company who pays them a LOT of money, but then they laid off everybody who was working on this

This is crazy!

[mdalpozzo]

plus one to this issue. absolutely unbelievable. please github please. i've worked so hard on my github repo configuration don't make me migrate back to gitlab