git rebase: основы

Перенос коммитов из одной ветки на вершину другой — для создания линейной, чистой истории без лишних merge-commit-ов.

Зачем нужно

Пока разработчик работает в feature-ветке, main продолжает обновляться. git rebase «перебазирует» feature-ветку — берёт все её коммиты и повторно применяет их поверх актуального состояния main. Результат — линейная история без «ромбов» от merge. Многие команды предпочитают rebase-workflow, потому что история читается как единая цепочка событий.

Где используется

  • Актуализация feature-ветки перед созданием Pull Request
  • Поддержка линейной истории в проектах с rebase-политикой
  • git pull --rebase — загрузить изменения без merge-commit
  • Очистка истории перед merge через интерактивный rebase

Основной контент

Как работает rebase

До rebase:
  main:    A---B---E---F
                \
  feature:       C---D

После git rebase main (из ветки feature):
  main:    A---B---E---F
                        \
  feature:               C'---D'

Коммиты C и D «пересозданы» как C' и D' с новыми хэшами поверх F.

Команды

# Перебазировать текущую ветку на main
git switch feature/auth
git rebase main

# Если возник конфликт — разрешить, добавить в staging и продолжить
git add src/auth.js
git rebase --continue

# Пропустить конфликтный коммит (редко нужно)
git rebase --skip

# Прервать rebase и вернуться к исходному состоянию
git rebase --abort

# Rebase конкретной ветки на другую
git rebase main feature/auth

# Pull через rebase (не создаёт merge-commit)
git pull --rebase origin main

Типичный workflow с rebase

# 1. Работаем в feature-ветке
git switch feature/payment

# 2. Main обновился — актуализируем ветку
git fetch origin
git rebase origin/main

# 3. Разрешаем конфликты если есть
# ... редактируем файлы ...
git add .
git rebase --continue

# 4. Push с --force-with-lease (хэши коммитов изменились)
git push --force-with-lease origin feature/payment

# 5. Создаём PR — история чистая и линейная

Rebase vs Merge: когда что использовать

Ситуация Что использовать
Публичная ветка (main, develop) Merge
Личная feature-ветка Rebase
git pull в командном проекте git pull --rebase
Сохранить историю ветки Merge --no-ff

Золотое правило rebase: никогда не делай rebase ветки, которую используют другие разработчики.

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

  • Rebase опубликованной ветки без --force-with-lease — хэши изменились, обычный push будет отклонён
  • --force вместо --force-with-lease — --force перезапишет удалённую ветку даже если кто-то уже push-нул в неё
  • Rebase общей ветки — коллеги получат конфликты истории при следующем pull; rebase только личных веток
  • Не прерывать rebase при запутанных конфликтах — лучше git rebase --abort и разобраться с ситуацией

Связанные темы

Ресурсы