Reset vs revert

git reset переписывает историю ветки: двигает HEAD к более раннему коммиту и может менять индекс и рабочие файлы, фактически убирая коммиты из истории. git revert не трогает существующую историю, а создаёт новый коммит с обратным патчем к выбранному коммиту. В общих ветках обычно используют git revert, а git reset — в локальных ветках до публикации.

Ключевое различие в том, что git reset изменяет уже существующую историю ветки, а git revert добавляет поверх неё новый коммит, который логично «откатывает» нежелательные изменения.

git reset работает с указателем HEAD и состоянием файлов:

• Перемещает HEAD (и указатель ветки) к другому коммиту, обычно к одному или нескольким коммитам назад.
• В режимах --soft, --mixed и --hard по-разному влияет на индекс и рабочую директорию: от простого смещения указателя до полного отката файлов к состоянию выбранного коммита.
• После reset «лишние» коммиты как будто исчезают из истории ветки; формально их ещё можно найти через reflog, но для остальных они пропадают.
• Опасно делать git reset для уже отправленных в общий репозиторий коммитов, потому что придётся использовать git push --force и ломать историю другим разработчикам.

git revert решает другую задачу: он не двигает HEAD назад и не стирает историю, а создаёт новый коммит, который вносит изменения, обратные выбранному коммиту. В итоге в истории видно и исходный «плохой» коммит, и отдельный коммит, который его отменяет. Такой подход безопасен для общих веток, потому что не требует переписывать уже опубликованную историю.

Практически: используйте git reset как «редактор истории» в личной ветке до публикации, когда нужно подчистить или объединить коммиты. В уже расшаренных ветках лучше применять git revert, чтобы откатить изменения, не ломая историю для других участников команды.