当文件相同时，git diff 报告差异

Question

我正在尝试将一个分支中的更改手动合并到我的存储库中的另一个分支中。 我使用以下方法查找差异：

git diff branchA...branchB path/to/files > diff.patch

这很好用，可以展示所有更改。然后我手动更新了我想要的branchA文件并提交了它们。Git状态显示一切都是最新的。现在我想再次运行diff以确保我没有漏掉任何内容。

但是当我运行diff时，它显示给我与第一次运行时完全相同的差异。例如，它向我展示了在branchB中添加的行，即使完全相同的行现在也存在于branchA中。

我猜这是因为我手动合并了，但如何获得正确的diff？

- Bill

---

你真的有提交过什么吗？因为我觉得你工作目录中的更改不会在 git diff 中显示出来。 - Tim Biegeleisen

如果您有任何本地更改，请将其存储，还原之前的更改，然后再试一次。显示差异。 - Nitin Dhomse

Answer 1

三个点的语法（branchA...branchB）在git diff中有不同于大多数 git 命令的特殊含义。通常来说，X...Y告诉 git rev-list 构造两个集合的对称差异：第一个集合是所有从X可达的提交集合，第二个集合是所有从Y可达的提交集合。对称差异是“所有从任一X或或Y可达的提交，但不包括两者都可达的提交”。换句话说，如果回溯到X和Y的历史最终到达某些公共提交（这些提交是最低公共祖先），那么我们只剩下既非 LCAs 也非其祖先的提交。LCAs 是我们也称之为合并基础。在大多数情况下，有一个 LCA 十分明显，它是您确定的两个提交的（单个）合并基础。当这两个提交是两个分支的末端时，这是很有道理的，并且对称差异是“合并基础后，在两个分支上的提交”，这是操作如 cherry-picking 的一个很好的起点。但对于git diff来说，这没有多大用处。原因是 git diff 只能比较两个且仅两个提交。²如果您给它一大堆提交，它不知道该怎么处理。由于git diff只使用一对提交，所以重新定义了两个点X..Y和三个点X...Y的语法。对于两点版本，它只取两个命名的提交，但对于三个点版本，它做了一些巧妙的事情：

git diff X...Y 意味着 git diff $(merge-base X Y) Y

由于三个点的语法通常停在（通常是单个的）合并基础，git diff 假设您必须意图执行某些类似于合并的操作。因此，它找到了您命名的提交的合并基础。幸运的是，只有一个最低公共祖先，这就是the合并基础。然后将合并基础提交与第二个命名提交进行比较。

如果这两个名称是分支名称（在本例中就是这样），并且您检出了第一个分支并向其添加了一个或多个提交（就像在本例中一样），我们可以确信两个分支末端的合并基础保持不变。 第二个分支也没有变化（因为我们仅修改了第一个分支，向其添加了新的提交）。 因此，如果我们现在使用相同的三点语法运行新的git diff，我们将比较完全相同的两个提交。

要自己验证，请使用：

git merge-base branchA branchB

请注意打印的提交ID，然后检出branchA并添加一个提交，并运行相同的git merge-base命令。在添加新提交之前和之后，您可能还想运行git rev-parse branchA和git rev-parse branchB：您将看到branchA获得了一个新的提交，而branchB没有。

您也可以运行：

git rev-list --left-right branchA...branchB

这将生成对称差异提交的列表（不包括合并基础），并使用<和>字符标记它们，以显示选择它们的两个（左侧或右侧）祖先中的哪一个。 （将rev-list更改为log --graph以查看日志消息。）

任何使用 git rev-list 的 git 命令都是一样的。这包括 git log（实际上，git log 和 git rev-list 本质上是相同的命令，具有不同的默认输出）。

好吧，git 还会为合并提交执行所谓的“合并差异”，但你无法从git diff本身获取它。

- torek

---

这很有道理，也是我认为正在发生的事情，有没有办法让git比较两个不同分支中文件的当前内容呢？还是我需要检出两个版本并使用标准的差异工具？ - Bill

要比较两个特定的提交，请只使用git diff A B(或带有两个而不是三个点的git diff A..B)。这里的'A'和'B'名称可以是任何解析为特定提交的内容，例如原始SHA-1或分支名称(分支名称解析为其顶端提交)。然而，使两个不同分支的末尾匹配通常不是明智之举：通常您想选择自合并基以来的更改，这就是git merge所做的事情。 - torek