Git WindowsLinuxmacOS

Git: после rebase пропал локальный коммит

  • Обновлено
  • Чтение ≈ 4 минуты

Краткий ответ

После git rebase Git пересоздаёт коммиты поверх другой основы: хеши обычно меняются, а прежние вершины веток могут перестать отображаться в обычном git log. Это не всегда потеря: Git хранит локальный журнал перемещений ссылок (reflog) и, пока нужные объекты не удалены, коммит можно восстановить. Статья посвящена поиску исчезнувшего коммита, а не обычному завершению перебазирования.

В этой статье
  1. Что означает проблема
  2. Как отличить причины
  3. Пошаговая диагностика и решение
  4. Команды для проверки и исправления
  5. Как проверить результат и что делать, если не помогло

#Что означает проблема

После git rebase Git пересоздаёт коммиты поверх другой основы: хеши обычно меняются, а прежние вершины веток могут перестать отображаться в обычном git log. Это не всегда потеря: Git хранит локальный журнал перемещений ссылок (reflog) и, пока нужные объекты не удалены, коммит можно восстановить. Статья посвящена поиску исчезнувшего коммита, а не обычному завершению перебазирования.

#Как отличить причины

Возможная причинаКак узнатьЧто делать
Коммит пересоздан с новым SHARebase создал эквивалентный коммит с другим родителем.Новый git log содержит похожее изменение и сообщение, но другой идентификатор.Сначала проверить содержимое, возможно, восстанавливать нечего.
Коммит пропущен или оказался пустымRebase не включил прежний коммит, например из-за уже присутствующих изменений.Коммита в новой линии нет; в reflog видна прежняя вершина или исходный SHA.Проверить исходный коммит, закрепить его отдельной веткой.
Коммит остался в отброшенной локальной историиВетка теперь указывает на новую вершину, а прежняя не имеет именованной ссылки.git reflog --all находит старый SHA, git show показывает нужные файлы.Создать спасательную ссылку до новых операций очистки.

#Пошаговая диагностика и решение

  1. Остановите любые операции очистки и проверьте rebaseОткройте VS Code → «Терминал» → «Создать терминал» внутри проекта либо Git Bash в его каталоге. Введите git status -sb. Если там You are currently rebasing, сперва выясните, есть ли незаконченные конфликты: git rebase --abort отменяет текущий НЕЗАВЕРШЁННЫЙ rebase, но не отменяет давно завершённый. Не используйте команду автоматически — если изменения уже исправлялись вручную, сохраните их копию. Перед остальными командами выполните git --version: в ответ должна появиться установленная версия Git. Если терминал сообщает, что git не найден, проверьте установку Git и доступность команды в этом терминале; не продолжайте операции наугад.
  2. Проверьте, нет ли нужного изменения под новым хешемВыполните git log --all --oneline --decorate -30 и найдите сообщение исчезнувшего коммита. Откройте его через git show --stat ВАШ_SHA с настоящим идентификатором. Если файлы и поведение уже совпадают, повторное применение может создать дубль. Проверьте тесты вместо немедленного восстановления.
  3. Откройте локальный журнал перемещений ссылокВ том же терминале выполните git reflog --all --date=iso. Записи часто содержат rebase (start), rebase (pick) или rebase (finish) и исходные вершины. Из-за большого журнала можно дополнительно посмотреть git reflog show HEAD -30, но он может не показать старые записи других веток. Запишите хеш нужного коммита из вывода, а не плавающий номер HEAD@{N}.
  4. Проверьте содержимое найденного SHA, не переключаясьВыполните git show --stat ВАШ_SHA и при необходимости git show --format=fuller --no-patch ВАШ_SHA. Сверьте автора, дату, текст сообщения и список файлов. Подстановка ВАШ_SHA обязательна; не копируйте пример буквально. Если Git пишет bad object, проверьте правильность хеша и того, что это тот же локальный клон: удалённый сервер обычно не хранит ваш reflog.
  5. Закрепите найденную точку отдельной веткойКогда уверены, что SHA правильный, создайте ссылку git branch rescue-before-rebase ВАШ_SHA. Это НЕ меняет рабочие файлы и не сбрасывает текущую ветку; созданное имя защищает объект от потери из-за отсутствия ссылок. Если ветка rescue-before-rebase уже существует, выберите новое уникальное имя и не используйте -f.
  6. Сравните восстановленный коммит с текущей историейЗапустите git log --oneline --left-right --cherry-pick rescue-before-rebase...HEAD. Здесь трёхточечное выражение сравнивает две линии и с --cherry-pick помогает скрыть эквивалентные изменения. Однако сложные слияния и частично изменённые правки могут требовать ручной сверки git show. Сохраните результаты сравнения для команды до применения любых изменений.
  7. Перенесите необходимый одиночный коммит безопасноТолько если коммит действительно отсутствует в текущей ветке, нет незакоммиченных правок и вы обсудили порядок с командой, создайте отдельную ветку git switch -c restore-lost-change. Затем выполните git cherry-pick ВАШ_SHA, подставив проверенный SHA одиночного коммита. Возможны конфликты: исправьте файлы, git add и git cherry-pick --continue после тестов. При отказе от попытки выполните git cherry-pick --abort, пока операция ещё не завершена. Для merge-коммита этот пример не подходит.
  8. Проверьте результат и согласуйте публикациюУбедитесь, что git log -3 --oneline содержит нужное изменение на восстановительной ветке, тесты прошли, git status --short пуст. Отправляйте изменения через обычный запрос на включение и не выполняйте git push --force в рабочую общую ветку. Если нужного SHA нет ни в reflog, ни в копиях, специалист может изучить оставшиеся объекты, но гарантировать восстановление нельзя.

#Команды для проверки и исправления

Linux · Терминал (Bash)Команда
Все команды только читают историю локального репозитория. --all включает известные ссылки, --date=iso делает даты понятнее.
git status -sb
git log --all --oneline --decorate -30
git reflog --all --date=iso
Linux · Терминал (Bash)Команда
Замените ВАШ_SHA действительным хешем из журнала в ОБЕИХ командах. Показывает файлы, автора и дату; не изменяет данные.
git show --stat ВАШ_SHA
git show --format=fuller --no-patch ВАШ_SHA
Linux · Терминал (Bash)С осторожностью
Создаёт защитную ссылку на проверенный коммит, рабочую директорию не меняет. Если имя занято, выберите новое; подставьте свой SHA.
git branch rescue-before-rebase ВАШ_SHA

Команда может изменить состояние системы или её настройки. Проверьте параметры и последствия перед запуском.

Linux · Терминал (Bash)Команда
Сравнение по двум линиям без изменения состояния. Укажите своё название спасательной ветки, если оно другое.
git log --oneline --left-right --cherry-pick rescue-before-rebase...HEAD
Linux · Терминал (Bash)С осторожностью
Действовать строго по очереди после резервной копии и с чистой рабочей папкой. Первый шаг создаёт отдельную ветку, второй применяет изменения из проверенного одиночного коммита и может вызвать конфликт. Подставьте SHA.
git switch -c restore-lost-change
git cherry-pick ВАШ_SHA

Команда может изменить состояние системы или её настройки. Проверьте параметры и последствия перед запуском.

#Как проверить результат и что делать, если не помогло

Успех: спасательная ветка содержит исходный SHA, новая ветка содержит ровно необходимые восстановленные изменения, тесты проходят, рабочая папка чистая. Если найден только большой merge-коммит, не используйте пример cherry-pick без разбора родителей. Если журнал отсутствует, соберите резервные копии и сведения о Git для специалиста.

Источники и обновления

Последнее обновление статьи: 2 ноября 2026. Версии программ и интерфейсы меняются — если шаги не совпадают с вашей версией, сверяйтесь с документацией производителя.