完成https://learngitbranching.js.org后,我以为我有了樱桃挑选的想法,但事实证明我根本没有.
我创建了一个文件abc.txt并进行如下提交:
(write a) ? (write b) ? (write c)[master][HEAD]
由此abc.txt变成了:
a
b
c
现在,让一个分支from-a上(write a):
(write a)[from-a][HEAD] ? (write b) ? (write c)[master]
和樱桃采摘(write c)[master],我认为它将abc.txt包含只有一个线和c线,即喜欢
a
c
但它实际上导致:
a
<<<<<<< HEAD
=======
b
c
>>>>>>> 3a0882d... write c
在这里,我的困惑是双重的.为什么它会冲突而不只是添加线？为什么它包含b-line,尽管我只选择樱桃write c？
Git具有上下文感知功能,可以查找周围的行以及添加/删除的行.
这是有道理的,因为git需要知道应该从提交更改的位置.
在您的情况下,分支from-a具有内容
a
周围的线是空的.
您尝试挑选的提交具有以下内容:
diff --git a/abc.txt b/abc.txt
index 422c2b7..de98044 100644
--- a/abc.txt
+++ b/abc.txt
@@ -1,2 +1,3 @@
a
b
+c
即使提交消息在添加/删除的行周围显示更宽的上下文,git也只会尝试匹配上面的一行和修改下面的一行.(感谢das-g)
这意味着git会尝试找到该行:
b
在文件的末尾并插入行
c
在它之后.
因为你的分支from-a(当前HEAD),git找不到该行
b
在文件的末尾,因此无法干净地应用您的补丁,这导致冲突.
文本
<<<<<<< HEAD
=======
b
c
>>>>>>> 3a0882d... write c
表示git看到文件末尾的实际内容为空的冲突,表示为
<<<<<<< HEAD
=======
但是git期望找到这条线
b
为了添加该行
c
之后,由...表示
=======
b
c
>>>>>>> 3a0882d... write c
这样就可以解决冲突并决定如何加入这两种状态.
当你有冲突,你总是找之间的代码成对的的<<<<<<< HEAD和>>>>>>>.
在它们之间,你将使用=======哪个分隔当前HEAD状态和git在应用补丁后预期的状态.
| 归档时间： |
|
| 查看次数： |
461 次 |
| 最近记录： |