Откат изменений в Git без паники: безопасный алгоритм

Откат в Git занимает несколько минут, если сначала сохранить текущее состояние и только потом выбрать команду. В этой инструкции для Git 2.x вы научитесь отменять последний коммит, убирать изменения из рабочего каталога, безопасно откатывать общую ветку и восстанавливать потерянную ссылку через reflog.

Что нужно проверить до начала

Команды ниже рассчитаны на Git 2.x и обычный репозиторий с локальной рабочей копией. Перед откатом вам понадобятся:

• доступ к терминалу и папке репозитория;
• понимание имени ветки, с которой вы работаете;
• чистая или осознанно изменённая рабочая копия;
• локальная копия последних коммитов, если откат касается удалённой ветки.

Сначала проверьте состояние:

git status

git branch --show-current
git log --oneline --decorate -n 10

Проверка результата: Git покажет текущую ветку, список изменённых файлов и последние десять коммитов. Запишите хеш коммита, к которому хотите вернуться.

Если в рабочей копии есть нужные незакоммиченные изменения, не начинайте с git reset --hard. Сохраните их во временный stash:

git stash push -u -m "backup before rollback"

Ключ -u включает в stash неотслеживаемые файлы. Проверка: команда завершится сообщением о сохранении состояния, а git status покажет чистую рабочую копию.

Сноска. HEAD — указатель на текущий коммит. Если команда меняет HEAD, она перемещает указатель ветки или создаёт новый коммит поверх текущего состояния.

Безопасный алгоритм отката

1. Создайте резервную ветку. Она сохранит ссылку на текущую точку, даже если следующий шаг переместит основную ветку.

   git switch -c backup-before-rollback

   Проверка: команда git branch отметит новую ветку звёздочкой. Если резервная ветка уже создана, используйте другое имя.
2. Вернитесь в рабочую ветку. Подставьте её фактическое имя вместо main или develop.

   git switch main

   Проверка: git branch --show-current напечатает нужное имя. Если Git сообщает, что есть незакоммиченные изменения, сначала сохраните их через stash или отдельный коммит.
3. Определите тип отмены. Если коммит уже попал в общую ветку, обычно нужен новый отменяющий коммит. Если это только ваша локальная ветка, можно переместить её указатель с помощью reset.

   git show --stat --oneline HEAD
   git log --oneline --decorate -n 5

   Проверка: вы видите, какой именно коммит отменяете, и понимаете, опубликован ли он в удалённом репозитории.
4. Отмените опубликованный коммит через revert. Для последнего коммита:

   git revert HEAD

   Git откроет редактор сообщения нового коммита. Сохраните сообщение и закройте редактор. Проверка: git log --oneline -n 2 покажет новый коммит с отменой, а git status — чистую рабочую копию, если конфликтов нет.
5. Откатите локальную ветку через reset, если переписывание истории допустимо. Выберите режим по результату, который нужен:

   # Убрать последний коммит, оставив изменения подготовленными к коммиту
   git reset --soft HEAD~1
   
   # Убрать последний коммит, оставив изменения в рабочих файлах
   git reset HEAD~1
   
   # Убрать последний коммит и удалить его изменения из рабочей копии
   git reset --hard HEAD~1

   Проверка: выполните git status и git log --oneline -n 3. В первом случае изменения попадут в staged, во втором останутся unstaged, в третьем рабочие файлы вернутся к предыдущему коммиту.
6. Отправьте безопасный откат на сервер. После revert используется обычная отправка:

   git push origin main

   Проверка: удалённый репозиторий покажет новый отменяющий коммит. После локального reset обычный push может быть отклонён, потому что история ветки стала короче. Не используйте принудительную отправку, пока не согласовали её с командой и не проверили резервную ветку.

Как выбрать между revert, reset и restore

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

Чтобы вернуть файл из последнего коммита, используйте:

git restore --source=HEAD -- path/to/file

Проверка: git diff -- path/to/file больше не показывает локальные изменения файла. Укажите точный путь и проверьте его до запуска команды.

Главное правило: опубликованную историю обычно отменяют новым коммитом, а не стирают перемещением указателя.

Что ломается и как восстановиться

Конфликт при revert

Если изменения последнего коммита пересекаются с более новыми правками, Git остановится с сообщением о конфликте. Откройте отмеченные файлы, оставьте правильный вариант, затем добавьте их и завершите отмену:

git status
git add path/to/conflicted-file
git revert --continue

Проверка: команда завершится созданием отменяющего коммита. Если вы передумали, используйте git revert --abort, пока операция не завершена.

Reset удалил то, что было нужно

Сначала ничего не делайте поверх этой ветки и найдите старое положение HEAD:

git reflog --date=local -n 10

В выводе найдите строку до ошибочного reset и её идентификатор. Создайте от него спасательную ветку:

git switch -c recovery-after-reset <commit-id>

Проверка: git log --oneline -n 5 в новой ветке покажет потерянный коммит. reflog хранит локальную историю перемещения ссылок, но это не замена резервной копии: записи могут исчезнуть после очистки репозитория.

Git не даёт переключить ветку

Сообщение вроде Your local changes to the following files would be overwritten by checkout означает, что переключение затрёт локальные изменения. Сохраните их через stash, отдельный коммит или копию файлов, затем повторите переключение.

Push отклонён после reset

Ошибка rejected (non-fast-forward) означает, что удалённая ветка содержит историю, которой нет в вашей локальной ветке. Не исправляйте это автоматическим --force. Сначала обсудите откат, проверьте резервную ветку и правила репозитория. Если переписывание действительно разрешено, используйте более безопасный вариант принудительной отправки только после проверки, что удалённая ветка не получила новые коммиты.

Что делать после отката

Запустите тесты и сборку до отправки результата в удалённый репозиторий. Проверьте не только изменённые файлы, но и миграции базы данных, конфигурацию и зависимости: отмена коммита в Git не откатывает внешние действия, уже выполненные в базе или инфраструктуре.

Оставьте резервную ветку до завершения проверки на CI, а затем удалите её локально, если она больше не нужна:

git branch -d backup-before-rollback

Следующий полезный шаг — договориться в команде, какие ветки считаются общими и когда разрешён reset. Отдельно проверьте, как проект восстанавливается после ошибочного push: этот сценарий стоит отработать до инцидента, а не во время него.