Скотт Чакон - Pro Git

$git revert ^M

[master 09f0126] Revert "Revert "Merge branch 'topic'""

$git merge topic

Рисунок 6. История после повторения отмененного слияния

В этом примере, M и ^M отменены. В коммите ^^M, фактически, сливаются изменения из C3 и C4, а в C8 – изменения из C7, таким образом, ветка topic полностью слита.

До этого момента мы рассматривали типичные слияния двух веток, которые обычно выполняются с использованием стратегии слияния, называемой “рекурсивной”. Но существуют и другие типы слияния веток. Давайте кратко рассмотрим некоторые из них.

Во-первых, существует еще один полезный прием, который мы можем использовать в обычном “рекурсивном” режиме слияния. Мы уже видели опции ignore-all-space и ignore-space-change, которые передаются с префиксом -X, но мы можем также попросить Git при возникновении конфликта использовать ту или иную версию файлов.

По умолчанию, когда Git при слиянии веток замечает конфликт, он добавляет в код маркеры конфликта, отмечает файл как конфликтующий и позволяет вам разрешить его. Если же вместо ручного разрешения конфликта вы хотите, чтобы Git просто использовал какую-то определенную версию файла, а другую игнорировал, то вы можете передать команде merge одну из двух опций -Xours или -Xtheirs.

В этом случае Git не будет добавлять маркеры конфликта. Все неконфликтующие изменения он сольет, а для конфликтующих он целиком возьмет ту версию, которую вы указали (это относится и к бинарным файлам).

Если мы вернемся к примеру “hello world”, который использовали раньше, то увидим, что попытка слияния в нашу ветку приведет к конфликту.

$git merge mundo

Auto-merging hello.rb

CONFLICT (content): Merge conflict in hello.rb

Resolved 'hello.rb' using previous resolution.

Automatic merge failed; fix conflicts and then commit the result.

Однако, если мы выполним слияние с опцией -Xours или -Xtheirs, конфликта не будет.

$git merge -Xours mundo

Auto-merging hello.rb

Merge made by the 'recursive' strategy.

hello.rb | 2 +-

test.sh | 2 ++

2 files changed, 3 insertions(+), 1 deletion(-)

create mode 100644 test.sh

В этом случае, вместо добавления в файл маркеров конфликта с “hello mundo” в качестве одной версии и с “hola world” в качестве другой, Git просто выберет “hola world”. Однако, все другие неконфликтующие изменения будут слиты успешно.

Такая же опция может быть передана команде git merge-file, которую мы обсуждали ранее, то есть для слияния отдельных файлов можно использовать команду git merge-file --ours.

На случай если вам нужно нечто подобное, но вы хотите, чтобы Git даже не пытался сливать изменения из другой версии, существует более суровый вариант – стратегия слияния “ours”. Важно отметить, что это не тоже самое что опция “ours” рекурсивной стратегии слияния.

Фактически, эта стратегия выполнит ненастоящее слияние. Она создаст новый коммит слияния, у которой родителями будут обе ветки, но при этом данная стратегия даже не взглянет на ветку, которую вы сливаете. В качестве результата слияния она просто оставляет тот код, который находится в вашей текущей ветке.

$git merge -s ours mundo

Merge made by the 'ours' strategy.

$git diff HEAD HEAD~

$

Вы можете видеть, что между веткой, в которой мы были, и результатом слияния нет никаких отличий.

Это часто бывает полезно, когда нужно заставить Git считать, что ветка уже слита, а реальное слияние отложить на потом. Для примера предположим, что вы создали ветку “release” и проделали в ней некоторую работу, которую когда-то впоследствии захотите слить обратно в “master”. Тем временем в “master” были сделаны некоторые исправления, которые необходимо перенести также в вашу ветку “release”. Вы можете слить ветку с исправлениями в release, а затем выполнить merge -s ours этой ветки в master (хотя исправления в ней уже присутствуют), так что позже, когда вы будете снова сливать ветку release, не возникнет конфликтов, связанных с этими исправлениями.

Идея слияния субдеревьев состоит в том, что у вас есть два проекта и один из проектов отображается в субдиректорию другого. Когда вы выполняете слияние субдеревьев, Git в большинстве случаев способен понять, что одно из них является субдеревом другого и выполнить слияние подходящим способом.

Далее мы рассмотрим пример добавления в существующий проект другого проекта и последующее слияние кода второго проекта в субдиректорию первого.