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!

[sebandgo]

This is a must feature!

[heldrida]

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.

[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.

[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>

[acwest]

if you check the co. mit has he's, before and after the merge, they have changed. Which is totally unnecessary and breaks many things

…

On Fri, 4 Oct 2024, 15:39 Alec Kloss, ***@***.***> wrote: I just tried a squash merge... still sqashes, no fast-forward: % git show origin/test-main commit 4ba75f8979b9781761764258a2d39d094e509406 (origin/test-main) Author: Alec Kloss ***@***.***> Date: Fri Oct 4 14:36:55 2024 -0500 test (#1783) % git show test-topic commit 9d356a27684d9372a4d0f893ee4d21b1a43829e7 (HEAD -> test-topic, origin/test-topic) Author: Alec Kloss ***@***.***> Date: Fri Oct 4 14:35:50 2024 -0500 test % git diff test-topic..origin/test-main % I think the log message makes it pretty obvious it's a new commit. — Reply to this email directly, view it on GitHub <#4618 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAANTDYIIAW2EXEL5A7TFHTZZ3VHVAVCNFSM5AI3TFG2U5DIOJSWCZC7NNSXTOSENFZWG5LTONUW63SDN5WW2ZLOOQ5TCMBYGQ4DAOJT> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[wendyzhaogogogo]

looking forward to fastward feature

[raksorakso]

Shocking that Github does not have this feature. This is a clear selling point for Gitlab/Bitbucket.

[acwest]

Elias, the difference between fast-forward and squash is with fast-forward, the head of the destination branch is moved to point to the head of the source branch. With squash, all of the commits in the source branch are squashed down to one commit, and that commit is applied to the head of the destination branch. I normally do both, where I squash the source branch, and then fast-forward merge it to the destination. The main visible difference between doing it my way, and just squashing, is that with fast forward, the commit hashes are the same on both branches at the end, which helps eliminate extra builds by the CI system

…

On Wed, 9 Oct 2024 at 03:59, Elias Rami ***@***.***> wrote: but still there are no merge commits anymore with squash, which is normally what fast forward does? i'm 100% sure there where merge commits with squash a few months before. — Reply to this email directly, view it on GitHub <#4618 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAANTDZA7IZ5INLGRS7IFEDZ2TO7RAVCNFSM5AI3TFG2U5DIOJSWCZC7NNSXTOSENFZWG5LTONUW63SDN5WW2ZLOOQ5TCMBYHA4TCNJW> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[soham-suki]

It's kinda crazy that this option isn't available. I wonder why? I don't see any downsides of allowing users to fast-forward.

[alchatti]

This is related to https://github.com/orgs/community/discussions/8940

[andrei-pump]

This is a very useful and basic functionality of Git. What blocks its implementation?

[jamesmazur]

How is this not supported yet? Please add this.

[sanford-freedman-philips]

Please add support for this.

[sandmmakers]

Please support this.

[sandytf]

The usability of Github is severely restricted by this feature not being present. Please add it.

[sankethm22]

Please add support for this!

[at-ng]

@sankethm22 @sandytf @sandmmakers Spam like this is only going to make people unsubscribe. Use the upvote button to show your support instead.

[arielyumul]

I need the fast forward merge capability for the Github release branching strategy please add this feature.

[hellogerard]

I feel like we're shouting into the wind at this point, but I just came back to GitHub after a few years of using GitLab. Am trying to setup the release procedure that we want and was SHOCKED to find that I could not merge with fast forward to my target branch. We have semi-business users doing the final merge of release PRs, so I do NOT want to tell them to merge via command-line. It's 2024, how is this not implemented yet in GitHub? 😡

[andreisilviudragnea]

Not having this feature promotes bad Git practices. Also many new people learn Github before Git, they do not even know they can use fast-forward merge.

I found a solution for this problem though. If you enable only merge commits on repository level and linear history together with only rebase as merge method on a brach protection rule, the PRs targeting that branch can be merged only from Git CLI using ff merge, because the GitHub UI will not allow it:

[acwest]

That's fairly clever, I knew there was a way to set that up, but I hadn't quite figured it out...