Что делает git revert
Что проверяют
Понимаете ли вы, чем отмена изменений отличается от переписывания истории и почему на общей ветке это принципиально. Следом почти всегда спрашивают про разницу с git reset и про то, как откатить merge-коммит.
Как отвечать
git revert <hash> не удаляет коммит, а создаёт новый, в котором применён обратный патч. История остаётся честной: видно, что изменение было и что его отменили. Поэтому revert безопасен для main и любой ветки, которую уже забрали коллеги, а git reset с последующим push --force сломает им локальные копии.
Что стоит назвать:
git revert HEAD: отменить последний коммит;--no-commit(-n): изменения попадают в индекс без коммита, так удобно откатить несколько коммитов одним;- диапазон
A..B: откатывает коммиты послеAдоBвключительно, начиная с самого нового; -m 1: обязателен для merge-коммита, указывает, какого родителя считать основной линией;- конфликты: решаются как при merge, дальше
git revert --continueили--abort.
В IntelliJ IDEA это пункт Revert Commit в логе Git, под капотом та же команда.
Для Java-проекта добавьте важную оговорку: revert откатывает только файлы. Если коммит содержал миграцию Flyway или Liquibase, которая уже прошла на базе, схема останется изменённой. Правильный путь это новая миграция, которая возвращает схему, а не удаление старой.
Где спотыкаются
Говорят, что revert «удаляет коммит», или путают его с git reset и git restore. Отдельная ловушка у тех, кто пришёл из SVN: там svn revert выбрасывает локальные незакоммиченные правки, то есть делает совсем другое.
Откатывают merge-коммит, а потом снова вливают ту же ветку и удивляются, что изменения не вернулись. Git считает их уже слитыми, поэтому сначала нужно сделать revert самого revert-коммита.
Откатывают коммит с уже применённой миграцией вместе с её файлом. Flyway на следующем старте упадёт на валидации: в flyway_schema_history есть версия, которой больше нет в коде.