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

Question

我喜欢使用"rebase and merge"选项在Github中合并PR,以避免使用merge提交混乱提交历史记录.

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

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

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

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

Answer 1

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

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

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

Answer 2

我两个都愿意

a) 避免引入合并提交

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

来自主题分支（或头分支）的所有提交都将单独添加到基本分支，而无需合并提交。使用快进选项
合并具有重新基提交的拉取请求。

和：

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

任何变基（本地或远程在 GitHub 上）都会更改 SHA1（因为根据定义，变基会更改基本父提交）。
正如Mondkin有用的评论，在祖先提交之上进行的变基不会影响提交。
如果 GitHub 仍然更改 SHA1，这意味着 GitHub 会更改一些其他元数据（日期或评论）以反映/记录该操作，并确保其可见（与本地存储库相反，本地存储库在本地存储库之上进行变基）本地祖先是无操作：什么也没有发生）。