合并分支时，Git不显示已删除行的当前/传入更改

我一直都在使用“主”分支，所以我试图了解更多关于git分支/合并的信息

我分支两次，然后执行合并

为什么git只显示新的冲突行？我想知道为什么删除“熊”一词根本就不是一种改变

---

您已经在评论中介绍了其中一些内容，但让我们把它写下来：

• 当您使用

  git merge

  时，实际上选择了三个提交。这三个提交中的每一个都有每个提交文件的完整（但只读）快照，其形式与您（或任何人）提交文件时文件的形式相同

• 这三项承诺是：
  • 当前提交（

    HEAD

    ，它是当前分支的尖端）
  • 您命名的另一个提交：

    git merge somebranch

    表示分支

    somebranch

    的提示（即最后一次）提交；及
  • 这两个提交的合并基

绘制提交图以查找合并基 要查找两次提交的合并基数，可以：

• 绘制提交图并使用您的眼球；或
• 使用gitmergebase，它有一个算法来实现这一点，然后只打印出原始散列ID

您自己的图像实际上显示了提交图的工作原理。我没有一个很好的方法来做这件事，所以我喜欢这样画提交：

          I--J   <-- branch1
         /
...--G--H   <-- master
         \
          K--L   <-- branch2

          I--J
         /    \
...--G--H      M   <-- branch1 (HEAD)
         \    /
          K--L   <-- branch2

名称

branch1

选择提交

J

，其中同名文件包含：

Ant
熊
猫
鹿
大象
青蛙

名称

branch2

选择提交

L

，其中该文件1包含：

Ant
猫
长颈鹿
河马
鬣蜥

---

这里有一个问题需要你思考。部分但不完全是哲学上的：我们怎么知道这是同一个文件？另见

---

设置合并 此时，如果需要，可以运行

git checkout branch1

，以便

HEAD

附加到

branch1

，因此commit

J

是当前提交，然后

git merge branch2

，选择commit

L

作为要合并的提交。Git现在从两个提交中向后走，

J

和

L

，直到找到两个分支上的提交。提交

I

和

J

仅在

branch1

上，提交

K-L

仅在

branch2

上。Commit

G

在两个分支上，Commit

H

也在两个分支上。因此，最好的共享（公共）祖先是commit

H

（在我们的示例中，可以通过名称

master

方便地指出，但通常没有额外的名称，您只需使用原始哈希ID

H

）

为了执行合并，Git实际上会查看

H

中的每个文件，然后查看

J

中的每个文件。实际上，Git在两次提交上运行

Git diff--find renames

。这将查找文件中从

H

到

J

的更改：

 Ant
 Bear
 Cat
+Deer
+Elephant
+Frog

没有删除任何行，从最后一行（第3行）之后开始添加三行

接下来，Git将

H

中的文件与

L

中的文件进行比较，就像运行

Git diff

一样。这次我们有：

 Ant
-Bear
 Cat
+Giraffe
+Hippo
+Iguana

第1行和第3行之间删除了一行；然后在最后一行之后添加三行

请注意，在这种情况下，您将文件（从

H

更改为

J

）和他们（无论他们是谁），尽管“他们”只是您再次更改了文件（从

H

更改为

L

）。这迫使Git对文件进行完整的文件级合并。如果只有“你”或“他们”更改了文件，Git将能够作弊：合并结果将是该文件的你或他们版本

执行文件级合并 既然Git必须合并对文件的单个更改，Git就要回到逐行处理的过程中。无论您在哪里更改文件，如果他们没有触及“同一行”，Git将接受您的更改。无论他们在哪里更改文件，如果您没有触摸“同一行”，Git都会接受他们的更改

在这里，他们删除了第2行。您不仅没有以任何方式更改第2行，也没有触及其相邻的第1行和第3行。上面的“同一行”包括相邻的行，所以Git觉得在这里取零钱是安全的

另一方面，您和他们都在末尾添加了三行，位于合并基本提交副本中的第3行之后。你的变化和他们的变化，因此毗邻：都触摸线3。所以Git为文件的这一部分声明了一个合并冲突

当Git遇到合并冲突时，至少对于像这样的文本文件，默认操作是Git将其最大的努力写入您的工作树中，以合并更改，冲突由冲突标记包围。这就是打开文件的工作树副本进行编辑时看到的内容

不过这里有一个方便的折痕：Git在Git的索引中保留了三个输入文件的所有三个副本—合并基文件、

--我们的

、以及

--他们的

文件。2这为Git提供了运行第三方合并工具（kdiff3、vimdiff、meld等）的能力。这些工具通常需要三个或四个文件名：

• 合并基文件

• --ours

  文件

• ——他们的

  文件
• 以及写入结果的位置，可能是Git的合并尝试

git mergetool

命令安排在所有这些文件上运行您选择的合并工具，方法是首先将可用（非git-ified）副本从索引提取到某个临时工作区

---

2从技术上讲，索引中的内容不是实际副本，而是参考。提交本身包含文件的重复数据消除副本

git merge --continue

git commit

          I--J   <-- branch1 (HEAD)
         /
...--G--H
         \
          K--L   <-- branch2

          I--J
         /    \
...--G--H      M   <-- branch1 (HEAD)
         \    /
          K--L   <-- branch2

*  a merge commit
|\
* |  a commit on the main line
| *  a commit on the branch that got merged
: :