Git rebase 跳过相同的提交

Question

根据git rebase doc

If the upstream branch already contains a change you have made (e.g., because you mailed a patch which was applied upstream), then that commit will be skipped. For example, running git rebase master on the following history (in which A' and A introduce the same set of changes, but have different committer information):

      A---B---C topic
     /
D---E---A'---F master 

will result in:

               B'---C' topic
              /
D---E---A'---F master

我无法理解的是这种优化的需要是什么？如果 git 会像这样重新设置:

               A''---- B'---C' topic
              /
D---E---A'---F master

可能出了什么问题？ (A = A' = A'')

EDIT :为了让自己更清楚，让我们说 F 还原 A' 的更改。现在 rebase 不会在 F 上应用 A 补丁，而只是在 B' 和 C' 上应用。在这种情况下， git rebase 行为可能是出乎意料的，对我来说没有意义。

Answer 1

可以有连续的提交来存储相同的源代码树。这就是你会得到的，因为A''不会对 F 进行任何更改——这些更改已经在中 F ;与 E 的区别至F由于与 E 的差异，包含相同的更改至A' .

换句话说，A'' 中的快照与 F 中的快照相同. Git 将这种提交对称为 空提交: 也就是说，如果父级匹配子级，并且子级不是 merge 提交，Git 会说子级提交是“空的”(即使它仍然有一个完整的快照)。 git commit命令需要标志 --allow-empty做出这样的 promise 。

此外，A'' 中的提交消息可能与 A' 中的提交消息相同.如果是，A''在所有有用的方面都是多余的。消除它可能是最好的做法。

请注意 git rebase最初是使用 git format-patch 实现的，这会将每个提交变成与其父级的差异，¹ 带有附加文本以使补丁可以通过电子邮件发送。一个单独的程序，git am ，读取“邮箱格式”文件(电子邮件消息序列)并应用补丁，使用附加文本重现提交作者、作者日期和日志消息。但是，格式补丁和 git am拒绝使用空补丁。因此，使用这两个程序来实现提交复制的 rebase 的初始版本不得不删除这些“空”提交。

现代 git rebase有多个后端，而不仅仅是 git am .这些可以创建或复制空提交。根据您的特定 Git 版本，您可能需要提供 -k标记为 git rebase获得 rebase 以故意创建此类提交。如果您的 Git 版本使用 git am作为默认后端，git rebase -k强制 rebase 使用交互式或 merge 后端，而不是 git am后端(当然也修改了它的初始设置，告诉它不要自动删除“空”提交)。

Git 2.26 及更高版本默认使用基于 merge 的后端，并且不需要 -k标志以保持空提交。使用 -k现在意味着保留变为为空的提交，而不是保留最初为空的提交。

您也可以手动进行 rebase ，使用单个 git cherry-pick命令或使用音序器进行集体采摘。与 rebase 一样，cherry-pick 默认拒绝复制“空”提交，需要 --allow-empty和/或 --keep-redundant-commits保留此类提交的标志。

---

¹ git format-patch根本无法格式化 merge 提交，因为它们有多个父级。