为什么 Github 中的“rebase and merge”选项会创建新的提交 SHA？有替代方案吗？答案

【问题标题】：Why does the "rebase and merge" option in Github create new commit SHAs? Is there an alternative?为什么 Github 中的“rebase and merge”选项会创建新的提交 SHA？有替代方案吗？
【发布时间】：2018-06-29 05:41:47
【问题描述】：

我喜欢在 Github 中使用“rebase and merge”选项来合并 PR，以避免合并提交导致提交历史混乱。

但我注意到以下行为：（来自 Github 的docs）

GitHub 上的变基和合并行为与 git rebase 略有不同。 GitHub 上的 rebase 和 merge 将始终更新提交者信息并创建新的提交 SHA，而当 rebase 发生在祖先提交之上时，GitHub 外部的 git rebase 不会更改提交者信息。

这对我来说似乎很奇怪，因为这不是 git CLI 中 rebase 的工作方式。有谁知道它为什么会这样？

理想情况下，我希望 a) 避免引入合并提交和 b) 保留功能分支中的提交 SHA 和标签。有没有办法从 UI 中做到这一点？

【问题讨论】：

标签： github

【解决方案1】：

您的赞赏是正确的，这不是 rebase 在 git 中的工作方式。原因在于 GitHub 中的一些选项名称不正确：

Squash and Merge：类似于 squash 和 rebase
变基和合并：类似于带有--no-ff 选项的变基（即使提交是最新的，也会引入新的提交）

如果您使用的是“GitHub Desktop”应用程序，您应该会看到其他不熟悉的名称，例如“Sync”而不是“Pull”+“Merge”+“Push”。

【讨论】：

“Rebase and Merge”提交是否与 ff 选项合并？
我不太明白这个问题，但快进意味着如果一个提交是另一个提交的祖先，则不会进行新的提交。
您说变基和合并“实际上是带有 --no-ff 选项的变基” - 我引用的文档似乎表明相反。
文档是正确的：Rebase and Merge 是一个变基，即使在快进（和最新）场景中它也会引入新的提交（所以它不会快进，这是就像说它使用-no-ff 选项）。我更新了答案以使其更清晰。

【解决方案2】：

两个都想要

a) 避免引入合并提交

您不会创建任何合并提交，因为文档提到：

主题分支（或头分支）的所有提交都单独添加到基础分支中没有合并提交。
使用 fast-forward option 合并具有重新提交的拉取请求。

还有：

b) 保留功能分支中的提交 SHA 和标签。

任何变基（在 GitHub 上本地或远程）都会更改 SHA1（因为根据定义，变基会更改基本父提交）。
正如Mondkin 有帮助的comments 一样，在祖先提交之上进行的rebase 将单独留下提交。
如果 GitHub 仍然确实更改了 SHA1，这意味着 GitHub 更改了一些其他元数据（日期或评论）以反映/记录该操作，并确保它是可见的（与本地 repo 不同，其中 rebase 在本地祖先是no-op：没有任何反应）。

【讨论】：

并非每个变基都会更改哈希：在祖先提交之上进行的变基会单独保留提交。这实际上是@SamHanes 引用中提到的关于 GitHub 和 git CLI 之间行为差异的内容（在 GitHub 中，甚至在祖先提交的基础上进行变基引入新的提交）
@MondKin 好点。我已将您的评论包含在答案中以获得更多可见性，并对其进行了扩展。
我认为你已经找到了“为什么”——提交者元数据在提交时更新，因此是新的 SHA。我希望在合并后保留放置在功能分支上的标签，但这在这个工作流程中似乎是不可能的。谢谢@VonC 和@MondKin！
我刚刚被同一个问题所困扰，我真的想知道是否有人知道 为什么 提交者元数据已更新（尤其是我最初提交谁做了rebase-and-merge）。