Восстановление файлов после revert в Git

Быстрые ссылки

• Не паникуйте
• Исправление revert-коммитов
• Откат без следов
• Альтернативные методы и проверка

Не паникуйте

К счастью, Git хранит всю историю в директории .git. Даже если вы видите, что файлы удалены в рабочем каталоге, данные обычно остаются в истории репозитория и могут быть восстановлены.

Важно понять разницу между операциями:

• commit: создаёт снимок и сохраняет изменения в истории.
• revert: создаёт новый коммит, который отменяет изменения целевого коммита.
• reset (soft): возвращает указатель HEAD, оставляя файлы в индексе и рабочем каталоге.
• reset (hard): перезаписывает индекс и рабочий каталог состоянием указанного коммита.

Пример типичной ошибки: вы инициализировали репозиторий, забыли .gitignore и случайно закоммитили ./bin/ и лишние файлы. Потом нажали «revert» в GUI, и рабочая директория очистилась. Это выглядело как удаление, но в истории есть и первоначальный коммит, и коммит-отмена.

Как работает revert и почему файлы могут исчезать

Команда git revert создаёт новый коммит с противоположными изменениями. Если исходный коммит добавил файл, то revert создаст коммит, который удалит этот файл. В результате в истории появится коммит-удаление, и рабочая копия покажет файл как удалённый.

Если вы хотите отменить сам revert (то есть вернуть файлы обратно), нужно применить обратную операцию к коммиту-реверту.

Исправление revert-коммитов (простой способ)

1. Найдите хеш коммита, который сделал revert (или хеш любого коммита, который удалил файл):

git log --oneline --graph

2. Скопируйте хеш коммита-реверта и выполните обратный revert — то есть revert самого коммита-реверта. Это создаст новый коммит, который вернёт изменения обратно:

git revert 

Пример:

git revert 62ff517cc7c358eaf0bffdebbbe1b38dea92ba0f

Если автоматический коммит не прошёл, Git сообщит об этом — тогда откройте редактор, разрешите конфликт (если есть), и вручную завершите коммит.

В GUI-клиентах процесс обычно проще: выберите коммит-реверт и нажмите «revert» ещё раз.

Важно: если репозиторий публичный и вы уже запушили коммиты, обратные коммиты сохранятся в истории и будут видны другим участникам.

Откат без следов (когда вы ещё не пушили)

Если вы находитесь на HEAD и ещё не отправили изменения в удалённый репозиторий, можно выполнить «жёсткий» reset к предыдущему коммиту. Это удалит из рабочего каталога изменения, внесённые коммитом-ревертом, без создания новых коммитов:

git reset --hard HEAD^

Пояснение: нужно именно –hard, потому что soft-reset оставит незакоммиченные изменения от revert в рабочем каталоге и индексе. Жёсткий сброс полностью синхронизирует рабочую копию и индекс с выбранным коммитом.

Предупреждение: git reset –hard удаляет незакоммиченные локальные изменения. Не выполняйте его, если есть важные несохранённые правки — сначала сохраните их патчем или в отдельную ветку.

Альтернативные методы и когда использовать их

• git restore (новые версии Git):

git restore --source= -- 

Эта команда восстанавливает конкретный файл из указанного коммита без изменения HEAD.

• git checkout – : работает во всех версиях Git и аналогичен git restore для файла.

• git reflog: если вы потеряли хеш, reflog покажет перемещения HEAD и позволит найти нужный снимок:

git reflog

Затем можно сделать:

git checkout  -- 

• Если есть «висячие» объекты (dangling commits), можно использовать git fsck –lost-found, но это продвинутая операция и обычно не нужна при обычных revert/reset сценариях.

Мини-методология: шаги восстановления (рекомендации)

1. Остановитесь. Не выполняйте следующие destructive-команды, если не уверены.
2. Посмотрите историю: git log –oneline –graph и git reflog.
3. Если revert-коммит существует и вы хотите просто отменить его — выполните git revert .
4. Если вы ещё не пушили и хотите просто убрать следы — используйте git reset –hard (например HEAD^).
5. Чтобы восстановить отдельный файл, используйте git checkout – path или git restore –source= – path.
6. Проверьте рабочую директорию и тесты. Закоммитьте и запушьте лишь после проверки.

Когда это не сработает и альтернативы

• Если вы уже запушили и другие разработчики базируются на этих коммитах, принудительное переписывание истории (git push –force) может нарушить чужие ветки. В таких ситуациях предпочтительнее создать обратный revert-коммит.
• Если объекты были удалены GC (редко, и только после длительного времени), восстановление может быть сложнее. В этом случае используйте git reflog и поиски по резервным копиям.

Контрольный список по ролям

• Для разработчика:
  • Найти нужный коммит через git log или git reflog.
  • Попробовать git checkout/restore для отдельных файлов.
  • Выполнить git revert или git reset –hard, в зависимости от ситуации.
  • Протестировать локально.
• Для релиз-менеджера:
  • Проверить, были ли изменения запушены.
  • Оценить влияние на CI/CD и коллаборацию.
  • Рекомендовать revert-коммит вместо форс-пуша, если ветка общая.

Краткий глоссарий в одну строчку

• commit: снимок изменений, сохранённый в истории.
• revert: новый коммит, отменяющий изменения предыдущего.
• reset: смещает HEAD; –soft сохраняет изменения в индексе, –hard — перезаписывает рабочую копию.
• reflog: журнал перемещений HEAD и ссылок.
• HEAD: указатель на текущую ветку/коммит.

Вывод и действия

Если вы случайно удалили файлы после revert — сначала найдите коммит через git log или git reflog. Если цель — просто вернуть файлы, примените revert к коммиту-реверту или восстановите файл из нужного коммита с помощью git checkout/git restore. Если вы ещё не пушили и хотите убрать коммит без следа — используйте git reset –hard, но делайте это осторожно.

Важно: перед выполнением destructive-операций сделайте резервную копию рабочей директории (tar/zip) или создайте временную ветку: git branch temp-save, чтобы избежать потери несохранённых данных.

Примечание: для команд, которые вы не понимаете полностью, сначала выполните git status и git log, скопируйте нужные хеши и проконсультируйтесь с коллегой.

Критерии приёмки

• Файлы восстановлены в рабочей директории.
• История репозитория отражает корректные изменения (или согласовано форс-пуш с командой).
• CI проходит и коллеги уведомлены, если история была изменена.