Claude Code в разработке: Git-воркфлоу и поиск ошибок

Коммиты: как агент понимает, что изменилось

Перед тем как оформить коммит, Claude Code параллельно опрашивает состояние репозитория тремя командами: git status — что изменено, добавлено или не отслеживается, git diff — что именно поменялось построчно (отдельно для застейдженных и незастейдженных правок), и git log — недавнюю историю коммитов, чтобы уловить стиль, в котором обычно пишут сообщения в этом проекте.

Дальше он подстраивается под этот стиль — если в истории видны Conventional Commits (feat:, fix:, refactor:), сообщение будет оформлено так же; если проект пишет коммиты обычным человеческим языком — агент последует этому. Формулировку можно доверить агенту целиком, а можно задать текст самому и попросить только оформить коммит — оба варианта работают одинаково хорошо.

Ветки и Pull Request

Создание ветки и реализацию задачи можно объединить в одном сообщении: «Создай ветку для фичи X и реализуй её» — агент сам придумает осмысленное имя ветки, переключится на неё и приступит к правкам. Когда работа готова к ревью, дальнейшие шаги идут через gh — официальный CLI GitHub:

• проверка состояния ветки и того, что она отслеживает нужный remote;
• git diff main...HEAD — весь набор изменений ветки относительно основной, а не только последнего коммита;
• просмотр списка коммитов ветки, чтобы убедиться, что в PR попадёт то, что нужно, и ничего лишнего;
• git push с публикацией ветки на remote;
• gh pr create с сформированным summary, разделом о деталях реализации и test plan — чеклистом того, что стоит проверить ревьюеру.

gh pr create --title "feat: add rate limiting to API" --body "$(cat <<'EOF'
## Summary
- Added token-bucket rate limiter middleware

## Test plan
- [ ] Unit tests for limiter pass
- [ ] Manual check: 429 returned after limit exceeded
EOF
)"

Ревью Pull Request

Проверить чужой PR можно двумя способами. Быстрый — выкачать ветку локально командой gh pr checkout <номер> и попросить агента в неинтерактивном режиме дать заключение: claude -p "Review this PR for correctness and edge cases". Более глубокий — сделать то же самое, но в обычной интерактивной сессии, где можно уточнять по ходу: «а что будет, если сюда придёт пустой массив», «покажи, где это поле используется дальше по цепочке».

Интерактивный rebase

Если в ветке накопилось несколько «грязных» коммитов — опечатка в предыдущем сообщении, промежуточный коммит вроде «wip» или «fix typo», который логически относится к предыдущему — агент умеет привести историю в порядок через интерактивный rebase: объединить (squash) несколько коммитов в один осмысленный, поправить текст сообщения задним числом. Это тот случай, где стоит явно понимать, что происходит — интерактивный rebase переписывает историю, и делать это стоит только для веток, которые ещё не расшарены с другими участниками, либо после явного согласования.

Разрешение конфликтов слияния

При конфликте агент не просто вставляет один из двух вариантов наугад — он читает оба конфликтующих блока, разбирается, что каждая сторона пыталась сделать (по коду и по смыслу окружающих изменений), и предлагает решение, которое сохраняет замысел обеих правок, а не просто «побеждает» одна из версий. Если совместить изменения технически невозможно (например, обе стороны по-разному переписали одну и ту же функцию), агент честно объясняет, в чём противоречие, и просит уточнить, какой вариант поведения нужен в итоге — вместо того чтобы гадать.

Cherry-pick и backport

Иногда нужен не весь набор изменений ветки, а один конкретный коммит — например, критичный фикс бага, который нужно перенести из ветки разработки в ветку релиза отдельно от остальных незавершённых изменений. Это и есть cherry-pick: агент находит нужный коммит по описанию задачи или хешу и переносит именно его на целевую ветку. Похожая задача — backport, перенос фикса из основной ветки в старую поддерживаемую версию продукта, когда патчить нужно сразу несколько параллельно живущих релизов.

Работа со stash

Если нужно срочно переключиться на другую задачу, не закоммитив текущие незавершённые изменения, агент умеет пользоваться полным циклом stash: убрать текущие правки во временное хранилище, переключиться на нужную ветку, при необходимости подтянуть свежие изменения (git pull), вернуться на исходную ветку и применить отложенные правки обратно. Это избавляет от соблазна коммитить «на всякий случай» незаконченный код только ради того, чтобы переключить контекст.

Правила безопасности в git

У Claude Code есть встроенные ограничения на потенциально опасные git-операции — они применяются по умолчанию, если явно не попросить иначе:

• никогда не делает force-push в main/master без явного прямого указания сделать именно это;
• предпочитает создавать новый коммит вместо --amend — это снижает риск случайно затереть чужую или уже запушенную работу;
• добавляет в коммит файлы по конкретному имени, а не через git add -A или git add . — так меньше риск случайно закоммитить секреты вроде .env или временные файлы, которые не должны попасть в историю;
• никогда не пропускает git-хуки (--no-verify) без явной просьбы — если хук упал, это чаще сигнал разобраться в причине, а не обойти проверку.

Как правильно описывать баг

Качество исправления напрямую зависит от качества описания проблемы. Сравните два запроса. Расплывчатый: «приложение не работает» — агенту приходится самому искать, что вообще сломано, в каком месте и при каких условиях, а это может занять кратно больше времени, чем сам фикс. Конкретный: «на странице оформления заказа после нажатия кнопки „Оплатить“ вместо перехода на страницу успеха вылетает ошибка 500 в консоли — воспроизводится на шаге 3, если в корзине больше одного товара».

Хорошее описание бага обычно включает:

• ожидаемое поведение — что должно было произойти;
• фактическое поведение — что произошло на самом деле (текст ошибки, код ответа, скриншот);
• шаги воспроизведения — по порядку, с конкретными данными, если это важно;
• место — конкретная страница, компонент интерфейса или API-роут, а не «где-то в личном кабинете».

Падающие тесты

Когда тест падает, агент сначала прогоняет его, чтобы увидеть точный текст ошибки и стектрейс, а не полагается на пересказ. Дальше — ключевой шаг анализа: разобраться, что именно неправильно — сам тест (устаревшие ожидания, неверные тестовые данные) или код, который он проверяет (реальная регрессия). Это разные исправления, и путать их нельзя — поправить тест под сломанное поведение — это спрятать баг, а не починить его. После исправления — обязательный повторный прогон, чтобы убедиться, что тест теперь проходит по правильной причине, а не случайно.

Поиск проблем производительности

Claude Code умеет находить в коде несколько классических паттернов производительностных проблем, даже если приложение внешне «просто работает медленно»:

• N+1 запросы — когда вместо одного запроса к базе данных за списком связанных данных код делает по отдельному запросу на каждый элемент в цикле;
• отсутствующие индексы — запросы, которые фильтруют или сортируют по столбцу без индекса, и с ростом таблицы становятся всё медленнее;
• лишние ре-рендеры во фронтенд-коде — компоненты, которые перерисовываются чаще, чем реально меняются данные, которые они показывают;
• отсутствие пагинации — эндпоинты или запросы, которые тянут сразу весь набор данных целиком там, где нужна выдача постранично.

Debug Loop: итеративный паттерн отладки

В основе того, как агент подходит к непонятным багам, лежит повторяющийся цикл, а не попытка угадать причину с первого раза:

• Симптом — что наблюдается: ошибка, неверный результат, зависание.
• Расследование — чтение кода, логов, трассировки выполнения вокруг места, где проявляется симптом.
• Гипотеза — конкретное предположение о причине, которое можно проверить, а не общее «что-то не так с базой».
• Проверка — тест, лог-принт или воспроизведение, которое подтверждает или опровергает гипотезу.
• Фидбек — результат проверки: гипотеза подтвердилась (можно чинить) или нет (возврат к расследованию с учётом того, что уже исключено).

Цикл повторяется, пока гипотеза не подтвердится. Такой подход медленнее, чем попытка сразу «исправить на глаз», зато не оставляет за собой патчей симптомов вместо настоящей причины.

Практические задания

Git-воркфлоу:

• Возьмите небольшую задачу в своём проекте и попросите агента создать под неё ветку, реализовать изменения и открыть Pull Request через gh pr create одним диалогом.
• Сделайте в ветке несколько «черновых» коммитов подряд и попросите привести историю в порядок через интерактивный rebase перед тем, как открывать PR.

Отладка:

• Найдите (или намеренно внесите) падающий тест и опишите агенту симптом двумя способами — расплывчато и конкретно, сравните скорость и точность решения.
• Попросите агента пройтись по одному из тяжёлых экранов приложения на предмет N+1 запросов или лишних ре-рендеров и объяснить, что именно он нашёл и почему это медленно.