合并后Diff选项卡中的类别是什么

Question

我合并了一个分支到另一个分支，并且在“差异”选项卡中包含三个类别包含文件：

与：起源/分支@ hash1的区别区别于：origin / working_branch @ hash2组合差异

每个类别中都有哪些文件？我将origin / working_branch合并到origin / branch。

是这样吗？

与Diff的区别：origin / branch @ hash1-包含在origin / working_branch中更改的文件区别于：origin / working_branch @ hash2-包含在origin / branch中更改的文件组合差异-包含两个分支中更改的文件

Answer 1

其中一些问题与图形用户界面Git Extensions有关。我没有用过，也无法回答任何问题。但是，此问题的另一部分是这些差异的含义/显示，这是基本的命令行Git。

在Git中的

记住，每个提交包含所有文件的完整快照。对于常规（非合并）提交，很容易看到它是如何工作的。每个提交都有一个parent提交，因此，在我们可以绘制的一行中，一个接一个地串接在一起。

...---F--G--H   <-- master
或：

* 9fadedd637 (master) a commit message subject
|
* 3bab5d5625 some other commit message subject
|
* 1c56d6f57a this commit does something or other
|
:
例如，如git log --graph所示（上面的输出是模拟的，与--graph所显示的不完全相同，但是足够接近）。

要view

提交，我们可以将其检出，以便我们在工作树中具有all个文件，在其中可以看到它们；或者我们可以通过将Git与它的父项进行比较来要求Git show提交。为了查看提交H，在master的顶端，我们让Git将G 和 H都提取到一个临时区域（在内存中）并对其进行compare。

G中的某些文件与H中的对应文件匹配。 Git对这些文件一无所获。某些文件不

匹配；对于这些，Git向我们展示了一个配方-差异列表-通过它我们可以[[change G中的文件，使其would与H中的副本匹配。[合并提交有多个父级。当使用向右的新提交来绘制它们时，就像我通常在StackOverflow上所做的那样，我们得到如下所示：

          I--J
         /    \
...--G--H      M--N--...
         \    /
          K--L

Commit M是一个合并，其父级为J和L。

合并与其他任何提交一样：它拥有完整的快照，而不是某些更改集。但是我们可以通过将M中的快照与J中的快照进行比较，来

view

进行as更改。git diff <hash-of-J> <hash-of-M>

例如确实如此。
我们也可以通过比较L与M将其视为更改：

git diff <hash-of-L> <hash-of-M>

每个差异将显示
更改
。不过，它们将显示的更改是不同的。

由于M是一个合并提交，所以当我们查看J -vs- M时，将看到我们沿着

bottom

行完成的工作所带来的更改，提交K和L。如果我们比较L -vs- M，我们将看到在提交I和J中沿着top行完成的工作带来的更改。请注意，例如L可能是I的精选，因此作品是重复的。在这种情况下，合并仅采用了这些更改的一个副本，而不是两个副本，因此我们不会在这两个差异的任一个中看到这一点。A

combined diff

完全是另外一回事。在我看来，这是一种有用的尝试，并不像人们所希望的那样成功。 Git组合差异的作用是，首先运行每个单独的差异（在这种情况下，是J vs M和L vs M），然后从该差异中任意throw out在其他差异中，not完全没有变化。即，假设在H中，我们有四个文件，所有这些文件也在I，J，K，L和M中，并且这些属性成立：] >

[same.txt在所有六个提交中都是相同的。

[top-only.txt在I和/或J中被修改，但在K和/或L中未被修改。

[bot-only.txt在K和/或L中被修改，但在I和/或J中未被修改。

[both.txt在J和L中都被修改。

我们还将假定M不是邪恶合并（请参阅Evil merges in git?）。也就是说，如果我们运行该差异，则H -vs- M将

not

显示未通过I，J，K或L进行的任何更改。此外，我们将假设both.txt的更改完全不重叠，因此合并将两个更改合并在一起：没有冲突，没有其他问题。显然，将J与M进行比较对于same.txt而言什么都没有显示：在H之后的五次提交中都没有被触摸。

区分J与M

不显示

top-only.txt，因为M中的副本与J中的副本匹配。对该文件的更改发生在I和/或J中，即，将H与J进行比较显示了更改，但是对H的top-only.txt版本进行了更改，从而导致了J版本top-only.txt的版本适用于H版本以获得M版本。将L与M进行比较

不显示

bot-only.txt出于相同的原因。同样，M的bot-only.txt副本与L副本匹配。仅对both.txt存在J和M之间的差异。

和

L和M之间的差异。如果我们要求Git提供M的

combined diff

视图，Git现在将：

diffJvs M：更改了两个文件：top-only.txt和both.txt；和
• diffLvs M：更改了两个文件：bot-only.txt和both.txt。

因此，列表更改了三个文件，两个差异文件一个，每个差异文件一个。现在，组合的diff

throw out

唯一的一个diff文件，仅剩下一个文件both.txt。至此，您可以选择两种不同的组合差异：

git diff --cc（默认值：请注意两个破折号和两个c）：打印
• nothing

。[git diff -c（请注意一个破折号和一个c）：这表示both.txt的差异。

--cc实际上很有意义。这里的想法是向您显示出现

合并冲突

的位置。由于没有合并冲突，因此它不会显示任何内容。 （有关确实显示某些内容的情况，请参见the combined diff format section of the git diff documentation。）git diff也很有意义，除了一件事：它既不显示-c，也不显示top-only.txt。我们真正需要的是一种将merge result快照与

merge base

快照进行比较的方法，但是Git并没有。也就是说，我们可能想查看bot-only.txt与H。尽管我认为可能应该这样做，但没有内置操作可以执行此操作。M的输出，在我在此处创建的测试存储库上运行这种组合的diff，是：git show -c

我们

可以

手动完成。请参阅下面的脚本（名称为

commit 54627dbf51ab9b27c8e5486e4755651688dd5d21 (HEAD -> merge)
Merge: da92a96 e77c224
[snip]
diff --combined both.txt
index 5d51eed,506867f..1f3f391
--- a/both.txt
+++ b/both.txt
@@@ -2,10 -2,10 +2,11 @@@ this fil
  will be
  modified in
  both branches.
 +here is the top-branch change

  The changes
  will be
  combined into
  one file
  in the merge result.
+ here is the bottom-branch change

，所以我可以将其作为git-show-merge运行）。这基本上是从指定合并（或默认为git show-merge）的父级中找到合并基础，然后运行所需的差异。

Git也具有HEAD选项，可同时用于-m和git show。该标志有效地将合并“拆分”为单独的“虚拟提交”。每一个都是单亲提交，其单亲是实际合并中的双亲之一。这样，Git的内部差异引擎就可以很好地进行差异化处理（作为普通差异进行提交），以向您显示更改的文件。

在这种情况下，git log首先对git show -m <hash-of-M> -vs- J进行比较，然后对M -vs- L进行比较，然后显示两个差异。

[Git Extensions似乎没有M选项，但确实具有显示-m -vs- J差异，或M -vs- L差异的选项，或者-如果您选择它-一种组合差异格式，可能是M变体。

注意，--cc默认甚至不

attatting

以显示合并。使用明确的git log -p或-c选项强制--cc显示组合的差异。

git log