Git rebase: что это и как работает

Git rebase или перебазирование — инструмент, который позволяет формировать линейную историю целевой ветки. Смысл в том, что одна ветка объединяется с другой, а коммиты при этом сохраняются. Изменения можно отслеживать в правильной последовательности, поэтому складывается впечатление, будто они происходили в одной ветке.  

Выполнять Git rebase можно в двух режимах:

• Стандартном. Этот режим применяется для простого переноса коммитов одной ветки поверх другой. Команда: git rebase <базовая_ветка> (например, git rebase main). Git берет все уникальные для вашей ветки коммиты и воспроизводит их один за другим поверх последнего коммита в базовой ветке. Это позволяет синхронизировать локальную ветку с последними изменениями в главной. При этом история остается линейной, а история коммитов не редактируется.

• Интерактивном. Режим позволяет контролировать историю перед ее переносом, редактировать, удалять или объединять коммиты. Команда: git rebase -i <коммит_базовый_коммит> (например, git rebase -i HEAD~3 для редакции трех последних коммитов). Git открывает текстовый редактор, где вы можете указать, какое действие применить к каждому коммиту в списке. Это удобно, если нужно объединить мелкие исправления в логический коммит или исправить опечатку в сообщении старого коммита. Локальная история перед публикацией изменений переписывается.  

Оба режима помогают поддерживать прозрачную и чистую историю Git. Интерактивный требует большей осторожности, поскольку активно перезаписывает детали коммитов. При необдуманном использовании вы рискуете потерять часть истории. 

Процесс перебазирования можно сравнить с вырезанием и повторной вставкой коммитов в другое место в истории проекта. Рассмотрим основные принципы работы Git rebase. 

Идентификация и отмена

Представьте, что выполняете команду git rebase <базовая_ветка>, например, git rebase main из вашей ветки feature. Git определяет, какие коммиты уникальны для вашей текущей ветки и отсутствуют в базовой. Git временно отменяет эти коммиты, возвращая вашу ветку к тому состоянию, какой она была до ответвления от main.

Перемещение базы

Git переводит указатель вашей ветки на свежий коммит в базовой. Это и есть база для изменений.

«Перезагрузка» коммитов 

Git начинает последовательно применять каждый из ранее отмененных уникальных коммитов вашей ветки поверх нового базового коммита. Старые коммиты не копируются — они повторно создаются с идентичным содержимым, только уже с новым идентификатором. 

Обработка конфликтов

Конфликты — ситуации, когда изменения в одной ветке противоречат изменениям в другой. В таких случаях Git приостанавливает процесс и просит вас устранить конфликт в файлах, выполнить git add для добавления разрешенных файлов или git rebase --continue для продолжения работы с оставшимися коммитами.

Изменение истории ветки 

Интерактивный режим git rebase -i <коммит_до_которого> позволяет не просто перенести коммиты, но и редактировать их содержимое и порядок. Это поможет очистить локальную историю перед публикацией.

Вы можете переставить коммиты в списке, объединить несколько мелких коммитов в один, внести дополнительные изменения в файлы, которые уже были в истории.

Новички и даже некоторые опытные пользователи Git зачастую пренебрегают rebase, считая, что для слияния изменений достаточно операции merge. Но у этих инструментов разные задачи. При git merge коммиты остаются отдельными и видимыми в истории, при git rebase — переписываются с новыми ID, а история становится линейной. 

Используйте git merge, если:

• Объединяете публичные ветки через Pull Request.

• Работаете в команде и хотите сохранить полный контекст ветвлений. 

• Не собираетесь отслеживать каждое изменение. 

Используйте git rebase, если:

• Хотите привести локальную историю в порядок перед слиянием с общей. 

• Поддерживаете локальную ветку в актуальном состоянии.

• Работаете самостоятельно и контролируете все изменения. 

Разберем пошаговый процесс работы инструмента и конкретные примеры. 

Подготовка к rebase

Перед выполнением git rebase убедитесь, что работаете с актуальной информацией. Начинайте с обновления базовой ветки удаленного репозитория.

Команды: 

Чтобы не потерять данные, создайте резервную копию рабочей ветки. Это позволит легко откатиться назад в случае непредвиденных проблем или ошибок.

Команды:

Выполнение Git rebase 

Перейдите в ветку, которую хотите перебазировать с помощью команды git checkout feature-branch. Примените git rebase main, указав базовую ветку. Git по очереди применит все уникальные коммиты из локальной ветки feature-branch поверх последнего коммита в главной ветке main. Если не будет конфликтов, процесс завершится автоматически. 

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

Если возникнет конфликт, Git остановит процесс и сообщит, какой именно коммит его спровоцировал. Что делать дальше:

1. Откройте файлы, отмеченные как конфликтные. 

2. Внесите и сохраните изменения.

3. Добавьте разрешенные файлы в индекс: git add.

4. Возобновите процесс rebase: git rebase --continue.

5. Повторяйте шаги до тех пор, пока Git не сообщит об успешном завершении rebase.

Если не можете разрешить конфликты или хотите вернуться к исходному состоянию, используйте команду git rebase --abort. 

Пример использования

Предположим, у вас есть история коммитов, которая выглядит так:

• [C4] -- fix: добавлено форматирование;

• [C3] -- fix: исправлена ошибка в логике;

• [C2] -- feat: добавлена новая функция;

• [C1] -- initial commit. 

Цель — объединить [C3] и [C4] в один коммит с помощью git rebase -i. 

Чтобы изменить коммит [C3], нужно запустить интерактивный rebase до родительского коммита — [C2]:

Дальше нужно отредактировать список коммитов. Git откроет текстовый редактор с указанием действий для коммитов [C3] и [C4]: 

• pick C3 fix: исправлена ошибка в логике

• pick C4 fix: добавлено форматирование

Чтобы объединить [C4] с [C3], измените команду pick для [C4] на squash:

• pick C3 fix: исправлена ошибка в логике

• squash C4 fix: добавлено форматирование

Сохраните файл и закройте редактор. Git снова откроет редактор, чтобы вы объединили сообщения коммитов. Удалите старые сообщения и напишите новое. В истории вместо [C3] и [C4] появится один коммит [C3'] с новым сообщением.

Интерактивное перебазирование git rebase -i — инструмент для перезаписи и очистки локальной истории коммитов перед публикацией. Он позволяет редактировать, удалять, объединять или переупорядочивать коммиты.

Как пользоваться интерактивным режимом

Интерактивный режим запускается командой git rebase -i. Нужно указать коммит, предшествующий первому коммиту, который вы хотите изменить. Например, чтобы редактировать три последних коммита, укажите родителя третьего с конца коммита:

После выполнения команды Git откроет текстовый редактор со списком коммитов и инструкциями. Изменяйте ключевое слово (pick) перед каждым коммитом, чтобы указать системе нужное действие.

Переупорядочивание коммитов

В редакторе коммиты отображаются в хронологическом порядке — от старого к свежим. Чтобы изменить их порядок, переместите строки в списке. Например, вы хотите поставить коммит с исправлением (fix) сразу после коммита с внедрением функции (feat). Вырежьте строку с коммитом-исправлением и вставьте ее сразу под строкой с коммитом-функцией.

Изменение сообщений коммитов

Если допустили опечатку или хотите дополнить сообщение, используйте команду reword. Например, вы собираетесь изменить сообщение коммита [C2]. Замените pick на reword в строке коммита. После закрытия редактора Git откроет второй редактор, где нужно ввести новое сообщение.

Удаление коммитов

Удаление полезно для устранения коммитов, содержащих только отладочный код. Например, вы хотите убрать коммит [C3]. Замените pick на drop или вручную удалите строку с коммитом [C3] из списка.

Примеры интерактивного rebase

Наиболее распространенный сценарий использования — объединение мелких коммитов в логический блок. Например, нужно объединить три коммита (C3, C4, C5) в один с полным описанием внедряемой функции.

Исходный список коммитов после выполнения git rebase -i:

• pick 7f4d2f C3 feat: начало работы над API;

• pick 1a3b4c C4 fix: поправлен синтаксис;

• pick 5e6f7g C5 feat: добавлен обработчик ошибок.

Редактирование для объединения:

• pick 7f4d2f C3 feat: начало работы над API;

• squash 1a3b4c C4 fix: поправлен синтаксис;

• squash 5e6f7g C5 feat: добавлен обработчик ошибок. 

Git объединит C4 и C5 с C3. Затем система предложит ввести новое сообщение. Если не хотите ничего редактировать, используйте fixup вместо squash. Тогда по умолчанию будет использоваться сообщение коммита C3. 

Опция rebase при выполнении команды git pull позволяет загружать изменения из удаленного репозитория и автоматически перебазировать поверх них локальные коммиты. 

Вместо создания коммита слияния merge commit, как это делает стандартный git pull, команда git pull --rebase выполняет git fetch+git rebase.

Предположим, вы работали в ветке main и сделали два локальных коммита [L1], [L2], а коллега опубликовал один коммит [R1] в удаленном репозитории. Вам нужно слить этот коммит со своим [L2]. 

Что будет, если сделать стандартный git pull:

1. Git скачает [R1].

2. Git создаст новый коммит слияния [M], в котором объединятся [L2] и [R1].

Что будет, если сделать git pull+rebase:

1. Git скачает [R1].

2. Git временно отложит локальные коммиты [L1], [L2].

3. Git обновит вашу ветку до последнего удаленного коммита [R1].

4. Git воспроизведет ваши локальные коммиты [L1] и [L2] поверх [R1], создавая новые коммиты [L1'], [L2'].

Главное преимущество опции — чистая история без ненужных коммитов слияния, которые усложняют чтение журнала изменений. Когда вы позже будете публиковать свою ветку, удаленный репозиторий сможет выполнить быстрое слияние — fast-forward merge. 

Можно настроить Git так, чтобы он всегда использовал rebase с pull для определенной ветки или для всех веток. Команда: git config --global pull.rebase true.

Если во время выполнения rebase возникнут конфликты, их нужно разрешить и продолжить процесс с помощью git rebase --continue. Можно пойти другим путем — устранить один большой конфликт слияния позже. Но последовательное разрешение позволит сохранить чистую историю.

Поговорим о преимуществах в контексте сравнения с git merge. Выделим четыре основных.

Чистая и линейная история

При использовании git merge для интеграции изменений часто создаются коммиты слияния, которые засоряют историю. Rebase позволяет интегрировать изменения без создания лишних данных. Так формируется линейная история. В ней легче ориентироваться — искать ошибки и проверять последовательность изменений.  

Улучшенная организация коммитов 

Интерактивный режим git rebase -i предоставляет инструменты, которые помогут привести в порядок локальную историю до ее публикации. 

Устранение «шума»

Вы можете очистить промежуточные или неполные коммиты (например, те, что содержат только отладочную информацию) прежде, чем отправлять их на общий сервер. Rebase позволяет убедиться, что каждый коммит в конечной истории — это логически завершенное, работоспособное изменение.

Упрощение интеграции в основную ветку 

Rebase позволит убедиться, что ваша ветка разработана на основе самой актуальной версии основной ветки перед созданием Pull Request. Если возникнут конфликты слияния, их можно разрешить постепенно. Это проще, чем исправлять все сразу при использовании merge.

Несмотря на возможности, которые открывает команда, у нее есть минусы: 

• Изменение истории коммитов. Когда вы выполняете rebase, коммиты переписываются, что может создать проблемы при совместной работе над проектом. Изменение истории иногда приводит к конфликтам версий и потере данных. Получается, что другим участникам репозитория придется работать с устаревшей историей.

• Риски при работе с чужими ветками. Опасно без разрешения использовать rebase для переписывания истории чужих веток. Другие участники могут столкнуться с трудностями при обновлении своих локальных копий. 

• Потеря коммитов. Если при использовании rebase возникнут конфликты версий, коммиты могут случайно удалиться. Если не будете разрешать конфликты правильно, рискуете потерять изменения, которые были сделаны в процессе перезаписи истории.

• Сложности в случае конфликтов.  В отличие от merge, где конфликты происходят только один раз, при использовании rebase конфликты могут возникать на каждом шаге перезаписи коммитов.

• Невозможность использования на публичных ветках. В этом случае rebase применять рискованно, поскольку вы можете создать проблему для других участников, которые работают с этими ветками.

• Не всегда прозрачная история. Другим участникам проекта может быть сложно отслеживать коммиты, из-за того, что теряется контекст некоторых изменений.

• Проблемы при отмене. Отменить rebase сложнее, чем merge, поскольку изменения будут переписаны.  

Чтобы избежать сложностей, взвесьте все минусы перед использованием команды. Применяйте git rebase только в том случае, если умеете работать с этим инструментом. 

Git rebase — полезный инструмент для работы с локальными личными ветками. Он поможет подготовить их к финальному слиянию. Не перебазируйте ветки, которые уже были отправлены в общий репозиторий и используются вашими коллегами. В таком случае применяйте git merge. Освойте этот инструмент и уже потом переходите к git rebase.

Если вы ищете российский сервис с полным набором инструментов для управления версиями и автоматизации разработки, обратите внимание на Advanced CodeArts Repo от Cloud.ru. Это многофункциональное решение, которое предоставляет все необходимое для полного цикла разработки: от управления репозиториями Git и совместной работы с кодом до автоматизированного тестирования, CI/CD-пайплайнов и развертывания решений. Advanced CodeArts объединяет функциональность GitHub, GitLab и Azure DevOps в единой консоли, позволяя командам разработчиков работать эффективнее без необходимости интегрировать множество отдельных инструментов.