Git reflog: как найти потерянный коммит и сохранить его в новой ветке

Если после переключения веток, rebase или reset нужный коммит исчез из обычного git log, сначала посмотрите git reflog. Этот локальный журнал показывает изменения ссылок. Найденный коммит безопаснее сначала закрепить новой веткой, чем сразу передвигать текущую ветку через reset.

В инструкции Mentoring.digital начинаем с чтения состояния. Не выполняйте очистку репозитория, expire или gc ради восстановления: такие действия могут уменьшить возможность найти нужные объекты.

Сохраните текущее состояние и изучите журнал

git status --short
git reflog show HEAD --date=iso
git reflog show --all --date=iso

Первая команда показывает незакоммиченные изменения. Не отбрасывайте их и не переключайте рабочее дерево, пока не решили, как их сохранить. При важном инциденте полезна копия всего каталога репозитория вместе с .git, сделанная до дальнейших изменений.

В reflog ищите действие перед моментом потери: переключение, reset, rebase или commit. Дата и сообщение помогают сузить поиск, но не доказывают, что найден именно нужный вариант. Журнал HEAD и журналы веток могут содержать разные полезные записи.

Проверьте содержимое кандидата

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

git show --stat COMMIT_HASH
git show COMMIT_HASH --
git log --oneline -5 COMMIT_HASH

Проверьте автора, сообщение, изменённые файлы и сами изменения. Если нужно посмотреть конкретный файл в этом коммите, используйте git show COMMIT_HASH:path/to/file с настоящим путём. Это чтение объекта, а не замена файла в рабочем каталоге.

Обозначения вроде HEAD@{1} зависят от текущего состояния журнала и меняются после новых действий. Для фиксации найденного результата удобнее записать полный хеш. В PowerShell выражения с фигурными скобками также стоит передавать в кавычках.

Закрепите коммит отдельной веткой

git branch rescue/recovered-work COMMIT_HASH
git log -1 --oneline rescue/recovered-work

Создание ветки оставляет текущую ветку и рабочие файлы на месте. Если имя уже занято, выберите новое. Не добавляйте принудительное перезаписывание, пока не проверите существующую ветку.

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

Когда reflog не поможет

Reflog относится к локальному репозиторию и не переносится обычным clone или push как общая история команды. В новом клоне может не быть записи, которая существует на прежнем компьютере. Журнал не является архивом всех правок файлов и не обещает восстановление данных, которые никогда не попали в объекты Git.

Записи и недостижимые объекты могут очищаться. В стандартных настройках документация Git указывает 90 дней для обычного истечения записей и 30 дней для недостижимых, но конфигурация и выполненные команды способны изменить эти сроки. Это не гарантия хранения потерянного коммита в течение указанного периода.

Если кандидата нет, проверьте другие локальные клоны и согласованные резервные копии. Не выдавайте отсутствие в одном reflog за доказательство окончательной потери. И наоборот, найденная строка журнала ещё не гарантирует, что сам объект сохранился.

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