为什么Github中的"rebase and merge“选项会创建新的提交SHAs？还有别的选择吗？

Question

我喜欢使用"rebase and merge“选项来合并Github中的PRs，以避免将提交历史与合并提交混淆。

但是我注意到了以下的行为：(来自Github的文档)

GitHub上的重基和合并行为与git重基略有偏差。GitHub上的重基和合并将始终更新提交者信息并创建新的提交SHAs，而GitHub外部的git重基不会在祖先提交的基础上更改提交者信息。

这对我来说似乎很奇怪，因为这不是从git CLI重基的方式。有人知道它为什么会这样吗？

理想情况下，我希望既避免引入合并提交，也避免引入合并提交；( b)保留来自特性分支的提交SHAs和标记。有办法从UI中做到这一点吗？

Answer 1

我想两者都来 ( a)避免引入合并提交

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

来自主题分支(或头分支)的所有提交都单独添加到基分支，而不需要合并提交。 使用快进期权合并具有重基提交的拉请求。

和：

b)从特性分支保存提交SHAs和标记。

任何重基(在GitHub上本地或远程)无论如何都会更改SHA1 (因为根据定义，重基会更改基本父提交)。

作为蒙德金有用的评论，在祖先提交的基础上进行的重基使提交保持不变。

如果GitHub仍然更改了SHA1，这意味着为GitHub更改了其他元数据(日期或注释)，以反映/记录该操作，并确保它是可见的(与本地回购相反，在本地祖先之上的重基是无操作：什么都不会发生)。

Answer 2

你的欣赏是正确的，这不是在git中重基的工作方式。原因是在GitHub中，有些选项的名称很差：

• Squash和Merge：类似于南瓜和重基
• Rebase和Merge：类似于带有--no-ff选项的重基(即使提交是最新的，也将引入新的提交)

如果您使用的是"GitHub桌面“应用程序，您应该会看到其他陌生的名称，如”同步“，而不是”拉“+”合并“+”推送“。