12k
All articles

Git Rebase для начинающих: простое введение

Git rebase переносит коммиты на целевые ветки, формируя чистую линейную историю. Статья охватывает интерактивный squash и force push для feature-веток.

OpenReplay Team
OpenReplay Team
Git Rebase для начинающих: простое введение

Если вы когда-либо смотрели на историю Git и думали «какой же это беспорядок», вы не одиноки. Эти запутанные линии веток и избыточные коммиты слияния затрудняют понимание того, что на самом деле изменилось и когда. Именно здесь на помощь приходит git rebase — мощный инструмент, который помогает поддерживать чистую, читаемую историю коммитов.

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

Ключевые выводы

  • Git rebase воспроизводит коммиты поверх другой ветки, создавая линейную историю
  • Используйте rebase для поддержания актуальности веток функций и очистки коммитов перед публикацией
  • Никогда не делайте rebase веток, над которыми работают другие
  • Интерактивный rebase позволяет объединять, переупорядочивать и редактировать коммиты
  • Используйте force push с флагом --force-with-lease для безопасности после rebase

Что такое Git Rebase?

Думайте о git rebase как о переписывании истории — но в хорошем смысле. Когда вы делаете rebase, вы берёте коммиты из одной ветки и воспроизводите их поверх другой ветки, как если бы вы начали свою работу с другой точки.

Представьте, что вы пишете рассказ. Вы начинаете главу 3, пока ваш коллега всё ещё редактирует главу 2. Когда он закончит, вы можете либо:

  • Сделать merge: добавить примечание «здесь вставлены изменения коллеги из главы 2»
  • Сделать rebase: переписать вашу главу 3, как если бы вы начали её после того, как глава 2 уже была завершена

Подход с rebase даёт вам более чистое повествование без «шума слияния».

Зачем использовать Git Rebase?

Поддержание линейной и чистой истории

Линейная история читается как книга — один коммит следует за другим в чёткой последовательности. Это упрощает:

  • Отслеживание момента внесения ошибок
  • Понимание эволюции функций
  • Просмотр изменений кода в pull request’ах

Без rebase ваша история заполняется коммитами слияния, которые многократно говорят «Merged branch ‘main’ into feature-xyz», скрывая фактическую выполненную работу.

Когда разработчики выбирают Rebase

Разработчики обращаются к rebase в двух основных ситуациях:

  1. Поддержание актуальности: ваша ветка функции нуждается в последних обновлениях из main
  2. Полировка работы: вы хотите очистить коммиты перед тем, как другие их просмотрят

Оба сценария помогают поддерживать ту чистую, линейную историю, которая упрощает жизнь всем.

Git Rebase против Merge: ключевые различия

Вот фундаментальное различие:

Merge создаёт новый коммит, который объединяет две ветки:

A---B---C (main)
     \   \
      D---E---M (your-feature)

Rebase воспроизводит ваши коммиты поверх целевой ветки:

A---B---C (main)
         \
          D'---E' (your-feature)

Обратите внимание, как rebase создаёт новые коммиты (D’ и E’), в то время как merge добавляет коммит слияния (M). Результат rebase линейный и чистый, в то время как merge сохраняет точную историю, но добавляет сложность.

Распространённые случаи использования Git Rebase

Обновление вашей ветки функции

Вы работаете над функцией, пока ваша команда отправляет обновления в main. Чтобы включить их изменения:

git checkout your-feature-branch
git rebase main

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

Очистка коммитов перед Pull Request

Перед публикацией вашей работы вы можете захотеть привести в порядок ваши коммиты. Интерактивный rebase позволяет:

git rebase -i HEAD~3

Это открывает редактор, где вы можете:

  • Объединить несколько коммитов «work in progress» в один
  • Переупорядочить коммиты для логического потока
  • Отредактировать сообщения коммитов для ясности

Например, превратить это:

- Fix typo
- WIP: add login
- More login stuff
- Fix tests

В это:

- Add user login functionality with tests

Важные предупреждения: когда НЕ использовать Rebase

Золотое правило: не делайте Rebase общих веток

Никогда не делайте rebase веток, над которыми работают другие. Когда вы делаете rebase, вы создаёте новые коммиты с разными SHA-1 хешами. Если у кого-то ещё есть старые коммиты, Git путается и создаёт дублирующиеся коммиты.

Безопасно делать rebase: вашу локальную ветку функции
Никогда не делайте rebase: main, develop или любую ветку, которую используют другие

Понимание рисков Force Push

После rebase вам часто потребуется принудительный push:

git push --force-with-lease origin your-feature-branch

Флаг --force-with-lease безопаснее, чем --force, потому что он проверяет, что никто другой не отправлял изменения с момента вашего последнего pull. Тем не менее, делайте force push только для веток, которыми вы владеете.

Начало работы с Git Rebase

Вот простой рабочий процесс для практики:

  1. Создайте ветку функции из main
  2. Сделайте несколько коммитов
  3. Тем временем main получает обновления
  4. Сделайте rebase вашей ветки функции:
    git checkout feature-branch
    git rebase main
  5. Если возникают конфликты, разрешите их и продолжите:
    git add .
    git rebase --continue

Начните с ваших локальных веток, чтобы обрести уверенность, прежде чем делать rebase чего-либо общедоступного.

Заключение

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

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

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

Могу ли я отменить rebase, если что-то пошло не так?

Да, вы можете использовать git reflog, чтобы найти хеш коммита до rebase, а затем использовать git reset --hard, чтобы вернуться к этому состоянию. Git ведёт локальную историю того, куда указывал HEAD, поэтому вы можете восстановиться после большинства ошибок.

В чём разница между git pull и git pull --rebase?

Git pull выполняет fetch, за которым следует merge, создавая коммит слияния. Git pull --rebase выполняет fetch, за которым следует rebase, воспроизводя ваши локальные коммиты поверх удалённой ветки для более чистой истории.

Должен ли я всегда использовать rebase вместо merge?

Нет, у обоих есть своё место. Используйте rebase для локальной очистки и поддержания актуальности веток функций. Используйте merge для объединения завершённых функций в основные ветки, где важно сохранение полной истории.

Как прервать выполняющийся rebase?

Выполните git rebase --abort, чтобы остановить rebase и вернуть вашу ветку в исходное состояние до начала rebase. Это работает, когда вы находитесь в процессе разрешения конфликтов или в любой момент во время интерактивного rebase.

Understand every bug

Uncover frustrations, understand bugs and fix slowdowns like never before with OpenReplay — self-hosted, with full data ownership.

Star on GitHub

We use cookies to improve your experience. By using our site, you accept cookies.