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

因此，我的一个同事尝试在 web 界面中使用 GitHub 的“通过快进进行合并”选项来合并一个分支，以保持历史清晰，避免伪造的合并提交(他们合并进去的 master分支，自即将合并的功能分支启动以来一直没有进展)。

有趣的是，这并没有像预期的那样工作: 所有的提交都得到了新的提交哈希。

仔细观察，似乎合并选项实际上被称为“ Rebase and Merge”，它似乎真的做了相当于 git rebase --force的事情，改变了 委托人的信息(包括合并的人和合并发生的时间)。

我花了很长时间才证实了我的怀疑，因为我无法使用 cmdline 工具向我展示特性分支上的原始提交和主分支上看似相同的提交(使用不同的散列)之间的区别。 (最后，我发现 gitk同时显示了提交者和作者的提交; 在 非常端，我发现我也可以通过 git log --pretty=raw获得这些信息)

所以:

  • 有没有一种方法可以通过 GitHub 的 web 界面进行“适当的”快进合并(git rebase 没有和 --force选项) ？
  • 如果没有，为什么？(我可以看到问责制的优点; 例如，它回答了谁应该对某段代码最终出现在 master中负责的问题)
16949 次浏览
小开
最佳答案

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

GitHub 上的 rebase 和 merge 行为略微偏离了 git rebase。基于 GitHub 的 Rebase 和 merge 将始终更新提交者信息并创建新的提交 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 UI 运行原子的线性提交策略(最好的策略)。

请注意，Bitbucket DOES 支持这一点，并且有更多细粒度的选项来设置 PR 着陆/集成策略。也就是对目标/主线分支执行 --ff-only更新的 “重定基，快进”选项。它还有一个 “重新基地，合并”选项，允许您在目标上运行 rebase (这样您的提交是线性的) ，但是可以使用合并提交(如果您想跟踪提交都是一个逻辑单元/PR 的一部分)进行集成。

这两个选项似乎都优于 GitHub 的有限选项，无论是使用非线性合并提交(GitHub 的 “合并请求”选项)还是线性重建(‘ Rebase and merge’选项) ，后者确实实现了线性提交，但在源代码分支上产生了重复提交，因此如果你想保持清洁和同步，总是需要在本地手动硬重置。

所以... 看来是时候换回购供应商了！

小开

可以通过命令行进行快进合并，然后将其推送到 Github。Github pull request CLI 指令确实明确表示要使用 git merge --no-ff，但它似乎也可以使用快进，它保留 git 提交散列并关闭打开的 pull 请求:

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

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

小开

根据其他人的说法，GitHub 似乎并不通过他们的 web UI 来支持这一点。我也不知道该怎么做。它适用于命令行，就像前面提到的(git merge --ff-only ...)一样，但是似乎没有相应的 UI。

我很抱歉提到了一个竞争产品，吉塔。Gitea 有一个非常类似于 GitHub 的 UI，并且这个 UI 有三个相同的合并 PR 的方法。然而，与 GitHub 不同的是，第三个标签为“ Rebase and merge”的文件，如果不需要重新定位，它会自动进行快速合并。就是这样。所以我不明白你为什么不能在 GitHub 上做。

小开

另一种方法是建立一个 快进公关 GitHub Action:

如果可能，仅使用快进移动基地合并拉请求 分支(目标分支)到头部分支(源分支)。注释成功 或故障消息上的请求问题。目标是保持 分支在合并结束时相等。


提交答案