Блог

Предположим, что следующая структура фиксации:

 A ---- B(HEAD)
  
   C
  

Содержимое файла в этих ревизоинах.

A:

 1
  

B:

 1
2
  

C:

 0
1
  

Я хочу объединить B с C. Если я сделаю это через git merge C , я получу ожидаемый конфликт. Но если я сделаю git rebase C , то git сделает это без каких-либо конфликтов, но результат будет неожиданным:

 0
12
  

Кто-нибудь может, пожалуйста, объяснить мне, почему это происходит? Могу ли я вообще полагаться на перебазирование? В документации говорится, что rebase повторно применяет коммиты на конце другого коммита. Итак, как получается, что коммит, добавляющий «2» ко второй строке, не вызывает никаких конфликтов и «съедает» разрыв строки?
Вы можете протестировать его на этом репозитории https://gitlab.com/timofei.davydik/rebase_problem.git

 git checkout test
git rebase master
  

Похоже, что проблемы вызваны отсутствием новой строки в последней строке вашего файла в каждом случае и, возможно, ошибкой с перебазированием при обнаружении этой отсутствующей новой строки. Технически текстовый файл не является «допустимым», когда отсутствует его окончательная новая строка, что, как я подозреваю, означает, что этот случай редко проверяется.

Я воспроизвел поведение в вашем образце репозитория — спасибо, что предоставили его! — и затем создал другую изолированную среду с теми же файлами, но с новой строкой в последней строке в каждом состоянии.

С окончательными символами новой строки в файле были созданы как слияние, так и перебазирование:

 0
1
2
  

как и следовало ожидать.

Я думаю, git merge что в вашем примере наблюдается конфликт, потому что он не распознает 1 и 1n как одно и то же, тогда как git rebase видит, что «вставить 0 впереди 1 » продолжается, потому что он находит 1 в первой строке, даже если новая строка отсутствует в 1 .

Тот факт, что git rebase произведено 0n12 , предполагает, что он взял 0n и 1 из C, а затем 2 из B, при этом новая строка отсутствует в 1 и 2 , потому что они отсутствуют в вашем файле.

Я бы сказал, что это ошибка, из-за которой перебазирование учитывало 1 == 1n , но в остальном вывод является разумным на основе входных данных.

На самом деле, merge и rebase не будут перемещать вещи одинаково. Итак, предполагая, что вы в настоящее время находитесь на ветке B:

• git merge C приведет к переходу верхнего состояния ветки C в вашу текущую ветку B. Это полезно, когда вы работаете над главной веткой и пытаетесь объединить результаты локальных ветвей разработки, например.
• git rebase C переместит вашу полную ветвь B поверх C (в качестве целевого объекта). Для этого git фактически найдет все коммиты, относящиеся к B, просматривая вашу ветку назад, пока не обнаружит, что первый коммит является общим для обеих ваших ветвей (здесь точка «A»). Затем он будет воспроизводить каждую фиксацию ветви B поверх C, то есть повторно применять каждый набор изменений.

Во-первых, это означает, что rebase операция не является операцией слияния. Тогда набор изменений, введенный B, на самом деле «добавляет 2 сразу после 1».

 @@ -1  1,2 @@
1
 2
  

В «A» ваш файл содержит только «1», поэтому в итоге вы получите «1» «2».
В «C» ваш файл содержит «0» «1», поэтому вы получите «0» «1» «2».