Что самое важное при использовании интерактивного rebase в Git?

Что самое важное при использовании интерактивного rebase в Git?

Интерактивный rebase (git rebase -i) — мощный инструмент для чистоты истории коммитов. Рассмотрим критически важные аспекты.

Главное правило: Never rebase public history

Это самый важный принцип при работе с rebase:

# ✅ БЕЗОПАСНО — переписываем локальные коммиты
git rebase -i HEAD~3

# ❌ ОПАСНО — переписываем коммиты, которые уже в удаленном репозитории
git rebase -i origin/main
git push --force  # это сломает всем истории!

Если вы переписали историю в удаленном репозитории, коллеги получат конфликты при pull, и их локальные ветки будут несовместимы.

Основные операции в интерактивном rebase

git rebase -i HEAD~5

Ототкроется редактор с опциями:

pick abc1234 Исправление ошибки
reword def5678 Добавлен новый функционал
squash ghi9012 Добавлены тесты
fixup jkl3456 Исправлены опечатки
drop mno7890 Старый экспериментальный код

pick — сохранить коммит reword — сохранить коммит, но изменить сообщение squash — объединить с предыдущим, сохраняя оба сообщения fixup — объединить с предыдущим, но отбросить сообщение этого коммита drop — удалить коммит из истории exec — выполнить shell команду

Практический пример

Представим, нужно очистить историю из 4 коммитов:

# Исходная история:
# abc1234 Написал функцию processOrder()
# def5678 Исправил баг в processOrder()
# ghi9012 Добавил юнит-тесты
# jkl3456 Исправил опечатку в комментарии

# Запускаем интерактивный rebase
git rebase -i HEAD~4

Эдитируем список:

pick abc1234 Написал функцию processOrder()
fixup def5678 Исправил баг в processOrder()
squash ghi9012 Добавил юнит-тесты
fixup jkl3456 Исправил опечатку в комментарии

Результат: один аккуратный коммит с нужной историей.

Критичные аспекты

1. Резервная копия

Git автоматически создаёт ORIG_HEAD перед rebase. Если что-то пошло не так:

git reset --hard ORIG_HEAD  # вернуться к исходному состоянию

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

Если во время rebase возникли конфликты:

# Исправляем файлы вручную
# Затем: 
git add .
git rebase --continue

# Или отменяем весь rebase:
git rebase --abort

3. Проверка перед отправкой

# После rebase проверяем историю
git log --oneline -n 10

# Сравниваем с remote
git log --oneline origin/main..HEAD

# Только тогда пушим (обычно для своей ветки):
git push origin feature-branch

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

• Переписывайте только свои коммиты — не трогайте историю, которая уже в удалённом репо
• Проверяйте результат — git log перед push
• Используйте squash для черновиков — тесты, опечатки, исправления
• Сохраняйте осмысленные коммиты — которые описывают логические блоки работы
• Будьте осторожны с --force push — лучше никогда не использовать на public ветках

Интерактивный rebase делает историю проекта чистой и понятной, но требует дисциплины и внимания к деталям.