Git merge: команда слияния веток¶

git merge — команда системы управления версиями Git, предназначенная для интеграции изменений из одной ветки в другую. Она объединяет истории разработки двух веток, создавая новый коммит слияния (merge commit), который фиксирует результат объединения. Команда является одной из ключевых в Git наряду с commit, branch и checkout и используется для организации совместной работы над кодом.

¶Назначение и принцип работы

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

При выполнении git merge Git анализирует три состояния: общий предок двух веток (точка расхождения), текущую ветку и вливаемую ветку. В зависимости от ситуации возможны три сценария:

• Fast-forward (перемотка). Если текущая ветка не получила новых коммитов после точки расхождения, Git просто перемещает указатель текущей ветки вперёд на коммиты вливаемой ветки. При этом новый коммит слияния не создаётся, история остаётся линейной. По умолчанию Git выполняет fast-forward, если это возможно.
• Трёхстороннее слияние (three-way merge). Если обе ветки имеют коммиты после точки расхождения, Git выполняет объединение изменений, используя общий предок, и создаёт коммит слияния с двумя родителями.
• Конфликт слияния. Если одни и те же строки файлов были изменены в обеих ветках по-разному, Git не может автоматически разрешить противоречие и приостанавливает процесс, требуя вмешательства разработчика.

¶Синтаксис и основные параметры

Базовая форма команды выглядит как git merge <ветка>, где <ветка> — имя ветки, изменения которой вливаются в текущую. Перед выполнением слияния рабочая директория должна быть чистой (без незакоммиченных изменений), а текущая ветка — той, в которую выполняется слияние.

Наиболее часто используемые флаги:

• --no-ff — запрещает fast-forward и всегда создаёт коммит слияния, даже если слияние можно было выполнить перемоткой. Это позволяет сохранить в истории информацию о том, что существовала отдельная ветка.
• --ff-only — выполняет слияние только в режиме fast-forward; если это невозможно, команда завершается ошибкой. Полезно для поддержания линейной истории.
• --squash — объединяет изменения вливаемой ветки в рабочую директорию без создания коммита слияния и без сохранения истории ветки; разработчик сам создаёт один коммит со всеми изменениями.
• --abort — прерывает слияние при возникновении конфликта и возвращает репозиторий в состояние до его начала.
• -m — позволяет задать сообщение для коммита слияния (по умолчанию Git генерирует сообщение вида «Merge branch 'название'»).

¶Разрешение конфликтов

Конфликты возникают, когда Git не может автоматически объединить изменения. В таких случаях команда выводит список конфликтующих файлов, а сами файлы помечаются специальными маркерами:

``` <<<<<<< HEAD содержимое текущей ветки

содержимое вливаемой ветки

>>>>>> имя_вливаемой_ветки

```

Разработчик вручную редактирует файл, выбирая нужный вариант или комбинируя оба, после чего удаляет маркеры. Затем изменения индексируются командой git add, и слияние завершается командой git commit. Для просмотра конфликтующих файлов используется git status, для сравнения версий — git diff.

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

Git поддерживает несколько алгоритмов автоматического слияния, которые выбираются автоматически или задаются флагом -s:

• recursive — стратегия по умолчанию для слияния двух веток. Использует трёхстороннее слияние на основе общего предка и поддерживает определение переименований файлов.
• ort — современная переработанная версия recursive, используемая по умолчанию в новых версиях Git. Отличается более высокой скоростью работы и лучшей обработкой сложных случаев.
• resolve — упрощённая стратегия, аналогичная recursive, но без поддержки переименований.
• octopus — применяется при слиянии более двух веток одновременно (команда git merge ветка1 ветка2 ...).
• ours — автоматически разрешает конфликты в пользу текущей ветки, игнорируя содержимое вливаемой.
• subtree — используется для слияния веток, где одна является подкаталогом другой.

¶Практика использования

Типичный рабочий процесс слияния выглядит следующим образом:

1. Переключиться на целевую ветку: git checkout main.
2. Обновить её до актуального состояния: git pull.
3. Выполнить слияние: git merge feature-branch.
4. При необходимости разрешить конфликты и завершить слияние.
5. Удалить ненужную ветку: git branch -d feature-branch.

В распределённой командной разработке часто применяется модель Git Flow, где слияния выполняются между ветками разработки, релиза и основной веткой. Альтернативный подход — rebase (команда git rebase), который вместо создания коммита слияния переписывает историю, перенося коммиты ветки на новый базовый коммит. В отличие от merge, rebase создаёт линейную историю, но изменяет существующие коммиты, что опасно для опубликованных веток.

¶Отмена слияния

Если слияние выполнено ошибочно, его можно отменить. До создания коммита слияния (при конфликте) используется git merge --abort. После создания коммита применяется git reset --hard HEAD~1 для отката на один коммит назад или git revert -m 1 <хэш_коммита_слияния> для создания отменяющего коммита. Первый способ переписывает историю, второй — безопасен для опубликованных репозиториев.

¶Особенности и ограничения

• Слияние не изменяет историю вливаемой ветки — она остаётся доступной, что позволяет в любой момент вернуться к исходному состоянию.
• Коммит слияния имеет двух родителей, что усложняет некоторые операции с историей, например, интерактивный rebase.
• При частых слияниях крупных веток история становится нелинейной, что затрудняет её чтение. Для решения этой проблемы используются стратегии с перебазированием или squash-слияния.
• Git не хранит информацию о том, что ветка была удалена после слияния, поэтому рекомендуется удалять слитые ветки вручную.

Команда git merge является основным инструментом интеграции изменений и входит в стандартный набор команд любого разработчика, работающего с Git.