【发布时间】：2022-01-19 00:14:15
【问题描述】：
在我看来，我对 git（版本 2.31.1）的不直观的合并行为有疑问。让我用一个小玩具仓库来演示一下。
git init
touch file1
git add file1
git commit -m "Initial commit"
git branch feature
现在我有一个带有空文件和两个分支的提交，main 和 feature，指向该提交。现在我将主分支中的文件更改为
line1
line2
line3
line4
line5
并提交更改
git add file1
git commit -m "Change file1"
接下来，我去另一个分店
git checkout feature
把file1那里改成
line1
line2
line
line4
line5
然后再次提交更改
git add file1
git commit -m "Change file1"
生成的提交树如下所示：
* b1beb63 - Change file1 (HEAD -> feature)
| * 32ea83d - Change file1 (main)
|/
* 2952256 - Initial commit
现在我切换回main 分支并将feature 合并到main。
git checkout main
git config merge.conflictstyle diff3
git merge feature
正如所料，file1 中存在冲突。但是，冲突看起来像这样：
<<<<<<< HEAD
line1
line2
line3
line4
line5
||||||| 2952256
=======
line1
line2
line
line4
line5
>>>>>>> feature
如您所见，git 的行为就像整个文件是一个大冲突。我本来希望它看起来像这样：
line1
line2
<<<<<<< HEAD
line3
||||||| 2952256
=======
line
>>>>>>> feature
line4
line5
这将无限地更加用户友好。
我发现一些线程由于行尾不同而导致人们遇到类似问题。 这里不是这种情况，因为我在同一个平台的两个分支中使用同一个编辑器编辑了文件。
我目前对这种类型的合并的解决方案是通过对两个分支之间的文件进行差异来手动查找更改，即git diff main:file1 feature:file1。这可行，但相当烦人。
有什么方法可以让我在这次合并中得到我所期望的行为？如果没有，有什么好的理由说明这是不可能的吗？
【问题讨论】：
-
这个问题是 diff3 merge.conflictStyle 特有的。没有它，它会做你想做的事。
-
@Schwern 是的，但是我不会享受 diff3 冲突风格的好处。在这个简单的例子中，这无关紧要，但总的来说，我想坚持 diff3 冲突风格。
-
我已经把它归结为一个简单的解释为什么你不能同时拥有它。
标签： git merge version-control