3.1Слияние

Сравнишь fast-forward с трёхсторонним merge и проследишь роль общего предка. Разберёшь, когда нужен merge commit, как остановить слияние и почему повторный merge той же ветки не возвращает отменённые изменения.

Ветка: два файла по одной строке

Примеры главы идут на Go-сервисе shop: Аня ведёт main, Боря пишет в отдельных ветках. Пока в репозитории два коммита, и второй, с обработчиком /health, лежит в ветке health:

$ git log --oneline --graph --all
* 9472581 (health) Добавить /health
* b22e07b (HEAD -> main) Создать модуль shop

Ветка хранит хеш одного коммита (глава 1.2). Проверим, какие файлы git меняет, когда ветку создают и когда на неё переключаются:

$ touch ../mark && git branch retry && find .git -newer ../mark -type f
.git/logs/refs/heads/retry
.git/refs/heads/retry
$ touch ../mark && git switch retry && find . -newer ../mark -type f
Switched to branch 'retry'
./.git/HEAD
./.git/logs/HEAD
./.git/index
$ git switch main && git branch -d retry
Switched to branch 'main'
Deleted branch retry (was b22e07b).

git branch записал 41 байт в файл ссылки и строку в её журнал (reflog, глава 5.2). Новых объектов нет, файлы проекта никуда не копировались. git switch переписал HEAD, его журнал и индекс, а рабочую копию не тронул: переключение обновляет файлы, которые в двух коммитах различаются (глава 1.3), а коммит здесь тот же. Ветка, под которой тысяча коммитов, стоит столько же.

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

Fast-forward: перемотать указатель

Боря закончил /health, Аня вливает. Сначала спросим, что у веток общего:

$ git merge-base main health
b22e07be3256d6b7f2a23f69ccd998dd2474bf1f
$ git merge-base --is-ancestor main health; echo $?
0

merge-base, лучший общий предок двух коммитов, совпал с вершиной main. Значит, main целиком входит в историю health и сводить нечего. --is-ancestor задаёт тот же вопрос кодом возврата, 0 значит «да». Тогда git делает fast-forward, перемотку: переставляет ветку на вершину health и приводит к ней индекс и рабочую копию.

$ git merge health
Updating b22e07b..9472581
Fast-forward
 health.go | 7 +++++++
 main.go   | 1 +
 2 files changed, 8 insertions(+)
 create mode 100644 health.go
$ git reflog -2
9472581 (HEAD -> main, health) HEAD@{0}: merge health: Fast-forward
b22e07b HEAD@{1}: checkout: moving from retry to main
$ git merge health
Already up to date.

Нового коммита не появилось, обе ветки указывают на 9472581. По графу уже не скажешь, что работа шла в отдельной ветке: история линейная, будто Боря коммитил прямо в main. След остался в reflog, а reflog локальный. Повторное слияние ничего не делает, потому что теперь merge-base совпадает с вливаемой вершиной.

Весь выбор сводится к одному сравнению. merge-base равен вливаемой вершине: «Already up to date». Равен текущей: fast-forward. Не равен ни той, ни другой: истории разошлись, и нужно настоящее слияние.

Трёхсторонний merge

Ветку health Аня удалила. Второго сентября Боря завёл retry и научил сервис повторять запрос к базе, а Аня за это время сделала в main три коммита:

$ git log --oneline --graph main retry
* 7302ee9 (HEAD -> main) Переименовать db.go в store.go
* a7f2b2d Убрать флаг DebugSQL
* e51b996 Слушать порт 9090
| * cf9dac0 (retry) Поднять число повторов до 5
| * 259f46a Повторять запрос к базе
|/
* 9472581 Добавить /health
* b22e07b Создать модуль shop
$ git merge-base main retry
9472581c652970bbf7dddcc58725e64c9e3d21d2

Обе стороны правили config.go, и git diff main retry находит в нём четыре расхождения. Например, строка DebugSQL есть в retry и отсутствует в main. Боря её добавил или Аня удалила? По двум файлам этого не узнать. Нужна третья версия, с которой обе ветки начинали, то есть файл из merge-base. С ней каждое расхождение решается однозначно. Если от базы отошла одна сторона, берётся её версия, а одинаковую правку с двух сторон git вносит один раз. Конфликт получается, когда обе поменяли одно место по-разному (глава 3.2).

Это и есть трёхсторонний merge. Коммиты ветки по одному git не проигрывает. Он берёт три снимка, для каждой вершины считает, что в ней изменилось относительно базы, и накладывает обе разницы на базу, файл за файлом и кусок за куском:

$ git merge retry
Auto-merging config.go
Auto-merging store.go
Merge made by the 'ort' strategy.
 config.go |  3 ++-
 store.go  | 13 +++++++++++++
 2 files changed, 15 insertions(+), 1 deletion(-)
$ git log --oneline --graph -3 main
*   03180dc (HEAD -> main) Merge branch 'retry'
|\
| * cf9dac0 (retry) Поднять число повторов до 5
| * 259f46a Повторять запрос к базе

В терминале git сначала откроет редактор с сообщением коммита, а вывод появится, когда его закроешь. «Auto-merging» git печатает про файлы, которые менялись с обеих сторон и сводились построчно. Результат записан коммитом 03180dc с двумя родителями: первым стоит 7302ee9, где была main, вторым cf9dac0 (порядок разобран в главе 1.2). Сдвинулась только main. Статистика посчитана от первого родителя, то есть показывает, что слияние принесло в main. Прежнюю вершину git записал в ORIG_HEAD, и пока слияние никуда не отправлено, его отменяет git reset --hard ORIG_HEAD (глава 5.1). Откуда взялся store.go, которого в ветке Бори нет, объясняет раздел про ort.

merge-base: как git ищет общего предка

Общих предков у main и retry два, 9472581 и b22e07b, а merge-base из них один. По определению из git help merge-base общий предок A лучше общего предка B, если B лежит в истории A, а merge-base называется общий предок, лучше которого нет. Проще говоря, ближайший к обеим вершинам. Таких бывает несколько, если ветки сливали друг в друга крест-накрест.

Код поиска лежит в commit-reach.c. Git идёт от обеих вершин к родителям, более новые коммиты первыми (по номеру поколения из commit-graph или по дате), и помечает, из какой вершины достижим каждый коммит. Коммит с обеими пометками становится кандидатом, а его предков git помечает как заведомо худших. Обход кончается, когда рассматривать больше нечего, обычно задолго до корня. Из нескольких кандидатов git выбрасывает тех, что достижимы из другого кандидата.

Зачем всё это, видно на повторном слиянии. Третьего сентября Боря дописал в retry логирование неудачных попыток:

$ git merge-base main retry
cf9dac04e60bdac4d51cfd0344ac17aaa09512e7
$ git log --oneline main..retry
f27b1c4 (retry) Логировать неудачные попытки
$ git merge retry
Auto-merging store.go
Merge made by the 'ort' strategy.
 store.go | 2 ++
 1 file changed, 2 insertions(+)

База теперь cf9dac0, бывшая вершина retry: второй родитель 03180dc сделал её достижимой из main, и к вершинам она ближе, чем 9472581. Поэтому второе слияние сравнивает снимки только с этой точки и приносит одну новую правку. Останься база прежней, git сравнивал бы с 9472581 весь retry заново. Стоило бы Ане после первого слияния ещё раз поменять MaxRetries, и её новая версия столкнулась бы со старой версией Бори, которую она давно влила. Так и бывает после squash-merge, где второго родителя нет (глава 3.3). Второй родитель merge-коммита и есть запись о том, что уже слито.

--no-ff и --ff-only

Перемотка экономит коммит, но стирает из графа саму ветку. Боря сделал счётчик запросов в ветке metrics из двух коммитов, main с тех пор не двигалась, и fast-forward возможен. Аня всё равно просит коммит слияния:

$ git merge --no-ff metrics
Merge made by the 'ort' strategy.
 handlers.go |  1 +
 main.go     |  1 +
 metrics.go  | 13 +++++++++++++
 3 files changed, 15 insertions(+)
 create mode 100644 metrics.go
$ git rev-parse main^{tree} metrics^{tree}
70ce9af292a4486ab03aa34e5f7e862a22b9855a
70ce9af292a4486ab03aa34e5f7e862a22b9855a
$ git log --oneline --first-parent -4 main
9e6cbb8 (HEAD -> main) Merge branch 'metrics'
432bf6b Merge branch 'retry'
03180dc Merge branch 'retry'
7302ee9 Переименовать db.go в store.go

Деревья совпали: файлы после --no-ff те же, что дала бы перемотка, отличается только граф. У main появилась своя линия первых родителей, где каждая влитая ветка занимает один коммит, а при перемотке коммиты metrics встали бы на эту линию в ряд с коммитами Ани. Кнопка «Merge pull request» на GitHub и метод «Merge commit» на GitLab по документации равносильны git merge --no-ff.

--ff-only устроен наоборот и разрешает только перемотку. Утром второго сентября Боря начал от 9472581 ветку server, и с main она давно разошлась:

$ git log --oneline main..server
594f818 (server) Закрывать простаивающие соединения через минуту
6f78870 Слушать порт 8081
$ git merge --ff-only server
hint: Diverging branches can't be fast-forwarded, you need to either:
hint:
hint: 	git merge --no-ff
hint:
hint: or:
hint:
hint: 	git rebase
hint:
hint: Disable this message with "git config set advice.diverging false"
fatal: Not possible to fast-forward, aborting.

Git ничего не поменял. Режим нужен там, где своих коммитов быть не должно: подтянуть локальную main к серверной или влить ветку, которую уже перебазировали на main (глава 3.3). Метод «Fast-forward merge» на GitLab равносилен git merge --ff-only. Чтобы не писать флаг каждый раз, есть merge.ff: значение false действует как --no-ff, only как --ff-only, а флаг в команде сильнее настройки. Для одной ветки есть branch.main.mergeOptions.

Слияние остановилось: merge --abort

Ветку server всё же надо влить. Боря сменил в ней порт на 8081, Аня в main на 9090, и это одно место с разными правками:

$ git merge server
Auto-merging config.go
CONFLICT (content): Merge conflict in config.go
Auto-merging main.go
Automatic merge failed; fix conflicts and then commit the result.
$ ls .git | grep -E 'MERGE|ORIG|AUTO'
AUTO_MERGE
MERGE_HEAD
MERGE_MODE
MERGE_MSG
ORIG_HEAD
$ git merge --abort
$ git status --short
$ git merge --abort
fatal: There is no merge to abort (MERGE_HEAD missing).

Пока конфликт не разобран (это глава 3.2), коммита нет и main стоит на месте. Незаконченное слияние git помнит по файлам в .git: MERGE_HEAD хранит хеш вливаемого коммита, и по нему следующий git commit запишет двух родителей. --abort возвращает индекс и рабочую копию к состоянию до слияния, по документации это то же, что git reset --merge. Второй вызов падает: отменять нечего. Слияние, которое уже стало коммитом, отменяют иначе: git reset --hard ORIG_HEAD, пока оно не отправлено, и git revert -m 1, если отправлено (глава 5.1).

С незакоммиченными правками тоньше. Правка в файле, который слиянию не нужен, ему не мешает, и --abort её сохраняет. А та же правка в индексе не даёт слиянию даже начаться, хотя в ветке server файл handlers.go не менялся:

$ echo "// TODO: кэшировать ответ" >> handlers.go
$ git merge server
Auto-merging config.go
CONFLICT (content): Merge conflict in config.go
Auto-merging main.go
Automatic merge failed; fix conflicts and then commit the result.
$ git merge --abort && git status --short
 M handlers.go
$ git add handlers.go
$ git merge server
error: Your local changes to the following files would be overwritten by merge:
  handlers.go
Merge with strategy ort failed.

Сообщение вводит в заблуждение: перезаписывать файл никто не собирался, просто git требует, чтобы индекс совпадал с HEAD, иначе посторонняя правка уехала бы в коммит слияния. Если убирать правки некогда, есть git merge --autostash: правки уйдут в stash и вернутся после коммита или --abort, правда, в рабочую копию, а не в индекс. Подсказку выполнить git stash pop при этом не слушай: правки git вернёт сам.

$ git restore --staged handlers.go
$ git merge server
Auto-merging config.go
CONFLICT (content): Merge conflict in config.go
Auto-merging main.go
Automatic merge failed; fix conflicts and then commit the result.
$ git add -A && git merge --abort && git status --short
$ tail -1 handlers.go
}
$ git fsck --dangling
Checking ref database: 100% (1/1), done.
Checking object directories: 100% (256/256), done.
dangling commit b87c49b74d746243d02891fbf1993442e094328a
dangling tree 695c6a241341f554fa3e499d952a88eb8598c293
dangling commit edf781a165c554fb9e22c363cae67fd27c568abe
$ git show b87c49b:handlers.go | tail -1
// TODO: кэшировать ответ

Стратегия ort

ort написан на замену recursive, основной стратегии с версии 0.99.9k, и стал стратегией по умолчанию в git 2.34. В 2.50 старый код удалили, и -s recursive теперь другое имя ort: git напечатает «Merge made by the 'recursive' strategy», а выполнит тот же код. Слияние ort считает целиком в памяти и только потом обновляет индекс и рабочую копию (так описаны его функции в merge-ort.h). На этом построен git merge-tree --write-tree (git 2.38): он проводит то же слияние, не трогая индекс и файлы, печатает дерево результата и возвращает 0 при чистом слиянии и 1 при конфликте. В CI им удобно проверять, вольётся ли ветка. Пересчитаем первое слияние retry:

$ git merge-tree --write-tree 03180dc^1 03180dc^2
14fb520d897de0a5b27fd45b5c701259de19ae1c
$ git rev-parse 03180dc^{tree}
14fb520d897de0a5b27fd45b5c701259de19ae1c

В том слиянии был Auto-merging store.go, хотя Боря правил db.go. Аня переименовала db.go в store.go и дописала комментарий, а переименований git не хранит (глава 1.1). ort ищет их сам, сравнивая базу с каждой стороной. Здесь он нашёл пару по похожести содержимого и применил правки Бори к новому имени. С выключенным поиском та же пара даёт конфликт:

$ git merge-tree --write-tree --name-only -X no-renames 03180dc^1 03180dc^2; echo $?
2f554d83cd8cd98c12d3405dd4ef62563e7cdb4f
db.go

Auto-merging config.go
CONFLICT (modify/delete): db.go deleted in 03180dc^1 and modified in 03180dc^2.  Version 03180dc^2 of db.go left in tree.
1

Опции самой ort передают через -X: ignore-space-change, find-renames=70%, no-renames. -X ours постоянно путают со стратегией -s ours. Сравним их на server, где один кусок конфликтует (порт), а второй сливается чисто (IdleTimeout в main.go). После каждого опыта сразу откатываемся через git reset --hard ORIG_HEAD:

$ git merge -X ours server
Auto-merging config.go
Auto-merging main.go
Merge made by the 'ort' strategy.
 main.go | 2 ++
 1 file changed, 2 insertions(+)
$ grep Addr config.go
	Addr         = ":9090"

$ git merge -s ours server
Merge made by the 'ours' strategy.
$ git diff --stat HEAD^1 HEAD

Criss-cross: два общих предка

Возьмём отдельный маленький репозиторий: в main идёт разработка, в release правят выпущенную версию, и изменения переливают в обе стороны. От коммита d0f7c42 в main отошёл ead8e38 (MaxConns поднят до 20), в release коммит 3012aac (версия 1.0.1). Аня вливает release в main. Почти в то же время Боря в своём клоне вливает main в release, но его копия main о слиянии Ани не знает и стоит на ead8e38:

$ git merge release
Merge made by the 'ort' strategy.
 version.go | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
$ git switch release
Switched to branch 'release'
$ git merge ead8e38
Merge made by the 'ort' strategy.
 pool.go | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
$ git merge-base --all main release
3012aac962d0649031fb7f13872ffb0035195a65
ead8e385d16a1d9d07fae5b3ccadfcb5db925efd

Два слияния крест-накрест дали вершинам двух лучших общих предков: 3012aac не лежит в истории ead8e38, и наоборот. Без --all команда молча печатает одного. Боря снизил MaxConns до 15 в release, Аня вернулась в main и поменяла таймаут, и теперь выбор базы решает исход. В ead8e38 MaxConns равно 20, как у Ани, и строку менял только Боря: итог 15. В 3012aac там ещё 10, и выходит, что строку поменяли обе стороны: конфликт. Стратегия resolve базы не склеивает и при построчном слиянии взяла версию из 3012aac:

$ git merge -s resolve release
Trying simple merge.
Simple merge failed, trying Automatic merge.
Auto-merging pool.go
ERROR: content conflict in pool.go
fatal: merge program failed
Automatic merge failed; fix conflicts and then commit the result.
$ grep -A4 '^<<<<<<<' pool.go
<<<<<<< .merge_file_AH9RQj
	MaxConns    = 20
=======
	MaxConns    = 15
>>>>>>> .merge_file_LFNA1T
$ git merge --abort
$ git merge release
Auto-merging pool.go
Merge made by the 'ort' strategy.
 pool.go | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
$ grep MaxConns pool.go
	MaxConns    = 15

Имена временных файлов в маркерах у каждого прогона свои. ort на том же графе конфликта не видит. Перед основным слиянием он сливает между собой сами merge-base, взяв за базу их общего предка d0f7c42: MaxConns 20 из ead8e38 плюс версия 1.0.1 из 3012aac. Этот результат становится виртуальной базой. Относительно неё строку менял один Боря, итог 15. Если merge-base больше двух, ort склеивает их по очереди, а если у пары merge-base самой несколько общих предков, спускается рекурсивно. Отсюда и название прежней стратегии.

$ git show 9472581:config.go > ../base.go
$ git show 7302ee9:config.go > ../main.go
$ git show cf9dac0:config.go > ../retry.go
$ git merge-file -p -L main -L base -L retry ../main.go ../base.go ../retry.go
package main

import "time"

const (
	Addr         = ":9090"
	ReadTimeout  = 5 * time.Second
	WriteTimeout = 10 * time.Second
	MaxRetries   = 5
	RetryBackoff = 200 * time.Millisecond
)

$ : > ../empty.go
$ git merge-file -p -L main -L empty -L retry ../main.go ../empty.go ../retry.go
package main

import "time"

const (
<<<<<<< main
	Addr         = ":9090"
	ReadTimeout  = 5 * time.Second
	WriteTimeout = 10 * time.Second
	MaxRetries   = 3
=======
	Addr         = ":8080"
	DebugSQL     = true
	ReadTimeout  = 5 * time.Second
	WriteTimeout = 10 * time.Second
	MaxRetries   = 5
	RetryBackoff = 200 * time.Millisecond
>>>>>>> retry
)

$ git merge rename
Merge made by the 'ort' strategy.
 handlers.go | 2 +-
 main.go     | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)
$ go build ./...
# shop
./v1.go:6:38: undefined: listProducts

$ git log --oneline --first-parent -4 main
9e6cbb8 (HEAD -> main) Merge branch 'metrics'
432bf6b Merge branch 'retry'
03180dc Merge branch 'retry'
7302ee9 Переименовать db.go в store.go

$ git log --oneline --first-parent -4 main
77c5ad8 (HEAD -> main, metrics) Отдавать счётчик на /metrics
70b2e32 Считать запросы к /products
432bf6b Merge branch 'retry'
03180dc Merge branch 'retry'

$ git merge-base --all main release
3012aac962d0649031fb7f13872ffb0035195a65
ead8e385d16a1d9d07fae5b3ccadfcb5db925efd

$ git merge-tree --write-tree --name-only --merge-base=3012aac b8819b4 db2ff80; echo $?
1d20e8438b570d427a5d970521b459950dd5fa02
pool.go

Auto-merging pool.go
CONFLICT (content): Merge conflict in pool.go
1
$ git merge-tree --write-tree --merge-base=ead8e38 b8819b4 db2ff80; echo $?
d8da1f4c97c247dfc673ae4ccfef0546157f3fce
0

$ git diff --stat b8819b4...db2ff80
warning: b8819b4...db2ff80: multiple merge bases, using 3012aac962d0649031fb7f13872ffb0035195a65
 pool.go | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Что стоит запомнить

• Fast-forward двигает указатель, когда текущая история является предком вливаемой ветки.
• Three-way merge сравнивает обе версии с merge-base и может записать двух родителей.
• --ff-only запрещает создавать merge commit при невозможности перемотки.

Частые ошибки

• -s ours и -X ours - разные уровни выбора.
• Второй merge той же ветки не переигрывает старые коммиты, уже достижимые через merge.

A---B---F  feature
 \
  main=A

git merge -s ours feature