Ваша ветка функциональности отстаёт от main, а новая работа вам нужна. Git merge vs rebase — это выбор между двумя способами её получить, и оба верны. Они различаются тем, как выглядит история после.

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

Что делают git merge и git rebase

git merge берёт вершины двух веток и объединяет их. Если в обеих есть новые коммиты, Git создаёт коммит слияния с двумя родителями. Ничто из существующего не меняется.

git rebase берёт коммиты, которые есть только в вашей ветке, откладывает их, переносит вашу ветку на вершину другой и затем воспроизводит ваши коммиты один за другим. Воспроизведённые коммиты — это новые коммиты с новыми хешами, хотя изменения в них те же.

Git merge на практике

Наша отправная точка: коммит A в main, два коммита (F1, F2) в feature и ещё один коммит (M1), добавленный затем в main. Теперь сливаем main в feature.

git switch feature
git merge main
git log --oneline --graph

*   f507aab Merge main into feature
|\
| * 8842fb5 M1
* | 082cc6a F2
* | 5a71e3c F1
|/
* 8766865 A

Граф показывает настоящую историю: две линии работы, которые соединили. Исходные коммиты F1 и F2 сохраняют свои хеши. Цена — лишний коммит слияния, а в оживлённом проекте граф превращается в паутину.

Git rebase на практике

Та же отправная точка, но теперь мы делаем rebase feature на main.

git switch feature
git rebase main
git log --oneline --graph

* 1ff474b F2
* bf9149e F1
* 8842fb5 M1
* 8766865 A

История — одна прямая линия, будто вы начали работу после M1. Посмотрите на хеши: F1 был 5a71e3c, а стал bf9149e; F2 изменился с 082cc6a на 1ff474b. Git переписал их, поэтому rebase требует осторожности.

Merge и rebase рядом

Золотое правило rebase

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

Делать rebase своей приватной ветки функциональности нормально. Делать его для main или любой ветки, которой пользуются другие, — нет.

Безопасный рабочий процесс для команды

Эта процедура сохраняет историю чистой и никого не удивляет. Так же поступает большинство команд перед CI-конвейером, например таким, как в нашем руководстве по GitHub Actions CI/CD (на английском).

git switch feature
git fetch origin
git rebase origin/main        # or: git pull --rebase
# fix conflicts, then: git add <file> && git rebase --continue
git push --force-with-lease   # only on your own branch

--force-with-lease отказывается перезаписывать ветку на сервере, если с вашего последнего fetch туда кто-то отправил изменения, — обычный --force молча уничтожил бы их. Когда pull request одобрен, слейте его в main.

Как отменить неудачный rebase

Rebase выглядит разрушительным, но старые коммиты некоторое время остаются в reflog Git, так что можно вернуться.

git reflog                    # find the commit before the rebase
git reset --hard HEAD@{5}     # example position, check reflog first

Создайте резервную ветку командой git branch backup перед любым рискованным rebase, и восстановление сведётся к одной команде. Запускаете базу данных или инструменты в контейнерах? Загляните в наш учебник по Docker для начинающих (на английском).

Итоги

Merge хранит правду, rebase держит её в порядке. Используйте rebase, чтобы обновить свою ветку, merge — чтобы доставить её, и никогда не переписывайте историю, от которой зависят другие.

Часто задаваемые вопросы

Продолжайте изучать (статьи на английском)