Как откатить Rebase?

Хороший и важный вопрос. Откат rebase — это навык, который четко отделяет начинающих Git-пользователей от опытных. Стратегия зависит от того, успели ли вы отправить (push) изменения в общий репозиторий и на каком этапе находитесь.

📌 Основные стратегии отката

1. Откат rebase, если вы НЕ делали push (локальный rebase)

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

Способ А: Использование ORIG_HEAD (самый прямой)

При выполнении многих операций (merge, rebase, reset) Git сохраняет предыдущий указатель HEAD в специальную ссылку ORIG_HEAD. Это ваш спасательный круг.

# Вернет состояние ветки до начала rebase
git reset --hard ORIG_HEAD

Важно: ORIG_HEAD перезаписывается каждой новой операцией, поэтому используйте этот метод сразу после неудачного rebase.

Способ Б: Использование Reflog (самый универсальный и мощный)

git reflog показывает хронологию всех перемещений указателя HEAD в вашем локальном репозитории. Это ключ к восстановлению почти любой "потерянной" работы.

1. Найдите в логе состояние до rebase:

   git reflog
   # Вы увидите что-то вроде:
   # c1d2f3b (HEAD -> feature-branch) HEAD@{0}: rebase (finish): returning to refs/heads/feature-branch
   # a1b2c3d HEAD@{1}: rebase (pick): Add new login feature
   # 5e6f7a8 HEAD@{2}: rebase (start): checkout main
   # 876e123 HEAD@{3}: commit: My last good commit before rebase # <-- НАША ЦЕЛЬ
   # 654d321 HEAD@{4}: commit: Another old commit
   

2. Сбросьте ветку на нужный коммит, используя его хэш (876e123) или относительную ссылку (HEAD@{3}):

   git reset --hard HEAD@{3}
   # или
   git reset --hard 876e123
   

Способ В: Отмена интерактивного rebase в процессе

Если вы в середине интерактивного rebase и столкнулись с конфликтом, который хотите прервать:

git rebase --abort

Эта команда полностью прервет процесс и вернет ветку в исходное состояние.

---

2. Откат rebase, если вы уже сделали PUSH в общий репозиторий

Золотое правило: Не делайте git push --force (или --force-with-lease), чтобы откатить публичный rebase, если в вашей ветке могли работать другие разработчики. Вы перезапишете их историю. Вместо этого нужно выполнить новый, корректирующий коммит.

Способ А: Revert корректирующего коммита

Это самый безопасный для команды метод. Вы создаете новый коммит, который "отменяет" все изменения, привнесенные rebase.

1. Найдите общий предок вашей ветки до и после rebase (можно через reflog или git log --oneline --graph --all).
2. Создайте новый коммит, который является обратным (revert) к коммиту, с которого начался rebase, или сделайте revert для каждого нового коммита из rebase-последовательности.

   # Это может быть сложно. Часто проще "отменить" весь rebase,
   # вернувшись к старому состоянию и сделав merge.
   

Способ Б: Аккуратный принудительный push (если вы уверены, что вы одни в ветке)

Если вы на 100% уверены, что никто не брал вашу ветку после вашего push, можно:

1. Сначала локально откатиться к состоянию до rebase, используя reflog (как описано выше).
2. Затем выполнить принудительный push с арендой (safer force push):

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

    Ключевое отличие `--force-with-lease` от `--force`: команда **провалится**, если удаленная ветка была изменена кем-то еще, предотвращая случайное перезатирание чужой работы.

---

🛠️ Практический пример (пошагово)

Допустим, вы испортили историю в локальной ветке feature/login при rebase на main.

# 1. Прервать текущий, возможно, конфликтный rebase
git rebase --abort

# 2. Посмотреть историю действий
git reflog show feature/login

# 3. Идентифицировать хэш последнего хорошего коммита (до rebase)
# Например: abc1234

# 4. Жесткий сброс ветки на этот коммит
git reset --hard abc1234

# 5. Если rebase был простой и не было других коммитов, можно было проще:
git reset --hard ORIG_HEAD

# 6. Если вы уже запушили, ОСТАНОВИТЕСЬ. Оцените, брал ли кто ветку.
# Если нет — сделайте безопасный принудительный пуш:
git push --force-with-lease origin feature/login

✅ Выводы и лучшие практики

• Reflog — ваша страховка. Он хранится локально и обычно содержит историю за 30-90 дней.
• Перед rebase всегда создавайте резервную ветку. Это самый надежный способ.

  git checkout -b feature-backup-before-rebase
  

• Никогда не переписывайте публичную историю (force push) без крайней необходимости и согласования. Используйте --force-with-lease.
• Для сложных публичных откатов иногда проще создать новую ветку из последнего известного хорошего состояния и перенести туда нужные изменения через cherry-pick, чем пытаться "чинить" испорченную историю.

Помните: умение уверенно откатывать rebase не означает, что можно им пренебрегать. Это страховка, которая позволяет экспериментировать и учиться без страха что-то сломать.