Проверка контрольных точек Gemini CLI: Верификация восстановления файла

Итог

Практикуйтесь в восстановлении на одном одноразовом файле и сравните его байты, прежде чем полагаться на контрольные точки в рабочем репозитории.

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

Источники проверены 27 октября 2026 г. Это упражнение, подтвержденное документацией. Мы тестировали локальный фикстур и команды сравнения, включая намеренно измененный файл, который не проходит сравнение. Gemini CLI не установлен в этой среде создания, поэтому мы не выполняли аутентифицированное редактирование или /restore. Шаги агента ниже являются критериями приемки, а не сообщаемыми результатами успеха.

Вам нужен Bash на Linux или macOS, Git с рабочей локальной идентификацией коммита и установленный, аутентифицированный Gemini CLI. Используйте синтетические данные. Упражнение делает локальный коммит Git, но удаленный репозиторий не требуется.

Выберите операцию восстановления

Официальный руководство по контрольным точкам описывает снимки, созданные до использования одобренных инструментов редактирования файлов, таких как replace и write_file. Контрольная точка содержит состояние проекта, историю разговоров и ожидающий вызов инструмента. Снимок Git хранится в отдельном локальном теневом репозитории, а не в истории коммитов вашего проекта.

С справочник команд перечисляет три связанные операции:

Операция	Предназначение в этом упражнении
`/restore`	Перечислить контрольные точки файлов, затем восстановить ту, что предшествовала редактированию.
`/resume`	Найти и продолжить сохранённый разговор. Продолжение в одиночку не является проверкой восстановления файла.
`/rewind`	Выбрать более раннее взаимодействие и выбрать, какое состояние вернуть.

Отдельное руководство по перемотке назад говорит, что откат файлов охватывает инструменты редактирования на основе ИИ, исключая ручные правки и изменения, вызванные через оболочку. Сохраняйте это первое упражнение для встроенного редактирования файла. Не используйте команду оболочки для внесения изменений агентом и не рассматривайте эти элементы управления как общую кнопку отмены для внешних сервисов.

Создайте проект с независимым оригиналом

Запустите это в терминале, вне ваших рабочих репозиториев. Эти две соседние папки отделяют проект от доказательств, которые вы будете использовать для его проверки.

lab_root=$(mktemp -d /tmp/gemini-restore-lab.XXXXXX)
mkdir "$lab_root/project "$lab_root/evidence
cd "$lab_root/project
printf 'Корень лаборатории: %s\n' "$lab_root"
git init -q
mkdir .gemini
кот > .gemini/settings.json <<'JSON'
{
  "general": {
    "checkpointing": { "enabled": true },
    "defaultApprovalMode": "default"}
  }
}
JSON
printf 'Проект: Фонарь
День обзора: пятница
' > review.txt
cp review.txt "$lab_root/evidence/review.original.txt
git добавить review.txt .gemini/settings.json
git коммит -m "Записать одноразовое восстановление исходного уровня лаборатории"
git rev-parse HEAD > "$lab_root/evidence/baseline-commit.txt
git статус --коротко

Итоговый статус должен быть пустым. Если коммит не удается, решите проблему с локальной идентификацией Git, прежде чем продолжить; не путайте незафиксированную папку с записанным исходным уровнем. Сохраняйте распечатанный путь к корню лаборатории, чтобы второе окно терминала могло его найти.

Согласно ссылка на конфигурацию, .gemini/settings.json это место расположения настроек проекта, контрольные точки по умолчанию отключены, и для их изменения требуется перезапуск. Этот фрагмент создает новый файл в пустой лаборатории; при адаптации к существующему проекту тщательно объединяйте соответствующие ключи. Системные переопределения могут иметь приоритет над настройками проекта.

Начните новую CLI-сессию из папки проекта:

gemini --version > "$lab_root/evidence/cli-version.txt
gemini

Если будет запрошено подтверждение доверия к папке, проверьте точный путь scratch-проекта перед тем, как доверять ему. Сохраняйте обычные подтверждения. В /settings, убедитесь, что контрольные точки включены; если нет, исправьте эффективные настройки и перезапустите перед запросом редактирования. Не используйте устаревший --checkpointing флаг: руководство по контрольным точкам говорит, что он был удалён в версии 0.11.0.

Запросите ровно одно редактирование

Отправьте этот запрос внутри Gemini CLI:

Это одноразовое упражнение по восстановлению. Прочтите review.txt и используйте встроенный
инструмент редактирования файлов, чтобы изменить только «Review day: Friday» на «Review day: Monday».
Сохраните строку проекта и конечный перевод строки. Не выполняйте команды оболочки.
создавайте другие файлы, изменяйте настройки или выполняйте коммиты в Git. Остановитесь после редактирования.

Проверьте предложенный инструмент и дифф. Одобряйте только редактирование предназначенного файла. Если агент предлагает команду shell или более широкое изменение, откажитесь от этого и повторно укажите рамки задачи. Подсказка — это граница задачи, а не механизм контроля доступа.

Пока CLI остаётся открытым, используйте второй терминал. Замените путь ниже на путь к корневой папке лаборатории, напечатанный ранее:

lab_root=/tmp/gemini-restore-lab.REPLACE_ME
cd "$lab_root/project
кот review.txt
git различие -- review.txt
git статус --коротко

Требуется Project: Lantern и Review day: Monday, при этом только review.txt изменено. Сохраните фактический дифф вне проекта:

git различие -- review.txt > "$lab_root/evidence/edited.diff

Если результат отличается, остановитесь и зафиксируйте, что произошло. Упражнение по восстановлению легче всего интерпретировать, когда исходное и изменённое состояния отделяет ровно одно редактирование инструмента.

Восстановите указанный контрольный пункт после этого

Вернитесь к открытому интерфейсу CLI Gemini и введите:

/restore

Выберите контрольную точку, связанную с review.txt редактированием, используя её фактический идентификатор из списка. Руководство по контрольным точкам называет этот аргумент именем файла контрольной точки; справочник команд называет его ID вызова инструмента. Используйте то, что указано в вашей установленной версии, и проверьте /help отличается ли принятый синтаксис.

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

/restore <идентификатор-из-вашего-списка>

С руководство по контрольным точкам описывает восстановление файлов проекта и состояния переписки, после чего снова появляется первоначальное предложение инструмента. Отклоните или отмените это повторно предложенное изменение, чтобы оно немедленно не поменяло пятницу обратно на понедельник. Избегайте любых несвязанных правок во время упражнения: зафиксированная область восстановления — это снимок проекта, а не только файл, указанный в контрольной точке.

Проверьте байты и состояние репозитория

Во втором терминале выполните эти проверки из каталога проекта:

если cmp -с "$lab_root/evidence/review.original.txt review.txt; тогда
  printf 'PASS: восстановленный файл соответствует оригинальным байтам\n'
иначе
  printf 'FAIL: восстановленный файл отличается от оригинального\n'
fi
git различие --exit-code HEAD -- review.txt .gemini/settings.json
git статус --коротко
git rev-parse HEAD > "$lab_root/evidence/after-commit.txt
если cmp -с "$lab_root/evidence/baseline-commit.txt \
          "$lab_root/evidence/after-commit.txt; тогда
  printf 'PASS: коммит проекта не изменился\n'
иначе
  printf 'FAIL: коммит проекта изменился\n'
fi

Принимайте выполнение только в том случае, если оба сравнения пройдены, команда diff завершилась с нулевым кодом выхода, и статус пуст. Проверьте все три: совпадение review.txt не доказывает отсутствие лишних файлов, а один лишь чистый статус не доказывает, что агент не изменил коммит.

Запишите версию CLI, идентификатор контрольной точки, используемый инструмент и наблюдаемые проверки в папку внешних доказательств. Восстановленное сообщение чата или заверение агента, что он отменил редактирование, не является достаточным доказательством восстановления файла.

Когда проверка восстановления неудачна

Наблюдение	Следующее действие
`/restore` недоступна	Проверьте действительные настройки контрольной точки, перезапустите и обратитесь к установленной справке.
Список не содержит совпадающих контрольных точек	Подтвердите, что настройка была активна до редактирования, и проверьте, какой инструмент это сделал. Не придумывайте идентификатор.
Понедельник возвращается после восстановления	Проверьте, было ли повторно одобрено исходное редактирование при повторном предложении.
Сравнение байтов не удалось	Сохраните разницу и зафиксируйте неудачное восстановление; осмотрите файл перед следующей попыткой.
Статус показывает другие изменения	Проверьте каждый измененный путь. Не используйте широкий сброс, чтобы привести доказательства в чистый вид.

Если вам нужен оригинальный лабораторный файл после неудачной попытки, выйдите из Gemini CLI и скопируйте внешний оригинал в review.txt себя. Пометьте это как ручное восстановление, никогда как успешное восстановление контрольной точки.

Сохраняйте папку с доказательствами до тех пор, пока не просмотрите запуск. Повторите это небольшое упражнение после обновления CLI, прежде чем применять тот же рабочий процесс для важной работы. Для более крупной задачи по кодированию используйте урок на определение конкретных критериев принятия чтобы решить, какое поведение необходимо тестировать помимо восстановления.

Официальные заметки источника

Все проверено 27 октября 2026:

Контрольные точки Gemini CLI: содержимое снимков, включение, удалённый флаг и поведение восстановления.
Справка по конфигурации: настройки проекта, приоритет, значение по умолчанию для контрольных точек и требование перезапуска.
Команды CLI: /restore, /resume, /settings и синтаксис команд.
Перемотка назад: выбор взаимодействий и ограничения на то, какие изменения файлов можно отменить.

Запустите это в работу

Различайте контрольную точку файла от сохранённого разговора и перемотки взаимодействия.

Попробовать

Попросите Gemini CLI изменить один синтетический день обзора в одноразовом Git-проекте.

Докажите, что это сработало

Сравните восстановленный файл с его внешним оригиналом и подтвердите, что коммит проекта остался неизменным.

Держите в поле зрения

Включите создание контрольной точки перед редактированием и перезапустите CLI после изменения настройки.
Сохраняйте оригинальный файл и заметки обзора вне восстанавливаемого проекта.
Для успешного восстановления необходимы побайтовое сравнение и проверка изменённого файла.

Изучите рабочий процесс: Определите конкретные проверки для задачи кодирования ИИ