为什么Github中的“rebase and merge”选项会创建新的提交SHA？还有其他选择吗？

Question

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

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

  

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

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

理想情况下，我想同时避免引入合并提交和b）保留功能分支中的提交SHA和标记。有没有办法从用户界面执行此操作？

Answer 1

您的赞赏是正确的，这不是rebase如何在git中运行。原因是在GitHub中，一些选项命名不佳：

• 壁球和合并：类似于壁球和 rebase
• Rebase和Merge ：类似于带有--no-ff选项的rebase（即使提交是最新的，也会引入新提交）

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

Answer 2

  

我想两个人

     

a）避免引入合并提交

由于文档提到：

，您无法创建任何合并提交

  

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

和

  

b）保留功能分支中的提交SHA和标记。

任何rebase（在GitHub上本地或远程）都会更改SHA1（因为根据定义，rebase会更改基本父提交）。
在Mondkin帮助comments时，在祖先提交之上制作的rebase会单独提交提交。
如果GitHub仍然更改SHA1，这意味着更改了GitHub的一些其他元数据（日期或注释）以反映/记录该操作，并确保它是可见的（而不是本地仓库，其中一个rebase在顶部本地祖先是no-op：没有任何反应。