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

Question

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

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

仔细检查一下，似乎合并选项实际上被称为“Rebase and Merge”，它似乎确实相当于git rebase --force改变了提交者信息（进行合并的人以及合并发生的时间）。

我花了很长时间才确认我的怀疑确实如此，因为我无法使用 cmdline 工具向我展示功能分支上的原始提交和看似相同的提交（具有不同的哈希值）之间的区别在主分支上。（最后，我发现，gitk同时显示了提交者和提交作者;在非常最后我发现我也能得到通过这些信息git log --pretty=raw）

所以：

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

Answer 1

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

请注意，Bitbucket 确实支持这一点，并且具有用于设置 PR 登陆/集成策略的更细粒度的选项。即更新目标/主线分支的“Rebase, fast-forward”选项--ff-only。它还有一个“Rebase，merge”选项，它允许你在目标上运行一个 rebase（即：这样你的提交是线性的）但使用合并提交进行集成（如果你想跟踪提交都是一个逻辑单元的一部分/公关）。

这两个选项似乎都优于 Github 的有限选项，即使用非线性合并提交（Github 的“合并拉取请求”选项）或线性变基（“变基和合并”选项），后者确实实现了线性但会在源上创建重复提交分支，因此如果你想保持干净和同步，总是需要在本地手动硬重置。

所以......似乎是时候切换你的回购提供者了！

Answer 2

根据 GitHub 的文档和我自己的测试，不可能使用相同的提交哈希进行快进。

GitHub 上的 rebase 和合并行为与 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

Answer 3

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

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

Answer 4

可以通过命令行进行快进合并，然后将其推送到 Github。Github 拉取请求 CLI 指令确实明确说要使用git merge --no-ff，但它似乎也适用于快进，它保留 git commit 哈希并关闭打开的拉取请求：

$ git checkout master
$ git merge your-branch # the branch which has an open pull request
$ git push

此时，Github 会自动检测到分支已合并，并关闭拉取请求。如果您在 Web 浏览器中打开了“拉取请求”页面，您将看到它异步地将状态更改为："X 合并提交到主"，"拉取请求成功合并并关闭"。