Claude Code и Git: безопасный workflow с diff, тестами и ревью

Q: Как проверить только изменения Claude Code?

Используйте git diff, git diff --stat и git diff --check, затем сравните список файлов с планом. Если в рабочем дереве были старые изменения, отделите их до ревью.

Пошаговый Git-workflow для Claude Code: ветка, исследование задачи, план, diff, тесты, ревью и безопасное завершение без слепого принятия изменений.

Claude Code полезнее всего в связке с Git, когда агент ускоряет исследование и подготовку изменений, а разработчик сохраняет контроль над веткой, diff и тестами. Без такого процесса даже хороший ответ может привести к лишним файлам, нарушенной совместимости или незамеченной ошибке.

Официальная документация Claude Code описывает работу в терминале, команды CLI и режимы разрешений. В документации quickstart отдельный шаг посвящён Git, а страница безопасности рекомендует просматривать предлагаемые действия и не предоставлять лишний доступ (Quickstart, Security).

Эта статья — практический workflow: от чистой рабочей ветки до решения о коммите. Она дополняет обзор Claude AI, первый запуск Claude Code и настройку CLAUDE.md и permissions.

Короткий ответ

Обратите внимание:

Key Takeaways

Обратите внимание:

- Начинайте с отдельной ветки и зафиксированного состояния репозитория.

Обратите внимание:

- Сначала попросите Claude Code исследовать проект и предложить план, затем разрешайте запись.

Обратите внимание:

- Проверяйте diff после каждого смыслового блока, а не только в конце.

Обратите внимание:

- Тесты показывают, что известные сценарии работают; они не доказывают отсутствие всех рисков.

Обратите внимание:

- Коммит и отправка изменений — отдельные решения после человеческого ревью.

Почему Git нужен рядом с Claude Code

Claude Code может читать файлы, предлагать правки и запускать команды в вашем окружении. Git даёт независимый слой контроля:

показывает, какие файлы изменились;

позволяет сравнить текущее состояние с базовой веткой;

помогает отделить задачу от случайных локальных изменений;

сохраняет историю принятых решений;

упрощает возврат к рабочему состоянию.

Не путайте Git с автоматическим страхованием. Незакоммиченные изменения уже могут быть важны, а команда удаления или публикации может иметь внешние последствия. Перед стартом сохраните рабочие изменения понятным способом и не давайте Claude Code задачу в каталоге, границы которого вы не понимаете.

Шаг 1. Зафиксируйте исходное состояние

Откройте проект и выполните безопасную диагностику:

bash

git status --short
git branch --show-current
git log -1 --oneline

Передайте Claude Code задачу только на чтение:

Обратите внимание:

Изучи текущий Git-статус и структуру проекта. Не меняй файлы. Назови незакоммиченные изменения, точку входа для этой задачи и команды проверки.

Если рабочее дерево уже изменено, не просите инструмент «почистить всё». Сначала отделите собственные изменения от текущей задачи. Не используйте разрушительные команды, если не проверили их цель и восстановление.

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

Шаг 2. Составьте план до редактирования

Хороший запрос задаёт границы:

Обратите внимание:

Найди код, который отвечает за [поведение]. Опиши текущий путь данных, предложи минимальный план изменения, перечисли файлы и тесты. Не редактируй файлы.

Попросите Claude Code отдельно указать:

какие предположения он сделал;

какие части задачи неясны;

что он не будет трогать;

где нужен ручной просмотр;

какие ошибки могут проявиться после изменения.

Сравните план с требованиями проекта и CLAUDE.md. Если план неожиданно затрагивает платежи, авторизацию, миграции или публичный API, остановитесь и пересмотрите область.

Шаг 3. Вносите небольшие изменения

После подтверждения плана разрешайте один смысловой блок за раз. Например:

добавить функцию;

добавить тест;

обновить вызывающий код;

обновить документацию.

После каждого блока просите кратко сообщить:

что изменилось;

почему;

какие файлы затронуты;

какая проверка следующая.

Так проще найти источник ошибки и не потерять связь между запросом и diff. В настройке Claude Code описано, как закрепить такую последовательность в проектных правилах.

Шаг 4. Проверяйте diff, а не только итоговый текст

Используйте команды, которые показывают масштаб и содержимое изменений:

bash

git diff --stat
git diff --check
git diff

Проверяйте:

не появились ли лишние файлы;

не изменились ли строки за пределами задачи;

не попали ли секреты и персональные данные;

корректны ли импорты и обработка ошибок;

соответствует ли изменение требованиям и стилю проекта;

не добавлены ли сетевые или деструктивные команды без необходимости.

Если diff слишком большой, попросите Claude Code разделить изменение или объяснить каждый блок. Не принимайте результат по одному сообщению «готово».

Шаг 5. Запустите тесты и диагностику

После просмотра diff запустите проверки проекта:

bash

npm test
npm run lint
npm run build

Команды замените на реальные из README, package.json или CLAUDE.md. Если есть отдельный typecheck, миграции, визуальные тесты или smoke-проверки, включите их в список.

При ошибке попросите Claude Code:

Обратите внимание:

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

После исправления повторите тест, затем снова просмотрите diff. Зеленая сборка не подтверждает корректность требований, UX или безопасности, поэтому ручное ревью остаётся обязательным.

Шаг 6. Проведите code review

Перед коммитом полезен отдельный проход с другой формулировкой:

Обратите внимание:

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

Официальная документация Claude Code Code Review описывает отдельный сценарий анализа pull request и проверку кандидатов на проблемы (Code Review). Даже если используется локальное ревью, критерии стоит сохранить:

сначала корректность и риск для production;

затем обработка ошибок и границ;

затем тестируемость и читаемость;

в конце — косметические улучшения.

Не принимайте автоматически все замечания ревью. Проверьте их по коду и требованиям, а спорные пункты пометьте как требующие решения.

Шаг 7. Решите, что делать с результатом

После ревью возможны три исхода:

Состояние	Действие
Задача закрыта, тесты прошли	Подготовить коммит по правилам команды
Есть замечания	Исправить, снова проверить diff и тесты
Требования неясны или риск высок	Остановить работу и запросить решение

Коммит — не обязательная часть каждой сессии. Если проект использует ручное принятие изменений, оставьте понятный diff для владельца. Операции push, merge, публикации и деплоя должны выполняться только в согласованном процессе.

Что делать с конфликтом изменений

Если Claude Code обнаружил незнакомые незакоммиченные изменения:

не удаляйте их;

зафиксируйте список файлов;

определите владельца изменений;

ограничьте свою задачу;

при необходимости создайте отдельную ветку или копию;

после завершения покажите только собственный diff.

Правило «сделай чисто» не означает «удали всё лишнее». В рабочем репозитории чужие изменения могут быть незавершённой, но важной задачей.

Типичные ошибки

Запускать агента прямо в основной ветке. Ошибку сложнее отделить от стабильной версии. Используйте отдельную ветку или другой безопасный контур.

Давать запрос без границ. Формулировка «почини всё» порождает большой diff. Назовите поведение, файлы и критерий готовности.

Смотреть только на зелёный build. Сборка не проверяет все требования, регрессии и безопасность. Нужны diff, тесты и ручное ревью.

Позволять изменениям накапливаться. Большой итоговый diff трудно проверить. Разделяйте работу на небольшие блоки.

Автоматически отправлять результат в удалённый репозиторий. Push меняет внешнее состояние и может запустить CI или деплой. Решение должно быть явным.

Чек-лист перед коммитом

Перед тем как зафиксировать изменения, ответьте на вопросы:

задача описана в сообщении коммита и соответствует плану;

в diff нет случайных файлов и секретов;

обработаны ошибки и пустые значения;

тесты покрывают новый или изменённый путь;

публичные тексты, API и миграции совместимы с требованиями;

README или CLAUDE.md обновлены, если изменился workflow;

результат проверен не только Claude Code, но и человеком.

Если хотя бы один пункт неизвестен, оставьте изменения в рабочей ветке и сформулируйте открытый вопрос. Это лучше, чем маскировать неопределённость коммитом с общим названием.

Для задач с внешними эффектами добавьте отдельный финальный барьер: кто разрешает push, merge, публикацию или деплой. Техническая возможность выполнить команду не является разрешением на изменение внешней системы.

Частые вопросы

Может ли Claude Code сам сделать коммит?

Техническая возможность и правила конкретного проекта могут отличаться. Коммит стоит делать только после просмотра diff, прохождения проверок и решения владельца ветки.

Нужно ли каждый раз запускать полный build?

Определите набор проверок по риску изменения. Для конфигурации и публичного API полный build важен, для изолированного текста может быть достаточно линтера. Команды проекта имеют приоритет.

Как проверить только изменения Claude Code?

Используйте git diff, git diff --stat и git diff --check, затем сравните список файлов с планом. Если в рабочем дереве были старые изменения, отделите их до ревью.

Что делать при неудачном тесте?

Сохраните вывод, попросите объяснить причину, внесите минимальный фикс и повторите тест. Не маскируйте ошибку удалением проверки.

Как связать Git-workflow с правилами проекта?

Опишите порядок explore → plan → edit → diff → test → review в CLAUDE.md и правилах проекта.

Заключение

Безопасный workflow Claude Code строится вокруг Git, а не вместо Git. Отдельная ветка, план до записи, маленькие изменения, diff, тесты и code review превращают агента из непрозрачного генератора правок в управляемый инструмент.

Начните с первого запуска Claude Code, добавьте проектные правила в CLAUDE.md, а затем применяйте этот цикл к каждой задаче. Если нужен только анализ без доступа к репозиторию, используйте обычный Claude-чат.