git reset --keep и --merge: в чём разница

Как Git решает, можно ли продолжить

`--keep` обновляет index и те рабочие файлы, которые различаются между target и HEAD, но прерывается, если такой файл одновременно имеет локальные изменения. Это защищает рабочую правку от перезаписи. `--merge` ориентируется на различия target↔index и index↔working tree: если файл должен измениться для reset, но содержит незастейдженную правку относительно index, операция abort. Документация отдельно говорит, что `--merge` переносит unmerged index entries и задуман для состояния после конфликтного merge.

Совет: Перед reset создайте временную ветку — это почти ничего не стоит и сильно снижает риск.

Как выбрать режим перед reset

1. Сначала выполните `git status` и сохраните важные изменения отдельным commit, stash или backup-веткой.
2. Если цель — убрать последние commits, сохранив рабочие изменения, рассмотрите `git reset --keep <target>`.
3. Если вы выходите из конфликтного merge и хотите сохранить безопасные незастейдженные изменения, изучите `--merge`.
4. Не подменяйте анализ `--hard`: этот режим может удалить tracked changes и решает другую задачу.
5. После reset сразу сравните `git status` и `git diff`, чтобы убедиться, что ожидаемые локальные правки остались.

Почему `--merge` не является «более мягким --keep»

Режимы смотрят на разные отношения между target, HEAD, index и working tree. В некоторых состояниях один разрешён, а другой должен отказать. Особенно заметно это при unmerged entries: `--merge` способен переносить конфликтные записи, тогда как `--keep` в таких состояниях запрещён. Поэтому советы «всегда используй keep» или «merge всегда безопаснее» неверны без конкретного состояния репозитория.

Предупреждение: Не используйте `--hard` как замену режимам только потому, что они abort: отказ означает риск перезаписи.

Перед любым reset

• сделать backup-ветку для важных commits;
• проверить staged и unstaged изменения;
• зафиксировать текущий HEAD через `git rev-parse HEAD`;
• после операции проверить diff, а не только сообщение команды.

Ключевое различие режимов

• --keep. убрать commits, сохранить рабочие правки. abort при локальном изменении файла, который меняется target↔HEAD
• --merge. восстановление после конфликтного merge. сохраняет безопасные working changes и переносит unmerged entries

Практическое правило выбора режима

`--merge` обычно выбирают, когда нужно откатить состояние после merge и сохранить локальные изменения, которые не мешают восстановлению. `--keep` строже: он сохраняет рабочие изменения, но прекращает операцию, если сброс затронет изменённые локально файлы. Перед обоими вариантами полезно сохранить список изменённых файлов через `git status`, потому что reset меняет index и историю текущей ветки.

Практический выбор по цели

Если вы сделали два локальных commit, затем начали ещё одну незастейдженную правку и хотите убрать последние commits, не теряя эту правку, `--keep` соответствует описанному назначению — при отсутствии конфликта с target. Если же вы находитесь в состоянии неудачного merge с unmerged entries, документация прямо связывает восстановительный сценарий с `--merge`.

Важно: При unmerged entries отдельно изучите состояние index; `--keep` может быть запрещён.

Что учитывать

Режимы смотрят на разные отношения между target, HEAD, index и working tree. В некоторых состояниях один разрешён, а другой должен отказать. Особенно заметно это при unmerged entries: `--merge` способен переносить конфликтные записи, тогда как `--keep` в таких состояниях запрещён. Поэтому советы «всегда используй keep» или «merge всегда безопаснее» неверны без конкретного состояния репозитория.

Источники и проверка

Инструкция составлена редакцией N1RO на 2026-09-23. Перед действием сверьте актуальные условия на официальном сайте сервиса или производителя.

• git-reset Documentation