因此，我的一位同事试图在 Web 界面中使用 GitHub 的“通过快进合并”选项合并一个分支，以保持历史记录免受虚假合并提交的影响（master他们合并的分支，自那时起就没有进展——被合并的功能分支已启动）。
有趣的是，这并没有按预期工作：所有提交都有新的提交哈希。
仔细观察，似乎合并选项实际上被称为“Rebase and Merge”，它似乎确实等同于git rebase --force改变提交者信息（进行合并的人，以及合并发生的时间）。
我花了很长时间才确认我的怀疑确实是这种情况，因为我无法让 cmdline 工具向我展示功能分支上的原始提交和看似相同的提交（具有不同的哈希）之间的区别在主分支上。（最后，我发现它gitk同时显示了提交的提交者和作者；最后我发现我也可以通过 获取此信息git log --pretty=raw）
所以：
git rebase ？--forcemaster）看起来 GitHub 不支持这一点——这是一件可怕的事情。您基本上不能使用 GitHub UI 运行原子的线性提交策略（最好的）。
请注意，Bitbucket 确实支持这一点，并且有更多细粒度的选项来设置 PR 登陆/集成策略。即更新目标/主线分支的“变基，快进”选项。--ff-only它还有一个“变基，合并”选项，可让您在目标上运行变基（以便您的提交是线性的）但使用合并提交进行集成（如果您想跟踪提交都是一个逻辑单元/ PR的一部分）。
这两个选项似乎都优于 GitHub 使用非线性合并提交（GitHub 的“合并拉取请求”选项）或线性变基（“变基和合并”选项）的有限选项，后者确实实现了线性，但会在源上创建重复提交分支，因此如果你想保持干净和同步，总是需要在本地手动硬重置。
所以......似乎是时候切换你的回购提供商了！
根据 GitHub 的文档和我自己的测试，不可能使用相同的提交哈希进行快进。
GitHub 上的变基和合并行为与 git rebase 略有不同。GitHub 上的变基和合并将始终更新提交者信息并创建新的提交 SHA，而当变基发生在祖先提交之上时，GitHub 外部的 git rebase 不会更改提交者信息。有关 git rebase 的更多信息，请参阅 Pro Git 书中的“Git rebase”一章。
https://docs.github.com/en/github/administering-a-repository/about-merge-methods-on-github
可以通过命令行进行快进合并，然后将其推送到 Github。Github 拉取请求 CLI 指令确实明确表示使用git merge --no-ff，但它似乎也可以使用快进，它保留 git 提交哈希并关闭打开的拉取请求：
$ git checkout master
$ git merge your-branch # the branch which has an open pull request
$ git push
此时，Github 会自动检测到分支被合并，拉取请求将被关闭。如果您在 Web 浏览器中打开了“拉取请求”页面，您将看到它异步更改状态为：“X 合并提交到主服务器”、“拉取请求成功合并并关闭”。
另一种方法是设置Fast Forward PR GitHub Action：
如果可能，仅使用快进合并拉取请求，将基础分支（目标分支）移动到头分支（源分支）。在拉取请求问题上评论成功或失败消息。目标是在合并结束时保持分支相等。
根据其他人所写的，GitHub 似乎并不通过他们的 Web UI 支持这一点。我也没有想好怎么做。它适用于命令行，就像其他人提到的（git merge --ff-only ...）一样，但似乎没有 UI 等价物。
我很抱歉提到一个竞争产品，Gitea。Gitea 与 GitHub 有一个非常相似的 UI，并且 UI 具有相同的三种合并 PR 的方法。然而，与 GitHub 不同的是，第三个标签（“Rebase and merge”）在不需要 rebase 时会自动进行快进合并。它只是工作。这就是为什么我不清楚为什么你不能在 GitHub 上这样做。