Чтобы убрать подготовленные изменения файла из следующего коммита и оставить их на диске, в репозитории с существующим коммитом используйте git restore --staged -- path/to/file. На Mentoring.digital разберём отличие этой операции от удаления правок и покажем, как проверить результат.
Три состояния, которые нельзя смешивать
Рабочая копия содержит файлы, с которыми вы работаете. Индекс хранит подготовленный снимок для следующего коммита. HEAD указывает на текущий коммит. После git add файл на диске и его подготовленная версия могут совпадать, но последующее редактирование снова сделает их разными.
С флагом --staged команда restore по умолчанию берёт содержимое из HEAD и меняет индекс. Рабочую копию эта форма не восстанавливает. Обычный git restore -- file.txt имеет другой адрес назначения и может уничтожить незакоммиченные изменения файла. Не убирайте --staged по привычке.
Проверьте состояние до команды
git status --short
git diff --cached -- path/to/file
git diff -- path/to/file
git restore --staged -- path/to/file
git status --short
git diff --cached -- path/to/file
git diff -- path/to/fileЗамените path/to/file настоящим путём нужного файла. Разделитель -- отделяет параметры от пути. Проверяйте один файл, если не собирались менять подготовку всего репозитория.
После операции diff --cached для этого пути должен показывать отсутствие изменений относительно HEAD, а обычный diff позволит увидеть сохранившиеся правки отслеживаемого файла. Для нового файла, которого нет в HEAD, результатом отмены индексации будет неотслеживаемый файл. Его наличие проверяйте через status и файловую систему: обычный diff не показывает содержимое неотслеживаемых файлов.
Если файл уже редактировали после git add
Отмена индексации не разделяет автоматически ранние и поздние правки. Она убирает подготовленную версию выбранного пути из следующего коммита, сохраняя текущее содержимое на диске. Если нужно подготовить только часть изменений, сначала прочитайте diff, затем используйте осознанный выбор фрагментов, например git add -p.
В только что созданном репозитории без первого коммита HEAD ещё нет. Приведённый основной сценарий на такой случай не рассчитан. Не заменяйте ошибку команды случайным reset --hard или удалением файла: сначала выясните состояние репозитория.
Контроль перед коммитом
- Откройте файл и убедитесь, что нужные правки сохранились.
- Посмотрите git diff --cached без ограничения пути: туда могли попасть другие файлы.
- Если в индекс попал секрет, удаление из индекса не отменяет его прежнюю публикацию в истории.
- После повторного git add ещё раз проверьте подготовленный снимок.
Команды проверки удобно повторить в отдельном учебном репозитории. При сложном сочетании staged и unstaged изменений можно разобрать снимки с ментором по Git. Здесь цель: изменить состав следующего коммита, не переписывая историю и не удаляя рабочие правки.
