— 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>
Этот параметр определяет, как сообщение о слиянии будет очищено перед фиксацией. Кроме того, если <mode> присвоено значение scissors, ножницы будут добавлены к MERGE_MSG перед фиксацией результата в случае конфликта слияния.
–ff
–no-ff
–ff-only
Указывает, как обрабатывается слияние, когда объединённая история уже является потомком текущей истории. –ff используется по умолчанию, за исключением случаев объединения аннотированного (и, возможно, подписанного) тега, который не хранится на своём естественном месте в refs/tags/ иерархии, и в этом случае предполагается использование –no-ff.
С помощью –ff, когда это возможно, следует производить слияние как «ускоренную перемотку вперёд» (только обновив указатель ветви, чтобы он соответствовал объединенной ветви, не создавая фиксацию слияния). Если это невозможно (когда объединенная история не является потомком текущей истории), создаётся фиксация слияния.
С помощью –no-ff фиксация создаётся в любом случае, даже когда вместо этого слияние можно было бы разрешить как «ускоренную перемотку вперёд».
Использование –ff-only разрешает слияние как «ускоренную перемотку вперёд», когда это возможно. Если это невозможно, надо отказаться от слияния и выйти с ненулевым статусом.
-S[<ketid>]
–gpg-sign[=<keyid>]
–no-gpg-sign
GPG-sign результирует фиксацию слияния. Аргумент keyid является необязательным и по умолчанию использует идентификатор отправителя. Если он указан, он должен быть привязан к параметру без пробела.
–no-gpg-sign
полезен для отмены как переменной конфигурации commit.gpgSign, так и раннее введённой –gpg-sign.
–log[=<n>]
–no-log
В дополнение к именам ветвей заполняет сообщение журнала однострочными описаниями каждого из <n> фактически объединяемых коммитов.
Применение –no-log позволяет опускать создание списка однострочных описаний фактически объединяемых коммитов.
–singoff
–no-singoff
Используется для пропуска подписи исполнителя в конце сообщения журнала фиксации. Возможность не подписывать фиксацию (коммит) зависит от проекта, к которому присоединился исполнитель. Например, возможен вариант, когда исполнитель имеет право подтверждать свою работу лицензией проекта или, по соглашению с каким-либо представителем участника, собственным сертификатом разработчика. Необходимо обратиться к документации или руководству по созданию проекта, в котором коммитер участвует, чтобы понять, как используются подписи в этом проекте.
Параметр –no-signoff можно использовать в командной строке для отмены более раннего параметра –signoff.
–stat
-n
-no-stat
Показывает различия в конце слияния. Демонстрация различий также управляется параметром конфигурации merge.stat.
С помощью -n или –no-stat возможно не отображать diffstat в конце слияния.
–squash
–no-squash
Создаёт рабочее древо проекта и состояние индекса, как если бы произошло реальное слияние (за исключением информации о слиянии), но на самом деле не выполняет фиксацию коммита, не перемещает HEAD и не записывает $GIT_DIR/MERGE_HEAD (чтобы зафиксировать слияние далее следует выполнить команду git commit). Это позволяет создать дополнительный коммит поверх текущей ветви, который обладает эффектом как если бы произошло слияние с другой веткой или несколькими ветками в случае множественного слияния (octopus).
С помощью –no-squash производится слияние и фиксируется результат. Этот параметр можно использовать для переопределения –squash.
При использовании –squash, –commit не создаётся и будет потерян (завершится ошибкой).
–[no-]verity
По умолчанию выполняются перехватчики pre-merge и commit-msg. Когда задано значение –no-verify, их выполнения не происходит.
-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
Автоматически создаёт временную запись в хранилище перед началом операции, записывает её в специальную ссылку MERGE_AUTOSTASH и применяет её после завершения операции. Это означает, что можно запустить операцию на черновом рабочем древе. В то же время, использовать её следует с осторожностью: окончательное приложение stash после успешного слияния может привести к нетривиальным конфликтам.
–allow-unrelated-histories
По умолчанию команда git merge отказывается объединять истории, у которых нет общего предка. Этот параметр можно использовать для отмены этой меры безопасности при объединении историй двух проектов, которые начали свою жизнь независимо друг от друга. Поскольку это очень редкий случай, никакой переменной конфигурации, позволяющей включить это по умолчанию, не существует и добавляться не будет.
-m <msg>
Устанавливает сообщение о фиксации, которое будет использоваться для фиксации слиянием (в случае, если оно будет создано).
Если указано значение –log, к указанному сообщению будет добавлен краткий список объединяемых коммитов.
Команда git fmt-merge-msg может быть использована для предоставления хорошего значения по умолчанию для автоматических вызовов git merge. Автоматическое сообщение может содержать описание филиала.
–into-name <ветвь>
Подготавливает сообщение о слиянии по умолчанию, как при слиянии с ветвью <branch>, вместо имени реальной ветви, с которой выполняется слияние.
-F <файл>
–файл=<файл>
Фиксирует и позволяет прочитать сообщение о произошедшей фиксации (в случае, если она будет создана).
Если указано значение –log, к указанному сообщению будет добавлен краткий список объединяемых коммитов.
–rerere-autoupdate
–no-rerere-autoupdate
После того, как механизм повторного просмотра повторно использует записанное разрешение текущего конфликта для обновления файлов в рабочем дереве, следует разрешить ему также обновить индекс с результатом разрешения. –no-rerere-autoupdate – это хороший способ перепроверить, что сделал rerere, и выявить потенциальные несоответствия, прежде чем фиксировать результат в индекс с помощью отдельного git add.
–overwrite-ignore
–no-overwrite-ignore
Автоматическая перезаписать игнорируемых файлов из результата слияния. Это правило поведения по умолчанию. Используйте –no-overwrite-ignore для прерывания этого.
–abort
Прерывание текущего процесса разрешения конфликта и попытка восстановить состояние до слияния. Если присутствует запись автоматической очистки, добавляет её к рабочему дереву.
Если при запуске слияния присутствовали незафиксированные изменения в рабочем дереве, git merge –abort в некоторых случаях не сможет восстановить эти изменения. Поэтому настоятельно рекомендуется всегда фиксировать или сохранять свои изменения перед запуском git merge.
git merge –abort эквивалентен git reset –merge, когда присутствует MERGE_HEAD, если только MERGE_AUTOSTASH также не присутствует, и в этом случае git merge –abort применяет запись stash к рабочему дереву, тогда как git reset –merge сохранит сохраненные изменения в списке stash.
–quit
Не стоит беспокоиться о текущем выполнении слиянии. Пусть индекс и рабочее древо будут такими, как есть. Если применяется MERGE_AUTOSTASH запись о тайнике будет сохранена в списке тайников.
–continue
После остановки слияния git из-за возникшего конфликта, возможно завершить слияние, запустив git merge –continue.
<commit>…
Совершает слияние, как правило, других ветвей проекта со своей веткой. Указание более чем одного commit приведёт к слиянию с более чем двумя родительскими элементами (называемому слиянием Octopus).
Если из командной строки не задан порядок слияния, описывающий объединение ветвей проекта, текущая ветвь по умолчанию считается главной, к которой происходит присоединение других ветвей.
Когда FETCH_HEAD (и никакой другой коммит) не указан, ветви, записанные в файле .git/FETCH_HEAD предыдущим вызовом git fetch для объединения, объединяются с текущей ветвью.