Недавно я узнал, что при объединении двух веток в 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с mastergit объявляет конфликт слияния. Мое наивное ожидание состояло в том, что слияние произойдет без конфликта и приведет к следующему:

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

тогда я не хотел бы, чтобы мерзавец слился с этим

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

не тревожа меня.

Чтобы избежать возникновения таких проблем, git обычно отказывается автоматически объединять изменения, затрагивая соседние строки. Это дает вам возможность проверить, будет ли логика программы нарушена или нет.

Этот пример тривиален, но при объединении огромных ветвей риск подобных «логических» конфликтов намного выше. Иногда я бы даже хотел, чтобы контекст был еще больше, чем сейчас.

Это поведение только для мерзавцев?

После обсуждения с коллегой я только что попробовал, и SVN справляется с этим без проблем: вы модифицируете 2 строки.

Возможности слияния нескольких VCS тестируются здесь на базаре, darcs, git и mercurial : https://github.com/mndrix/merge-this

Кажется, только дарки успешно объединяют дело "соседних линий".

Применение смежных изменений к файлам не является сложной проблемой. Я действительно думаю, что это поведение было выбрано специально.

Почему кто-то решил, что изменение соседних строк приводит к конфликту?

Я думаю, что это заставит вас взглянуть на это .

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

Модификация № 1, о мастере:

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

Модификация № 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 merging в преимущество. Когда вам нужно сохранить согласованность двух строк, но вы не можете обнаружить их (во время компиляции, в начале ваших тестов или еще), вы можете попробовать присоединиться к ним.

Перепишите это ...:

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, который может интерактивно объединять конфликты в соседних (или отдельных) строках:

Это экономит мне огромное количество времени, так как я управляю проектом, в котором люди часто работают над одними и теми же файлами и проводят рефакторинг большого количества кода.

Скрипт доступен на GitHub под лицензией GPLv3 +. Может быть, вы найдете это полезным:

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