我最近了解到，当在git中合并两个分支时，如果相邻两行发生变化，则git声明这是冲突。例如，如果文件test.txt具有以下内容：

Line 1: A
Line 2: B
Line 3: C
Line 4: D

在分支中，master我们将其更改为

Line 1: A
Line 2: B1
Line 3: C
Line 4: D

而在分支中，testing我们将其更改为

Line 1: A
Line 2: B
Line 3: C1
Line 4: D

然后尝试合并testing为master，则git声明合并冲突。我天真的期望是合并不会发生冲突并产生以下结果：

Line 1: A
Line 2: B1
Line 3: C1
Line 4: D

我确信git不以这种方式合并是有充分的理由的。有人可以解释这个原因吗？

假设这段代码

x=0
x+=1 if foo
x+=1 if bar
return x

已在一个分支中更改为

x=0
x+=1 if foo && xyzzy
x+=1 if bar
return x

在另一个分支

x=0
x+=1 if foo
x+=1 if bar && xyzzy
return x

那么我不想git将其合并到这个

x=0
x+=1 if foo && xyzzy
x+=1 if bar && xyzzy
return x

不用惊动我

为了避免引起此类问题，git通常拒绝自动合并涉及附近行的更改。它使您有机会验证程序逻辑是否被破坏。

这个例子很简单，但是当合并巨大的分支时，类似的“逻辑”冲突的风险就更大了。有时我什至希望上下文比现在更大。

这是仅git的行为吗？

与同事讨论之后，我尝试了一下，SVN可以毫无问题地处理它：您修改了两行。

在这里，针对集市，darcs，git和mercurial测试了多个VCS的合并功能：https : //github.com/mndrix/merge-this

似乎只有darcs成功地合并了“相邻行”的情况。

将相邻的更改应用于文件不是一个难题。我真的认为这种行为是故意选择的。

为什么有人会决定修改相邻线会产生冲突？

我认为这是要强迫您看一下。

int max = MAX_ITEMS;
for(unsigned int i = 0; i < max; i++)
    do_stuff(i);

主模块上的Modif数字1：

int max = MAX_ITEMS/2; // Do stuff only on the first half
for(unsigned int i = 0; i < max; i++)
    do_stuff(i);

Modif 2，从分支合并：

int max = MAX_ITEMS;
for(unsigned int i = 0; i < max/2; i++) // max/2: only on 1st half
    do_stuff(i);

合并后，您不需要：

int max = MAX_ITEMS/2; // Do stuff only on the first half
for(unsigned int i = 0; i < max/2; i++) // max/2: only on 1st half
    do_stuff(i);

将此行为视为功能

您可以将git合并行为变成一种优势。当需要保持两行一致而又无法检测到它时（在编译时，测试初期或其他时候），可以尝试将它们合并。

重写此...：

for(unsigned int i = 0; i < max; i++)
    r = do_stuff(i);
    // Need to do something else
    do_something_else(r);

...对此：

for(unsigned int i = 0; i < max; i++)
    r = do_stuff(i);
    do_something_else(r); // Need to do something else

因此，当您合并Modif 1 ...：

for(unsigned int i = 0; i < max; i++)
    r = do_stuff(i)/2; // we need only the half
    do_something_else(r); // Need to do something else

...使用Modif 2 ...：

for(unsigned int i = 0; i < max; i++)
    r = do_stuff(i);
    if(r < 0) // do_stuff can return an error
        handle_error(r);
    do_something_else(r/2); // Need to do something else

...，git会产生冲突，您将迫使您查看它。

我主要是在猜测，但是我认为这与将第2行用作第3行更改的上下文有关。

Git不能只说“与C的行成为与C1的行”，因为可能还有另一行与“ C”，所以它说“与C的行，即在文件开始之后，即与A，并且与B的线现在是C1”

如果“带有B的行”不再存在，那么某些上下文将丢失，并且git只能大致判断出新行的去向。

这里的其他答案都是正确的，但对我而言，这似乎始终是不必要的限制。

正如其他人所说，在这些情况下，您绝对不希望Git在没有警告的情况下合并这些行。

但是在被警告后，我仍然希望该选项可以自动执行。因此，我编写了一个自定义git merge驱动程序，该驱动程序可以交互方式合并相邻（或单个）行上的冲突：

在我管理一个项目时，人们经常在同一个文件上工作并重构大量代码，这为我节省了大量时间。

该脚本可在GPLv3 +许可下在GitHub上使用。也许您会发现它很有用：

https://github.com/paulaltin/git-subline-merge