git-merge

Название

git-merge — объединение двух или более историй разработки

Краткое описание

git merge [-n] [--stat] [--compact-summary] [--no-commit] [--squash] [--[no-]edit]
        [--no-verify] [-s <strategy>] [-X <strategy-option>] [-S[<keyid>]]
        [--[no-]allow-unrelated-histories]
        [--[no-]rerere-autoupdate] [-m <msg>] [-F <file>]
        [--into-name <branch>] [<commit>…]
git merge (--continue | --abort | --quit)

Описание

Включает изменения из указанных коммитов (начиная с момента расхождения их историй с текущей веткой) в текущую ветку. Эта команда используется git pull для включения изменений из другого репозитория, а также может использоваться вручную для объединения изменений из одной ветки с другой.

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

          A---B---C topic
         /
    D---E---F---G master

В этом случае git merge topic повторно применит изменения, внесённые в ветке topic с момента её расхождения с master (т. е. E) до текущего коммита (C), поверх master и запишет результат в новый коммит вместе с именами двух родительских коммитов и сообщением журнала от пользователя с описанием изменений. Перед операцией ORIG_HEAD устанавливается в вершину текущей ветки (G).

          A---B---C topic
         /         \
    D---E---F---G---H master

Слияние останавливается, если возникает конфликт, который невозможно разрешить автоматически, или если при запуске слияния был указан параметр --no-commit. В этом случае можно выполнить git merge --abort или git merge --continue.

git merge --abort прервёт процесс слияния и попытается восстановить состояние до слияния. Однако если на момент начала слияния были незакоммиченные изменения (особенно если эти изменения дополнительно менялись после начала слияния), в некоторых случаях git merge --abort не сможет восстановить исходные изменения (до слияния). Поэтому:

Предупреждение

Не рекомендуется выполнять git merge при наличии существенных незакоммиченных изменений: хотя это возможно, в случае конфликта вы можете оказаться в состоянии, из которого будет сложно выйти.

Параметры

--commit

--no-commit

Выполнить слияние и зафиксировать результат коммитом. Этот параметр можно использовать, чтобы переопределить --no-commit.

С параметром --no-commit выполнить слияние и остановиться непосредственно перед созданием коммита слияния, чтобы пользователь мог проверить и при необходимости доработать результат слияния перед фиксацией.

Обратите внимание: обновления с перемоткой вперёд не создают коммит слияния, поэтому остановить такое слияние с помощью --no-commit невозможно. Следовательно, если нужно гарантировать, что команда слияния не изменит и не обновит ветку, используйте --no-ff вместе с --no-commit.

--edit

-e

--no-edit

Перед фиксацией успешно выполненного слияния запустить редактор, чтобы дополнительно отредактировать автоматически созданное сообщение слияния и дать пользователю возможность объяснить и обосновать слияние. Параметр --no-edit можно использовать, чтобы принять автоматически созданное сообщение (обычно это не рекомендуется). Параметр --edit (или -e) по-прежнему полезен, если вы передаёте черновое сообщение с помощью параметра -m в командной строке и хотите отредактировать его в редакторе.

Старые скрипты могут рассчитывать на историческое поведение, при котором пользователю не разрешалось редактировать сообщение журнала слияния. При запуске git merge они увидят открывшийся редактор. Чтобы упростить адаптацию таких скриптов к обновлённому поведению, в начале скриптов можно установить переменную среды GIT_MERGE_AUTOEDIT в значение no.

--cleanup=<mode>

Этот параметр определяет, как будет очищено сообщение слияния перед фиксацией. Подробнее см. в git-commit[1]. Кроме того, если параметру <mode> задано значение scissors, перед передачей механизму фиксации в случае конфликта слияния в MERGE_MSG добавляется маркер ножниц.

--ff

--no-ff

--ff-only

Определяет, как выполнять слияние, если история сливаемой ветки уже является потомком текущей истории. По умолчанию используется --ff, кроме случаев слияния аннотированного (и, возможно, подписанного) тега, хранящегося не в обычном месте иерархии refs/tags/; в этом случае предполагается --no-ff.

С параметром --ff при возможности разрешить слияние перемоткой вперёд (обновить только указатель ветки, чтобы он соответствовал сливаемой ветке; не создавать коммит слияния). Если это невозможно (история сливаемой ветки не является потомком текущей истории), создать коммит слияния.

С параметром --no-ff всегда создавать коммит слияния, даже если слияние можно было бы разрешить перемоткой вперёд.

С параметром --ff-only разрешить слияние перемоткой вперёд, если это возможно. Если это невозможно, отказаться от слияния и завершить работу с ненулевым кодом возврата.

-S[<key-id>]

--gpg-sign[=<key-id>]

--no-gpg-sign

Подписать полученный коммит слияния с помощью GPG. Аргумент <key-id> необязателен и по умолчанию соответствует идентификатору коммиттера; если он указан, его нужно указывать сразу после параметра, без пробела. Параметр --no-gpg-sign полезен для отмены как настройки commit.gpgSign, так и ранее заданного параметра --gpg-sign.

--log[=<n>]

--no-log

В дополнение к именам веток добавить в сообщение журнала однострочные описания не более чем <n> фактических коммитов, участвующих в слиянии. См. также git-fmt-merge-msg[1].

С параметром --no-log не добавлять однострочные описания фактических коммитов, участвующих в слиянии.

--signoff

--no-signoff

Добавить в конец сообщения журнала коммита завершающую строку Signed-off-by от коммиттера. Значение подтверждения зависит от проекта, в который вы отправляете изменения. Например, оно может удостоверять, что коммиттер имеет право отправлять эту работу на условиях лицензии проекта или согласен с некоторым подтверждением со стороны участника, например с Сертификатом происхождения разработчика. (См. https://developercertificate.org — вариант, используемый проектами ядра Linux и Git.) Чтобы понять, как подтверждения используются в проекте, ознакомьтесь с его документацией или обратитесь к его руководству.

Параметр --no-signoff можно использовать для отмены ранее указанного в командной строке параметра --signoff.

В Git нет (и не будет) переменной конфигурации для включения параметра командной строки --signoff по умолчанию; подробнее см. запись commit.signoff в gitfaq[7].

--stat

-n

--no-stat

Показать сводную статистику различий в конце слияния. Её отображение также регулируется параметром конфигурации merge.stat.

С параметром -n или --no-stat не показывать сводную статистику различий в конце слияния.

--compact-summary

Показать краткую сводку в конце слияния.

--squash

--no-squash

Подготовить рабочее дерево и индекс так, как если бы произошло обычное слияние (за исключением сведений о слиянии), но не создавать коммит, не перемещать HEAD и не записывать $GIT_DIR/MERGE_HEAD (чтобы следующая команда git commit создала коммит слияния). Это позволяет создать один коммит поверх текущей ветки с тем же результатом, что и при слиянии другой ветки (или нескольких веток в случае слияния Octopus).

С параметром --no-squash выполнить слияние и зафиксировать результат коммитом. Этот параметр можно использовать, чтобы переопределить --squash.

При использовании --squash параметр --commit запрещён и вызовет ошибку.

--verify

--no-verify

По умолчанию выполняются хуки pre-merge и commit-msg. Если указан параметр --no-verify, они пропускаются. См. также githooks[5].

-s <strategy>

--strategy=<strategy>

Использовать указанную стратегию слияния; параметр можно указать несколько раз, задав порядок их применения. Если параметр -s не указан, вместо этого используется встроенный список стратегий (ort при слиянии одной вершины, в остальных случаях — octopus).

-X <option>

--strategy-option=<option>

Передать параметр, специфичный для стратегии слияния, самой стратегии слияния.

--verify-signatures

--no-verify-signatures

Проверить, что вершина коммита боковой ветки, участвующей в слиянии, подписана действительным ключом, то есть ключом с действительным uid. В модели доверия по умолчанию это означает, что ключ подписи подписан доверенным ключом. Если вершина коммита боковой ветки не подписана действительным ключом, слияние прерывается.

--summary

--no-summary

Синонимы для --stat и --no-stat; эти параметры устарели и будут удалены в будущем.

-q

--quiet

Выполнять команду без вывода сообщений. Подразумевает --no-progress.

-v

--verbose

Выводить подробную информацию.

--progress

--no-progress

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

--autostash

--no-autostash

Автоматически создать временную запись в stash перед началом операции, записать её в ссылку MERGE_AUTOSTASH и применить после завершения операции. Это позволяет выполнять операцию с изменённым рабочим деревом. Однако используйте этот параметр с осторожностью: применение записи stash после успешного слияния может привести к сложным конфликтам.

--allow-unrelated-histories

По умолчанию команда git merge отказывается объединять истории, у которых нет общего предка. Этот параметр позволяет отменить данное ограничение безопасности при слиянии историй двух проектов, изначально созданных независимо друг от друга. Поскольку такие ситуации возникают крайне редко, переменной конфигурации для включения этого поведения по умолчанию нет и не будет.

-m <msg>

Задать сообщение для коммита слияния (если он будет создан).

Если указан параметр --log, к заданному сообщению будет добавлен краткий журнал сливаемых коммитов.

Команду git fmt-merge-msg можно использовать для создания подходящего сообщения по умолчанию при автоматических вызовах git merge. Автоматическое сообщение может содержать описание ветки.

--into-name <branch>

Подготовить сообщение слияния по умолчанию так, как если бы слияние выполнялось в ветку <branch>, а не в ветку, в которую оно фактически выполняется.

-F <file>

--file=<file>

Прочитать сообщение для коммита слияния (если он будет создан).

Если указан параметр --log, к заданному сообщению будет добавлен краткий журнал сливаемых коммитов.

--rerere-autoupdate

--no-rerere-autoupdate

После того как механизм rerere повторно использует сохранённое решение для текущего конфликта и обновит файлы в рабочем дереве, разрешить ему также обновить индекс результатом разрешения конфликта. Параметр --no-rerere-autoupdate позволяет перепроверить действия git-rerere[1] и обнаружить возможные ошибочные слияния до фиксации результата в индексе отдельной командой git-add[1].

--overwrite-ignore

--no-overwrite-ignore

Молча перезаписывать игнорируемые файлы результатом слияния. Это поведение используется по умолчанию. Укажите --no-overwrite-ignore, чтобы прервать операцию.

--abort

Прервать текущий процесс разрешения конфликтов и попытаться восстановить состояние до слияния. Если имеется запись autostash, применить её к рабочему дереву.

Если на момент начала слияния в рабочем дереве были незакоммиченные изменения, в некоторых случаях команда git merge --abort не сможет восстановить эти изменения. Поэтому рекомендуется всегда фиксировать изменения коммитом или сохранять их в stash перед запуском git merge.

git merge --abort эквивалентен git reset --merge, если присутствует MERGE_HEAD, за исключением случая, когда также присутствует MERGE_AUTOSTASH: тогда git merge --abort применяет запись stash к рабочему дереву, а git reset --merge сохраняет отложенные изменения в списке stash.

--quit

Забыть о текущем выполняющемся слиянии. Оставить индекс и рабочее дерево без изменений. Если присутствует MERGE_AUTOSTASH, запись stash будет сохранена в списке stash.

--continue

Если git merge останавливается из-за конфликтов, завершить слияние можно командой git merge --continue (см. раздел «КАК РАЗРЕШАТЬ КОНФЛИКТЫ» ниже).

<commit>...

Коммиты, обычно вершины других веток, которые нужно объединить с нашей веткой. Указание более чем одного коммита создаст слияние с более чем двумя родителями (такое слияние ласково называют Octopus).

Если в командной строке не указан коммит, объединяются ветки удалённого отслеживания, настроенные в качестве вышестоящих для текущей ветки. См. также раздел о конфигурации на этой странице руководства.

Если указан FETCH_HEAD (и не указан другой коммит), текущая ветка объединяется с ветками, записанными в файле .git/FETCH_HEAD предыдущим вызовом git fetch для слияния.

Проверки перед слиянием

Перед применением внешних изменений приведите свою работу в порядок и зафиксируйте её локально, чтобы она не была затёрта в случае конфликтов. См. также git-stash[1]. Команды git pull и git merge остановятся, ничего не сделав, если локальные незакоммиченные изменения затрагивают файлы, которые может потребоваться обновить командам git pull/git merge.

Чтобы в коммит слияния не попали несвязанные изменения, команды git pull и git merge также прервут работу, если в индексе зарегистрированы изменения относительно коммита HEAD. (В зависимости от используемой стратегии слияния могут существовать узкие исключения из этого правила, но в целом индекс должен соответствовать HEAD.)

Если все указанные коммиты уже являются предками HEAD, git merge завершится досрочно с сообщением «Уже актуально».

Слияние перемоткой вперёд

Часто вершина текущей ветки является предком указанного коммита. Это наиболее распространённый случай, особенно при вызове из git pull: вы отслеживаете вышестоящий репозиторий, не фиксировали локальные изменения и теперь хотите обновиться до более новой версии вышестоящего репозитория. В этом случае для сохранения объединённой истории новый коммит не нужен; вместо этого HEAD (вместе с индексом) обновляется и указывает на заданный коммит, без создания дополнительного коммита слияния.

Это поведение можно отключить параметром --no-ff.

Полноценное слияние

За исключением слияния перемоткой вперёд (см. выше), объединяемые ветки должны быть связаны коммитом слияния, у которого обе ветки являются родителями.

Фиксируется объединённая версия, согласующая изменения всех объединяемых веток, а HEAD, индекс и рабочее дерево обновляются до неё. В рабочем дереве могут быть изменения, если они не пересекаются; при обновлении они сохраняются.

Если способ согласовать изменения неочевиден, происходит следующее:

Указатель HEAD остаётся без изменений.
Ссылка MERGE_HEAD устанавливается так, чтобы указывать на вершину другой ветки.
Пути, которые удалось объединить без конфликтов, обновляются и в файле индекса, и в рабочем дереве.
Для конфликтующих путей файл индекса хранит до трёх версий: в этапе 1 хранится версия из общего предка, в этапе 2 — из HEAD, а в этапе 3 — из MERGE_HEAD (этапы можно просмотреть с помощью git ls-files -u). Файлы рабочего дерева содержат результат операции слияния, то есть результат трёхстороннего слияния со знакомыми маркерами конфликтов <<< === >>>.
Создаётся ссылка с именем AUTO_MERGE, указывающая на дерево, соответствующее текущему содержимому рабочего дерева (включая маркеры текстовых конфликтов). Обратите внимание: эта ссылка создаётся только при использовании стратегии слияния ort (по умолчанию).
Других изменений не вносится. В частности, локальные изменения, существовавшие до начала слияния, останутся прежними, как и записи индекса для них, то есть будут соответствовать HEAD.

Если вы попытались выполнить слияние, приведшее к сложным конфликтам, и хотите начать заново, можно восстановить исходное состояние с помощью git merge --abort.

Слияние тега

При слиянии аннотированного (и, возможно, подписанного) тега Git всегда создаёт коммит слияния, даже если возможно слияние перемоткой вперёд, а шаблон сообщения коммита подготавливается на основе сообщения тега. Кроме того, если тег подписан, результат проверки подписи добавляется в шаблон сообщения в виде комментария. См. также git-tag[1].

Если вы хотите просто включить изменения, приведшие к коммиту, на который указывает тег (например, синхронизироваться с вышестоящей точкой выпуска), возможно, вам не нужен лишний коммит слияния.

В таком случае можно самостоятельно «развернуть» тег перед передачей его команде git merge или указать --ff-only, если у вас нет собственных изменений. Например:

git fetch origin
git merge v1.2.3^0
git merge --ff-only v1.2.3

Как отображаются конфликты

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

По умолчанию Git использует для отображения таких конфликтующих фрагментов тот же стиль, что и программа "merge" из набора RCS. Например:

Here are lines that are either unchanged from the common
ancestor, or cleanly resolved because only one side changed,
or cleanly resolved because both sides changed the same way.
<<<<<<< yours:sample.txt
Conflict resolution is hard;
let's go shopping.
=======
Git makes conflict resolution easy.
>>>>>>> theirs:sample.txt
And here is another line that is cleanly resolved or unmodified.

Область, в которой произошли конфликтующие изменения, отмечается маркерами <<<<<<<, ======= и >>>>>>>. Часть перед ======= обычно представляет вашу версию, а часть после него — версию другой стороны.

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

Можно использовать альтернативный стиль, задав для переменной конфигурации merge.conflictStyle значение diff3 или zdiff3. В стиле diff3 приведённый выше конфликт может выглядеть так:

Here are lines that are either unchanged from the common
ancestor, or cleanly resolved because only one side changed,
<<<<<<< yours:sample.txt
or cleanly resolved because both sides changed the same way.
Conflict resolution is hard;
let's go shopping.
||||||| base:sample.txt
or cleanly resolved because both sides changed identically.
Conflict resolution is hard.
=======
or cleanly resolved because both sides changed the same way.
Git makes conflict resolution easy.
>>>>>>> theirs:sample.txt
And here is another line that is cleanly resolved or unmodified.

а в стиле zdiff3 он может выглядеть так:

Here are lines that are either unchanged from the common
ancestor, or cleanly resolved because only one side changed,
or cleanly resolved because both sides changed the same way.
<<<<<<< yours:sample.txt
Conflict resolution is hard;
let's go shopping.
||||||| base:sample.txt
or cleanly resolved because both sides changed identically.
Conflict resolution is hard.
=======
Git makes conflict resolution easy.
>>>>>>> theirs:sample.txt
And here is another line that is cleanly resolved or unmodified.

Помимо маркеров <<<<<<<, ======= и >>>>>>>, здесь используется ещё один маркер |||||||, за которым следует исходный текст. Видно, что в оригинале было просто изложено фактическое утверждение, ваша сторона лишь согласилась с ним и отказалась от своих слов, а другая сторона попыталась настроиться более позитивно. Иногда просмотр исходного текста помогает найти более удачное решение.

Как разрешать конфликты

Обнаружив конфликт, можно поступить одним из двух способов:

Отказаться от слияния. Нужно лишь сбросить файл индекса к коммиту HEAD, чтобы отменить действие пункта 2, и очистить изменения рабочего дерева, внесённые в пунктах 2 и 3; для этого можно использовать git merge --abort.
Разрешить конфликты. Git отметит конфликты в рабочем дереве. Отредактируйте файлы, чтобы получить нужный результат, и добавьте их в индекс с помощью git add. Используйте git commit или git merge --continue, чтобы завершить слияние. Последняя команда перед вызовом git commit проверяет, выполняется ли (прерванное) слияние.

Для разрешения конфликта можно использовать различные инструменты:

Используйте инструмент слияния. Выполните git mergetool, чтобы запустить графический инструмент слияния, который поможет вам выполнить слияние.
Просмотрите различия. Команда git diff покажет трёхстороннее сравнение различий, выделив изменения как в версии HEAD, так и в версии MERGE_HEAD. Команда git diff AUTO_MERGE покажет внесённые вами изменения, предназначенные для разрешения текстовых конфликтов.
Просмотрите различия для каждой ветки. Команда git log --merge -p <path> сначала покажет различия для версии HEAD, а затем для версии MERGE_HEAD.
Просмотрите исходные версии. Команда git show :1:filename показывает общего предка, команда git show :2:filename показывает версию HEAD, а команда git show :3:filename — версию MERGE_HEAD.

Примеры

Выполнить слияние веток fixes и enhancements с текущей веткой, создав слияние типа octopus:
```
$ git merge fixes enhancements
```
Выполнить слияние ветки obsolete с текущей веткой, используя стратегию слияния ours:
```
$ git merge -s ours obsolete
```
Выполнить слияние ветки maint с текущей веткой, но не создавать новый коммит автоматически:
```
$ git merge --no-commit maint
```
Это можно использовать, если вы хотите внести дополнительные изменения в результат слияния или написать собственное сообщение для коммита слияния.

Не злоупотребляйте этой опцией, добавляя значительные изменения в коммит слияния. Небольшие исправления, например обновление имени выпуска или версии, допустимы.

Стратегии слияния

Механизм слияния (команды git merge и git pull) позволяет выбрать внутреннюю реализацию merge strategies с помощью опции -s. Некоторые стратегии также принимают собственные опции, которые можно передать, указав аргументы -X<option> для команд git merge и/или git pull.

ort

Это стратегия слияния по умолчанию при извлечении изменений или слиянии одной ветки. Эта стратегия может разрешать конфликты только между двумя вершинами с помощью алгоритма трёхстороннего слияния. Если существует несколько общих предков, пригодных для трёхстороннего слияния, стратегия создаёт объединённое дерево общих предков и использует его в качестве эталонного дерева для трёхстороннего слияния. Как показали тесты на реальных коммитах слияния из истории разработки ядра Linux 2.6, это позволяет уменьшить количество конфликтов слияния, не вызывая ошибочных слияний. Кроме того, эта стратегия умеет обнаруживать и обрабатывать слияния с переименованиями. Обнаруженные копирования не используются. Название этого алгоритма является акронимом ("Ostensibly Recursive’s Twin") и связано с тем, что он был написан как замена предыдущему алгоритму по умолчанию — recursive.

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

Стратегия ort принимает следующие опции:

ours

Эта опция принудительно разрешает конфликтующие фрагменты автоматически, отдавая предпочтение версии our. Изменения из другого дерева, не конфликтующие с нашей версией, включаются в результат слияния. Для двоичного файла всё содержимое берётся из нашей версии.

Не путайте эту опцию со стратегией слияния ours, которая вообще не анализирует содержимое другого дерева. Она отбрасывает все изменения, сделанные в другом дереве, объявляя, что история our содержит всё, что в нём произошло.

theirs

Это противоположность опции ours; обратите внимание, что, в отличие от ours, стратегии слияния theirs не существует, поэтому спутать с ней эту опцию слияния нельзя.

ignore-space-change

ignore-all-space

ignore-space-at-eol

ignore-cr-at-eol

При трёхстороннем слиянии строки с указанным типом изменений пробельных символов считаются неизменёнными. Изменения пробельных символов, смешанные с другими изменениями строки, не игнорируются. См. также git-diff[1] -b, -w, --ignore-space-at-eol и --ignore-cr-at-eol.

Если версия their вносит в строку только изменения пробельных символов, используется версия our;
Если версия our вносит изменения пробельных символов, но версия their содержит существенное изменение, используется версия their;
В противном случае слияние выполняется обычным образом.

renormalize

Для всех трёх этапов каждого файла, требующего трёхстороннего слияния, выполняются виртуальные извлечение и помещение в репозиторий. Эта опция предназначена для слияния веток с разными фильтрами очистки или правилами нормализации конца строки. Подробности см. в разделе "Слияние веток с различными атрибутами при помещении в репозиторий и извлечении" в gitattributes[5].

no-renormalize

Отключает опцию renormalize. Переопределяет переменную конфигурации merge.renormalize.

find-renames[=<n>]

Включает обнаружение переименований, при необходимости задавая порог сходства. Это поведение используется по умолчанию. Переопределяет переменную конфигурации merge.renames. См. также git-diff[1] --find-renames.

rename-threshold=<n>

Устаревший синоним find-renames=<n>.

no-renames

Отключает обнаружение переименований. Переопределяет переменную конфигурации merge.renames. См. также git-diff[1] --no-renames.

histogram

Устаревший синоним diff-algorithm=histogram.

patience

Устаревший синоним diff-algorithm=patience.

diff-algorithm=(histogram|minimal|myers|patience)

При слиянии используется другой алгоритм сравнения различий, что помогает избежать ошибочных слияний, вызванных несущественными совпадающими строками (например, фигурными скобками из разных функций). См. также git-diff[1] --diff-algorithm. Обратите внимание: по умолчанию ort имеет значение diff-algorithm=histogram, тогда как для обычного сравнения различий сейчас используется настройка конфигурации diff.algorithm.

subtree[=<path>]

Эта опция представляет собой более развитую форму стратегии subtree: стратегия пытается определить, как следует сместить два дерева, чтобы они совпали при слиянии. Вместо этого указанный путь добавляется в начало или удаляется из начала, чтобы привести структуру двух деревьев к совпадению.

recursive

Теперь это синоним ort. До версии v2.49.0 это была альтернативная реализация, но в версии v2.50.0 её перенаправили на ort. Предыдущая стратегия recursive была стратегией по умолчанию для разрешения слияний двух вершин в версиях Git от v0.99.9k до v2.33.0.

resolve

Эта стратегия может разрешать конфликты только между двумя вершинами (то есть текущей веткой и другой веткой, из которой были извлечены изменения) с помощью алгоритма трёхстороннего слияния. Она старается тщательно обнаруживать неоднозначности при перекрёстных слияниях. Переименования не обрабатываются.

octopus

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

ours

Эта стратегия обрабатывает любое количество вершин, но итоговое дерево слияния всегда совпадает с деревом вершины текущей ветки, фактически игнорируя все изменения из остальных веток. Она предназначена для замены старой истории разработки боковых веток. Обратите внимание, что она отличается от опции -Xours стратегии слияния ort.

subtree

Это модифицированная стратегия ort. При слиянии деревьев A и B, если B соответствует поддереву A, дерево B сначала корректируется в соответствии со структурой дерева A, а не анализируется на том же уровне. Аналогичная корректировка выполняется и для дерева общего предка.

При использовании стратегий, основанных на трёхстороннем слиянии (включая стратегию по умолчанию ort), если изменение внесено в обеих ветках, но затем отменено в одной из них, оно всё равно будет присутствовать в результате слияния; некоторым такое поведение кажется непонятным. Это происходит потому, что при слиянии учитываются только вершины и база слияния, а не отдельные коммиты. Поэтому алгоритм слияния воспринимает отменённое изменение как полное отсутствие изменений и подставляет изменённую версию.

Настройка

branch.<name>.mergeOptions: Задаёт параметры по умолчанию для слияния в ветку <name>. Синтаксис и поддерживаемые параметры такие же, как у git merge, но значения параметров, содержащие пробельные символы, в настоящее время не поддерживаются.

Всё, что находится выше этой строки в данном разделе, не включено из документации git-config[1]. Далее следует содержимое, совпадающее с тем, что приведено там:

merge.conflictStyle

Задаёт стиль записи конфликтующих фрагментов в файлы рабочего дерева при слиянии. По умолчанию используется стиль "merge", который показывает маркер конфликта <<<<<<<, изменения, внесённые одной стороной, маркер =======, изменения, внесённые другой стороной, а затем маркер >>>>>>>. Альтернативный стиль "diff3" добавляет маркер ||||||| и исходный текст перед маркером =======. Стиль "merge" обычно формирует области конфликта меньшего размера, чем diff3, как из-за исключения исходного текста, так и потому, что совпадающее в обеих версиях подмножество строк просто выносится за пределы области конфликта. Другой альтернативный стиль, "zdiff3", похож на diff3, но удаляет совпадающие строки из обеих версий из области конфликта, если эти строки находятся рядом с её началом или концом.

merge.defaultToUpstream

Если merge вызывается без аргумента-коммита, выполняет слияние с вышестоящими ветками, настроенными для текущей ветки, используя их последние известные значения, сохранённые в ветках отслеживания удалённых репозиториев. Проверяются значения branch.<current branch>.merge, задающие ветки удалённого репозитория с именем branch.<current-branch>.remote, затем они сопоставляются с соответствующими ветками отслеживания удалённых репозиториев через remote.<remote>.fetch, и выполняется слияние вершин этих отслеживаемых веток. По умолчанию — true.

merge.ff

По умолчанию Git не создаёт дополнительный коммит слияния при слиянии коммита, являющегося потомком текущего коммита. Вместо этого вершина текущей ветки перемещается вперёд без создания нового коммита (fast-forward). Если задано значение false, эта переменная указывает Git создавать в таком случае дополнительный коммит слияния (что эквивалентно передаче параметра --no-ff в командной строке). Если задано значение only, разрешены только такие слияния fast-forward (что эквивалентно передаче параметра --ff-only в командной строке).

merge.verifySignatures

Если значение равно true, это эквивалентно параметру командной строки --verify-signatures. Подробности см. в git-merge[1].

merge.branchdesc

Помимо имён веток, добавляет в сообщение журнала текст описания, связанный с этими ветками. По умолчанию — false.

merge.log

Помимо имён веток, добавляет в сообщение журнала не более указанного числа однострочных описаний из фактических коммитов, участвующих в слиянии. По умолчанию — false; значение true является синонимом числа 20.

merge.suppressDest

Если добавить в эту многозначную переменную конфигурации шаблон glob, соответствующий именам интеграционных веток, вычисляемое по умолчанию сообщение о слиянии в эти интеграционные ветки не будет содержать в заголовке фразу "into <branch-name>".

Элемент с пустым значением можно использовать, чтобы очистить список шаблонов glob, накопленный из предыдущих записей конфигурации. Если переменная merge.suppressDest не задана, для обратной совместимости используется значение по умолчанию master.

merge.renameLimit

Количество файлов, рассматриваемых при исчерпывающем поиске переименований во время слияния. Если параметр не задан, используется значение diff.renameLimit. Если не заданы ни merge.renameLimit, ни diff.renameLimit, в настоящее время по умолчанию используется значение 7000. Эта настройка не действует, если поиск переименований отключён.

merge.renames

Определяет, обнаруживает ли Git переименования. Если задано значение false, поиск переименований отключается. Если задано значение true, включается базовый поиск переименований. По умолчанию используется значение diff.renames.

merge.directoryRenames

Определяет, обнаруживает ли Git переименования каталогов и, соответственно, что происходит при слиянии с новыми файлами, добавленными в каталог в одной ветке истории, если этот каталог был переименован в другой ветке истории. Возможные значения:

false: Поиск переименований каталогов отключён, то есть новые файлы останутся в старом каталоге.
true: Поиск переименований каталогов включён, то есть новые файлы будут перемещены в новый каталог.
conflict: Для таких путей будет сообщено о конфликте.

Если merge.renames равно false, параметр merge.directoryRenames игнорируется и считается равным false. По умолчанию используется conflict.

merge.renormalize

Сообщает Git, что каноническое представление файлов в репозитории со временем изменилось (например, в более ранних коммитах текстовые файлы записаны с окончаниями строк CRLF, а в более поздних используются окончания строк LF). В таком репозитории для каждого файла, которому требуется трёхстороннее слияние содержимого, Git может преобразовать данные, записанные в коммитах, в каноническую форму перед слиянием, чтобы уменьшить количество ненужных конфликтов. Дополнительные сведения см. в разделе "Слияние веток с различающимися атрибутами check-in/check-out" документации gitattributes[5].

merge.stat

Определяет, что, если вообще что-либо, выводить между ORIG_HEAD и результатом слияния в конце операции. Возможные значения:

false: Ничего не показывать.
true: Показывать git diff --diffstat --summary ORIG_HEAD.
compact: Показывать git diff --compact-summary ORIG_HEAD.

однако любое нераспознанное значение (например, значение, добавленное в будущей версии Git) считается равным true, а не вызывает ошибку. По умолчанию используется true.

merge.autoStash

Если задано значение true, перед началом операции автоматически создаётся временная запись stash, которая применяется после её завершения. Это позволяет выполнять слияние в рабочем дереве с незакоммиченными изменениями. Однако используйте эту возможность осторожно: применение stash после успешного слияния может привести к нетривиальным конфликтам. Этот параметр можно переопределить параметрами --no-autostash и --autostash команды git-merge[1]. По умолчанию используется false.

merge.tool

Управляет выбором инструмента слияния, используемого командой git-mergetool[1]. В приведённом ниже списке указаны допустимые встроенные значения. Любое другое значение рассматривается как имя пользовательского инструмента слияния; для него необходимо определить соответствующую переменную mergetool.<tool>.cmd.

merge.guitool

Управляет выбором инструмента слияния, используемого командой git-mergetool[1], если указан флаг -g/--gui. В приведённом ниже списке указаны допустимые встроенные значения. Любое другое значение рассматривается как имя пользовательского инструмента слияния; для него необходимо определить соответствующую переменную mergetool.<guitool>.cmd.

araxis
bc
codecompare
deltawalker
diffmerge
diffuse
ecmerge
emerge
examdiff
guiffy
gvimdiff
kdiff3
meld
nvimdiff
opendiff
p4merge
smerge
tkdiff
tortoisemerge
vimdiff
vscode
winmerge
xxdiff

merge.verbosity

Управляет объёмом вывода стратегии рекурсивного слияния. Уровень 0 не выводит ничего, кроме итогового сообщения об ошибке, если обнаружены конфликты. Уровень 1 выводит только конфликты, уровень 2 — конфликты и изменения файлов. Уровень 5 и выше выводит отладочную информацию. По умолчанию используется уровень 2. Можно переопределить переменной окружения GIT_MERGE_VERBOSITY.

merge.<driver>.name

Задаёт понятное человеку имя для пользовательского низкоуровневого драйвера слияния. Подробности см. в gitattributes[5].

merge.<driver>.driver

Задаёт команду, реализующую пользовательский низкоуровневый драйвер слияния. Подробности см. в gitattributes[5].

merge.<driver>.recursive

Задаёт низкоуровневый драйвер слияния, используемый при внутреннем слиянии общих предков. Подробности см. в gitattributes[5].

См. также

git-fmt-merge-msg[1], git-pull[1], gitattributes[5], git-reset[1], git-diff[1], git-ls-files[1], git-add[1], git-rm[1], git-mergetool[1]

© 2005–2026 Linus Torvalds and others
Licensed under the GNU General Public License version 2.
https://git-scm.com/docs/git-merge