Стратегии слияния в Git: параметры и примеры
Когда работа завершена, протестирована и готова к передаче в основную линию разработки, ваша команда должна выбрать стратегию слияния. В этой статье рассматриваются разные стратегии и объясняется, как работает Atlassian. По прочтении у вас будет достаточно знаний, чтобы выбрать оптимальный для своей команды вариант.
Стратегии слияния в Git
Под слиянием подразумевается объединение двух веток. Git пытается найти общий базовый коммит для двух или более указателей. Есть несколько методов поиска. Они называются «стратегиями слияния». Когда Git находит общий базовый коммит, создается коммит слияния, который объединяет изменения определенных коммитов. С технической точки зрения, коммит слияния — это обычный коммит с двумя родителями.
Команда git merge
автоматически выбирает стратегию слияния, если она не указана явным образом. Команды git merge
и git pull
могут использоваться с параметром -s
(стратегия). К параметру -s
можно добавить имя стратегии слияния, которую вы хотите использовать. Если стратегия явно не указана, Git выберет подходящую на основе предоставленных веток. Далее мы рассмотрим конкретные стратегии слияния.
Связанные материалы
Расширенный журнал Git
СМ. РЕШЕНИЕ
Изучите Git с помощью Bitbucket Cloud
Рекурсивная стратегия
git merge -s recursive branch1 branch2
Эта стратегия работает с двумя указателями HEAD. Она применяется по умолчанию при выполнении команды pull или merge для одной ветки. Рекурсивная стратегия позволяет обнаруживать и обрабатывать слияния с переименованием, но на сегодняшний день не может использовать обнаруженные копии. Эта стратегия применяется по умолчанию при выполнении команд pull или merge для одной ветки.
Решение
git merge -s resolve branch1 branch2
Эта стратегия может разрешить только два указателя HEAD с помощью алгоритма трехстороннего слияния. Данная стратегия пытается выявлять неопределенности при перекрестном слиянии и считается в целом безопасной и быстрой.
Стратегия «Осьминог»
git merge -s octopus branch1 branch2 branch3 branchN
Стратегия «Осьминог» применяется по умолчанию для более чем двух голов. Когда передается больше одной ветки, «осьминог» включается автоматически. Если в слиянии есть конфликты, которые нужно разрешать вручную, эта стратегия блокирует попытку слияния. В основном она используется для объединения голов аналогичных функциональных веток.
Стратегия «Наша»
git merge -s ours branch1 branch2 branchN
Стратегия «Наша» (Ours) позволяет работать с множеством веток. Выходной результат слияния всегда соответствует указателю HEAD
текущей ветки. Эта стратегия называется «Наша», потому что она игнорирует все изменения из «чужих» веток. Ее назначение — объединение истории аналогичных функциональных веток.
Стратегия «Поддерево»
git merge -s subtree branchA branchB
Это разновидность рекурсивной стратегии. При слиянии A и B, если B — дочернее поддерево A, сначала обновляется B, чтобы отразить древовидную структуру A. Кроме того, обновляется родительское дерево, которое является общим для A и B.
Типы стратегий слияния в Git
Явное слияние
Явное слияние — стандартный вариант, который используется по умолчанию. Слияние называется явным, потому что создается новый коммит слияния. При этом меняется история коммита и явно показано, где выполнено слияние. Содержимое коммита слияния также является явным: можно увидеть, какие коммиты были родительскими для коммита слияния. Некоторые разработчики избегают явных слияний, чтобы не перегружать историю проекта.
Скрытое слияние с использованием методов rebase или fast-forward
Склеивание (обычно без явного слияния)
Параметры рекурсивной стратегии слияния в Git
Рассмотренная выше рекурсивная стратегия имеет свой поднабор параметров.
ours
Не следует путать этот параметр со стратегией слияния «Наша» (Ours). Он позволяет автоматически разрешать конфликты путем предпочтения «нашей» (ours) версии. Изменения с «их» (theirs) стороны внедряются автоматически, если в них отсутствуют конфликты.
theirs
Параметр theirs, напротив, отдает предпочтение чужому дереву слияния при разрешении конфликтов.
patience
Этот параметр позволяет избежать ошибок слияния на неважных совпадающих линиях. Его лучше использовать, когда ветки, подлежащие слиянию, сильно расходятся.
diff-algorithim
ignore-*
ignore-space-change
ignore-all-space
ignore-space-at-eol
ignore-cr-at-eol
Набор параметров, которые ориентированы на символы пробела. Любая линия, которая соответствует поднабору передаваемого параметра, будет проигнорирована.
renormalize
Этот параметр запускает команды check-out и check-in во всех трех деревьях Git при разрешении конфликтов трехстороннего слияния. Он используется при слиянии веток с разными статусами checkin
/checkout
.
no-normalize
Отключает параметр renormalize. Это переопределяет переменную конфигурации merge.renormalize
.
no-renames
Этот параметр игнорирует переименованные файлы во время слияния.
find-renames=n
Это поведение по умолчанию. При рекурсивном слиянии поддерживается переименование файлов. Параметр n
можно использовать для передачи порогового значения сходства при переименовании. По умолчанию значение n
равно 100%
.
subtree
Этот параметр является вариантом стратегии «Поддерево» (Subtree). В то время как стратегия работает с двумя деревьями и задает способ их совмещения в общем родителе, этот параметр работает с метаданными пути дерева для обеспечения совмещения.
Наша политика слияния в Git
Atlassian настоятельно рекомендует использовать скрытые слияния. Причина простая: явные слияния оставляют следы и контекст в объединяемых функциях. Перед тем как отправлять функциональную ветку на проверку, следует выполнить очистку локальной истории с помощью команды rebase, однако это не меняет нашу политику, а дополняет ее.
Поделитесь этой статьей
Следующая тема
Рекомендуемые статьи
Добавьте эти ресурсы в закладки, чтобы изучить типы команд DevOps или получать регулярные обновления по DevOps в Atlassian.