Для чего нужен git rebase?

Для чего нужен git rebase

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

Основная идея: перемещение коммитов

rebase 'перемещает' ваши коммиты поверх другой ветки:

# Исходная история (две ветки)
main:     A - B - C
feature:        \- D - E

# После git rebase main feature
# Коммиты D и E 'пересажены' на C
main:     A - B - C
feature:           \- D' - E'

1. Синхронизация ветки с main

Когда основная ветка получает новые коммиты, ваша ветка становится 'отсталой':

# Ситуация: другие разработчики добавили коммиты
main:     A - B - C - F - G (новые коммиты)
feature:        \- D - E (ваша работа)

# Вариант 1: git merge (создает merge коммит)
git checkout feature
git merge main
# Результат: A - B - C - F - G
#                      \      /
#                   D - E - M (merge коммит)

# Вариант 2: git rebase (перемещает коммиты)
git checkout feature
git rebase main
# Результат: A - B - C - F - G - D' - E' (чистая линия)

2. Очистка локальной истории (before push)

ВАЖНО: Используй rebase только на локальных коммитах, еще не отправленных на сервер!

# Допустим ты написал 5 коммитов с описаниями:
# - Добавил функцию
# - Исправил опечатку
# - Добавил тесты
# - Исправил баг в тестах
# - Добавил комментарии

# Можно объединить в 1-2 логичных коммита
git rebase -i HEAD~5
# Откроется интерактивный режим

3. Интерактивный rebase (git rebase -i)

Позволяет переписать, объединить, удалить или переупорядочить коммиты:

# Начать интерактивный rebase последних 3 коммитов
git rebase -i HEAD~3

# Откроется редактор с коммитами:
# pick a1b2c3 Добавил функцию
# pick d4e5f6 Исправил опечатку
# pick g7h8i9 Добавил тесты

# Команды:
# pick   = использовать коммит
# reword = использовать, но изменить message
# squash = использовать, объединить с предыдущим
# fixup  = как squash, но без сообщения
# drop   = удалить коммит
# exec   = выполнить команду

# Пример: объединить коммиты
# pick a1b2c3 Добавил функцию
# squash d4e5f6 Исправил опечатку
# squash g7h8i9 Добавил тесты

# Результат: 1 коммит с объединенным сообщением

4. Переписать коммит

# Изменить сообщение последнего коммита
git commit --amend

# Через rebase
git rebase -i HEAD~1
# Изменить 'pick' на 'reword'

5. Удалить коммит

# Удалить последний коммит (локально)
git rebase -i HEAD~2
# drop старый коммит

Практический пример: очистка перед pull request

# Твоя история (грязная):
git log --oneline
# abc1234 Добавил функцию
# def5678 Исправил опечатку
# ghi9101 Добавил тесты
# jkl1213 Исправил баг в тестах
# mno1415 Добавил комментарии

# Сделать интерактивный rebase
git rebase -i HEAD~5

# Отредактировать:
# pick abc1234 Добавил функцию
# squash def5678 Исправил опечатку
# squash ghi9101 Добавил тесты
# squash jkl1213 Исправил баг в тестах
# squash mno1415 Добавил комментарии

# После сохранения - будет 1 чистый коммит

Сравнение: merge vs rebase

git merge:

main:  A - B - C - D
feat:       \- E - F

# После merge
main:  A - B - C - D
feat:       \- E - F
          \       /
           M (merge)

# Плюсы: полная история, безопасно
# Минусы: много merge коммитов, грязная история

git rebase:

main:  A - B - C - D
feat:       \- E - F

# После rebase
main:  A - B - C - D
feat:             \- E' - F'

# Плюсы: чистая линейная история
# Минусы: переписывает историю, опасно на shared ветках

ВАЖНЫЕ ПРАВИЛА

Правило 1: Никогда не rebase shared ветку

# ❌ НИКОГДА НЕ ДЕЛАЙ ЭТО
git checkout main
git rebase development
git push --force origin main
# Это сломает всем историю!

# ✅ Только локально
git checkout feature
git rebase main  # Переместить свою ветку
# Если уже push-нули, нужна force push (опасно)

Правило 2: Rebase перед push, merge после push

# Правильный workflow
1. Создаешь feature ветку
   git checkout -b feature
   # пишешь код (5 коммитов)

2. Очищаешь коммиты (rebase -i)
   git rebase -i HEAD~5
   # объединяешь в 1-2 коммита

3. Синхронизируешь с main (rebase)
   git rebase main
   # перемещаешь на свежий main

4. Push
   git push origin feature

5. Создаешь pull request

6. После одобрения - merge в main (через PR)
   # Другие видят историю через merge коммит

Правило 3: Никогда не меняй публичные коммиты

# ❌ ПЛОХО
git rebase -i HEAD~10  # Меняешь старые коммиты
git push --force       # Переписываешь историю на сервере

# ✅ ХОРОШО
# Меняешь только локальные, непубликованные коммиты
git log origin/main..HEAD  # Показывает твои локальные коммиты
# Их безопасно переписывать

Практические команды

# Обновить ветку с latest main
git fetch origin
git rebase origin/main

# Если конфликты - разрешить и продолжить
git status
# Исправить файлы
git add .
git rebase --continue

# Отменить rebase если что-то пошло не так
git rebase --abort

# Объединить последние 3 коммита
git rebase -i HEAD~3
# Выбрать squash для последних двух

# Изменить сообщение последнего коммита
git commit --amend

# Переместить ветку на main и отправить
git rebase main
git push origin feature

Когда НЕ использовать rebase

1. На shared ветках (main, develop) - используй merge
2. После push - только если уверен, что никто не pull-ил
3. Для важных версий - используй merge с --no-ff флагом
4. Если многие люди работают на ветке - слишком рискованно

Итого

Git rebase это инструмент для:

• Очистки локальной истории перед push
• Синхронизации ветки с main
• Объединения логически связанных коммитов
• Переписи истории ДО того как другие ее видят

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