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

Откат в Git зависит от того, где находится ошибка: в незакоммиченных файлах, локальном коммите или уже опубликованной истории. За 10–15 минут вы разберётесь, когда использовать restore, reset и revert, а перед опасной операцией создадите резервную ссылку на текущее состояние.

Что подготовить перед откатом

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

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

git status
git branch --show-current
git log --oneline -n 5

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

Шаг 1. Отмените незакоммиченные изменения

Это самый частый случай: вы изменили файл, но ещё не создали коммит. Команда git restore возвращает содержимое из последнего коммита и удаляет локальные правки в выбранном файле.

git restore -- путь/к/файлу

Замените путь на реальный, например git restore -- src/config.js. Проверка: выполните git status. Если файл был изменён только локально, он исчезнет из списка изменений.

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

git diff --name-only
git restore -- .

Проверка: git status не показывает отменённые файлы, а git diff не выводит их различия. Незакоммиченные неотслеживаемые файлы эта команда не удаляет.

Шаг 2. Уберите файл из staging, но сохраните правки

Если вы случайно выполнили git add, это ещё не повод откатывать файл. Снимите его с подготовки к коммиту:

git restore --staged -- путь/к/файлу

Проверка: git status показывает файл в разделе изменений, которые не подготовлены к коммиту, а его содержимое остаётся на месте. Это безопасный вариант, когда нужно исправить состав будущего коммита.

Шаг 3. Отмените последний локальный коммит

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

git branch backup-before-rollback

Проверка: команда git branch показывает новую ветку backup-before-rollback. Теперь выберите режим отката.

• Оставить изменения подготовленными: git reset --soft HEAD^. Коммит исчезнет из текущей ветки, а его изменения останутся в staging.
• Оставить изменения в файлах, но убрать из staging: git reset HEAD^. Это режим по умолчанию для смешанного сброса.
• Удалить коммит и его изменения: git reset --hard HEAD^. Команда уничтожает незасохранённые изменения в рабочем дереве.

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

Если коммит уже попал в общую ветку, откатывайте не историю, а эффект коммита. Так вы не переписываете чужую работу.

Шаг 4. Безопасно отмените опубликованный коммит

Для коммита, который уже отправлен через git push, обычно нужен git revert. Git создаст новый коммит с обратными изменениями, поэтому существующая история останется на месте.

git log --oneline -n 5
git revert <commit-hash>
git push

Вместо <commit-hash> подставьте идентификатор нужного коммита, например первые 7–10 символов из вывода git log. Проверка: в истории появляется новый коммит с сообщением об отмене, а удалённые изменения исчезают из рабочей версии после отправки.

Если при отмене возник конфликт, Git остановит операцию. Исправьте конфликтующие файлы, затем выполните:

git add -- путь/к/исправленному-файлу
git revert --continue

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

Шаг 5. Вернитесь после ошибочного сброса

Git некоторое время хранит прежние положения указателя HEAD в журнале ссылок. Это не гарантия на неограниченный срок, поэтому действуйте сразу и не запускайте очистку репозитория.

git reflog

git branch recovery-before-restore HEAD@{1}

Найдите в выводе строку с состоянием до ошибочного сброса. Создайте от неё отдельную ветку, подставив нужную позицию вместо HEAD@{1}. Проверка: git log --oneline recovery-before-restore показывает потерянный коммит.

После проверки можно вернуть текущую ветку на найденную позицию:

git reset --hard recovery-before-restore

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

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

Если не получилось

«pathspec did not match any file(s) known to git»

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

«Your local changes to the following files would be overwritten»

Команда пытается получить изменения, которые затрут ваши локальные правки. Сначала сохраните их отдельным коммитом или временно уберите через stash, а затем повторите операцию. Не добавляйте --hard, если эти изменения ещё могут понадобиться.

«error: commit ... is a merge»

Вы пытаетесь отменить merge-коммит, но Git не знает, какую родительскую линию считать основной. Такой откат требует явного выбора родителя и проверки результата на тестовой ветке; не подставляйте параметр наугад.

«CONFLICT» во время revert

Изменения из отменяемого коммита пересекаются с более поздними правками. Разберите конфликт, выполните git add для исправленных файлов и продолжите через git revert --continue. Если передумали, используйте git revert --abort, чтобы вернуть состояние до начала операции.

Что делать дальше

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