如何在 GitHub 上进行快进合并？答案

【问题标题】：How to do a fast-forward merge on GitHub?如何在 GitHub 上进行快进合并？
【发布时间】：2020-06-21 03:45:48
【问题描述】：

因此，我的一位同事尝试在 Web 界面中使用 GitHub 的“通过快进合并”选项合并分支，以保持历史记录免受虚假合并提交的影响（他们合并到的 master 分支，有自从要合并的功能分支开始后没有进展）。

有趣的是，这并没有按预期工作：所有提交都有新的提交哈希。

仔细观察，merge-option 似乎实际上被称为“Rebase and Merge”，它似乎确实相当于 git rebase --force，改变了 Committer 信息（两者都是是否进行了合并，以及合并发生的时间）。

我花了很长时间才确认我的怀疑确实是这种情况，因为我无法让 cmdline 工具向我展示功能分支上的原始提交和看似相同的提交之间的区别（使用不同的哈希）在主分支上。（最后我发现gitk同时显示了提交的Committer和Author；在非常结尾我发现我也可以通过git log --pretty=raw获取这些信息）

所以：

有没有办法通过 GitHub 的网络界面进行“适当的”快进合并（git rebase 没有 ~~--force~~ 选项）？李>
如果不是：为什么？（我可以看到问责制的优点；例如，它回答了谁对给定的代码最终出现在 master 负责的问题）

【问题讨论】：

标签： github git-merge fast-forward

【解决方案1】：

看起来 GitHub 不支持这一点——这是一件可怕的事情。您基本上不能使用 GitHub UI 运行原子的线性提交策略（最好的）。

请注意，Bitbucket 确实支持这一点，并且有更多细粒度的选项来设置 PR 登陆/集成策略。即 'Rebase, fast-forward' 选项，它对目标/主线分支进行--ff-only 更新。它还有一个 'Rebase, merge' 选项，可让您在目标上运行 rebase（以便您的提交是线性的），但使用合并提交进行集成（如果您想跟踪所有提交一个逻辑单元/PR的一部分）。

这两个选项似乎都优于 GitHub 使用非线性合并提交（GitHub 的 'Merge pull request' 选项）或线性变基（'变基和合并' 选项），它确实实现了线性，但会在源分支上创建重复提交，因此如果你想保持干净和同步，总是需要在本地手动硬重置。

所以...看来是时候更换你的 repo 提供商了！

【讨论】：

“因此，如果你想保持清洁和同步，总是需要在本地手动硬重置”
好的，我刚刚理解了这个问题。这太可怕了！

【解决方案2】：

根据 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

【讨论】：

值得一提的是，你可以从命令行打开pull-request并合并它并push它，github将关闭PR作为合并

【解决方案3】：

可以通过命令行进行快进合并，然后将其推送到 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 合并提交到 master”，“拉取请求成功合并并关闭” .

【讨论】：

好吧，我明确地询问如何“通过 GitHub 的 Web 界面”进行操作。（为了完整起见，很高兴您提到 github 明确承认此类合并）
确实，当主分支受到保护时，这甚至是不可能的。因此，必须手动执行这些步骤不仅仅是麻烦，有时甚至无法执行这些步骤。
@m-d 我也担心分支保护会阻止我使用此答案中的建议。但是，经过一些实验，我发现分支保护可以与此共存。
@bain 很高兴您为完整性提供了这个答案。它让我尝试了这种 CLI 方法，否则我认为它会被我的分支保护阻止。但它与分支保护并存！我的保护设置是：Require status checks to pass before merging、Require branches to be up to date before merging 和 Include administrators ...但只要我推送的提交是状态检查的 PR 的一部分，我就可以直接推送到受保护的分支确实已经通过了。这对我来说是个好消息。

【解决方案4】：

另一种方法是设置Fast Forward PR GitHub Action：

如果可能，仅使用快进合并拉取请求，移动基地分支（目标分支）到头分支（源分支）。评论成功或有关拉取请求问题的失败消息。目标是保持合并结束时分支相等。

【讨论】：

截至 2021 年 11 月 15 日，我试过这个，但似乎不起作用github.com/endre-spotlab/fast-forward-js-action/issues/…

【解决方案5】：

根据其他人的说法，GitHub 似乎并不通过他们的 Web UI 支持这一点。我也没有想好怎么做。它适用于命令行，就像其他人提到的 (git merge --ff-only ...)，但似乎没有等效的 UI。

对于提及竞争产品Gitea，我深表歉意。 Gitea 与 GitHub 有一个非常相似的 UI，并且 UI 具有相同的三种合并 PR 的方法。然而，与 GitHub 不同的是，第三个标签（“Rebase and merge”）在不需要 rebase 时会自动进行快进合并。它只是工作。这就是为什么我不清楚为什么你不能在 GitHub 上这样做。

【讨论】：