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-softek]

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.

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

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

[giovannicandido]

This is one thing that makes me look for alternatives to GitHub. Although I do like the service a lot, this is such a strategic feature, as explained by the other comments, that at first, I didn't believe GitHub did not have this option, so I had to try it for myself, and none of the merge strategies do that.
I also want a linear history with no rewriting (no rebase) to keep the original author's signature in the main branch and force only employees to commit to the branch guaranteed by signature. The closest is the merge commit but it polute the main branch with useless forced commits that are signed by the github bot and as I release each commit to main with a new commit that alters the source code automatically with the new version, this force a 3 commit for a single release.

[giovannicandido]

By forcing a history rebase, kind of looks like GitHub wants to be the author of all commits. 😒

[izaakschroeder]

Adding my voice to the pile 😄 this is one of the things that's potentially stopping us from migrating from BitBucket which has this feature.

[davidreis97]

It's crazy how GitHub doesn't support this.

[alexeymenkov]

I was surprised when realized github doesn't support --ff. Outdated bitbucket allowed us to have linear history and avoid all these problems with signed commits, inability to delete all merged local branches, etc

it seems to be easier to use another tool than get this feature :)

[sebmellen]

In case anyone is still having issues with the lack of -ff merges, this may help: Protected GitHub fast-forward commit action with Mergefreeze [Github Gist].

This is not an ideal solution, and it will cost your organization an additional $40/month, but it works well. We spent a lot of time figuring it out. Mergefreeze, combined with the action, prevents you from accidentally merging via the default web UI options by blocking them using a branch protection rule. The fast-forward action blocks all commits to your desired branch that don't use the action.

When run by adding a /fast-forward comment to your PR, the action temporarily suspends the required Mergefreeze branch protection rule, merges the commit to your desired branch through the CLI, and then adds back the branch protection rule. This avoids any mistaken merge/rebase commits, and it works just as fast as merging using the traditional web UI options.

CC @giovannicandido / @izaakschroeder / @davidreis97 / @alexeymenkov / @jraczykowski / @d81853embitel-de / @ryanberckmans / @Fab1n / @mauricioklein in particular, as you all seem to have experienced this issue recently 🙏 .

[davidreis97]

I love the idea and hope you have great success with it but I'll avoid the extra dependency and complexity and just disable rebasing as a merge strategy, at the cost of not having a linear history.

…

On Tue, 16 Jan 2024 at 02:38, Sebastian Mellen ***@***.***> wrote: In case anyone is still having issues with the lack of -ff merges, this may help: Protected GitHub fast-forward commit action with Mergefreeze [Github Gist] <https://gist.github.com/sebmellen/639904445118be908cbe3c23d9797d46>. This is not an ideal solution, and it will cost your organization an additional $40/month, but it works well. We spent a lot of time figuring it out. Mergefreeze, combined with the action, prevents you from accidentally merging via the default web UI options by blocking them using a branch protection rule. The fast-forward action blocks all commits to your desired branch that don't use the action. When run by adding a /fast-forward comment to your PR, the action temporarily suspends the required Mergefreeze branch protection rule, merges the commit to your desired branch through the CLI, and then adds back the branch protection rule. This avoids any mistaken merge/rebase commits, and it works just as fast as merging using the traditional web UI options. CC @giovannicandido <https://github.com/giovannicandido> / @izaakschroeder <https://github.com/izaakschroeder> / @davidreis97 <https://github.com/davidreis97> / @alexeymenkov <https://github.com/alexeymenkov> / @jraczykowski <https://github.com/jraczykowski> / @d81853embitel-de <https://github.com/d81853embitel-de> in particular, as you all seem to have experienced this issue recently 🙏 . — Reply to this email directly, view it on GitHub <#4618 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADXDBG5CINSPKTUI5C6E74DYOXRZ5AVCNFSM5AI3TFG2U5DIOJSWCZC7NNSXTOKENFZWG5LTONUW63SDN5WW2ZLOOQ5TQMJTHEYTONQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[sebmellen]

Definitely a reasonable alternative!

For us, we have a deployment workflow which requires staging and production to always be downstream of our main branch, so merge commits don't work (because they actually accelerate our downstream branch some number of commits ahead of main! Horribly confounding... Hopefully this action set can help others who are in our shoes as well.

[YohanGrember]

Please add an option to only allow ff merges!

[ashleyww93]

This would simplify our workflow, we have a production branch that is protected so we can pass SOC2 checks.

We have to open a PR from main to prod, even after the PRs have already been merged into main where we ensure that no PRs can be merged without approval etc.

Having an option to allow FF from specific branches would be great for us.

[sebthom]

Gitea will support this with the next release. See go-gitea/gitea#28954

[theoparis]

I'm moving to my own gitea instance because of this. 🚀
(also because of the current lack of ipv6 support 😕 )

[yesudeep]

Please add this!

[Elyytscha]

it is absolutly insane that this is missing

just to quote a stackoverflowman which represents my opinion
"..and this is a TERRIBLE affair. You basically CANNOT run an atomic, linear commit strategy (the best there is) using the GitHub UI."

[francisrafal]

We also need this please!

[yesudeep]

I've found that this GitHub action works: https://github.com/marketplace/actions/fast-forward-merge and preserves commit signatures.

Consider adding an alias for gh to make it convenient:

gh alias set submit 'pr comment --body "/fast-forward"'

Use a rebase-based workflow with this.

Submit your PR from the command line:

gh submit

[fuch1m]

Please add this!

[ryanberckmans]

Another reason to do this:

GitHub is wasting a lot of compute on redundant workflow runs for rebased commits that could have been fast-forwarded.