Git, коммиты и пул-реквесты

Claude Code понимает git так, как не понимают большинство IDE-плагинов: он не просто вызывает git commit, а выстраивает осмысленный рабочий процесс — выбирает, что стейджить, формулирует сообщения по контексту изменений, создаёт ветки и PR в нужные моменты. Но это работает только если вы встраиваете git в процесс явно, а не оставляете «на потом».

Предыдущая статья про Best practices и паттерны организации кода зафиксировала принцип: «коммит перед каждым большим шагом». Здесь — как именно это делать на практике и что ещё умеет Claude Code в git-контексте.

Коммиты: не вы пишете сообщение, а агент

Самое очевидное применение — поручить Claude Code не только написать код, но и сразу закоммитить его с внятным сообщением. Разница с «просто git commit -m "fix"» огромная.

Дайте агенту такую задачу:

Реализуй парсинг CSV-файла в src/parsers/csv.ts.
После реализации и зелёных тестов (`npm test -- csv`) —
закоммить изменения с осмысленным сообщением по conventional commits.

Claude Code изучит diff, поймёт суть изменений и напишет что-то вроде:

feat(parsers): add CSV parser with delimiter auto-detection

- Supports comma, semicolon, and tab delimiters
- Handles quoted fields with embedded newlines
- Returns typed rows via generic parameter

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

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

Стейджинг: агент выбирает, что включать

Claude Code умеет делать git add точечно. Если в рабочей директории есть несколько изменённых файлов, но коммит нужен только по одной задаче, уточните:

Закоммить только изменения, связанные с auth-модулем.
Файлы в src/utils/ пока не трогать — там незаконченная работа.

Агент проверит git status, выберет нужные файлы и сделает git add точечно. Если он видит в diff лишнее — спросит, добавлять ли.

Полезный паттерн: перед началом большой задачи попросить агента проверить, нет ли незакоммиченных изменений, и если есть — либо закоммитить, либо stash:

Проверь git status. Если есть незакоммиченные изменения — спроси,
что с ними делать, прежде чем приступать к задаче.

Так вы избегаете ситуации, когда агент смешивает два разных набора изменений в один коммит.

Ветки: изоляция на уровне git

Для любой задачи дольше 15 минут или затрагивающей больше 2–3 файлов — заводите ветку. Это не бюрократия, это страховка: вы можете сравнить с main, откатиться, или отдать на ревью без риска сломать основную ветку.

Создай ветку feature/export-csv от main,
реализуй экспорт в CSV (задача в CLAUDE.md под тегом #export),
закоммить по шагам.

Claude Code выполнит git checkout -b feature/export-csv main и будет работать в изоляции. Если что-то пойдёт не так — git checkout main вернёт вас в исходное состояние мгновенно.

flowchart TD
    A[Новая задача] --> B[git checkout -b feature/имя]
    B --> C[Claude Code: исследование]
    C --> D[Claude Code: реализация шага]
    D --> E{Тесты зелёные?}
    E -->|Нет| D
    E -->|Да| F[git commit с осмысленным сообщением]
    F --> G{Задача завершена?}
    G -->|Нет — следующий шаг| D
    G -->|Да| H[git diff main...HEAD --stat]
    H --> I[gh pr create]
    I --> J[Ревью / @claude в PR]
    J --> K[Merge в main]

Worktrees: несколько задач параллельно

Git worktrees — одна из самых недооценённых возможностей в контексте Claude Code. Worktree — это отдельная рабочая директория, привязанная к той же git-репозитории, с собственной веткой. Несколько worktrees могут существовать одновременно.

Практическое применение: вы ведёте две задачи параллельно в разных окнах терминала, каждая — в своём worktree и своём Claude Code-сеансе.

# Создать worktree для второй задачи
git worktree add ../myproject-auth feature/oauth-integration

# В первом окне — работаете в основной директории
cd ~/myproject
claude

# Во втором — в worktree
cd ~/myproject-auth
claude

Оба агента работают независимо, не конфликтуют по файлам (у каждого своя рабочая директория), но делятся историей git. Когда задача готова — git worktree remove ../myproject-auth убирает директорию, ветка остаётся.

Это особенно ценно когда одна задача ждёт ревью, а вы не хотите терять время. Вместо git stash с его потенциальными конфликтами — чистая изоляция через worktree.

Пул-реквесты: от коммита до PR

Claude Code может создавать PR через gh CLI (GitHub CLI) или через встроенную GitHub-интеграцию. Для CLI-подхода достаточно:

Задача выполнена, тесты зелёные. Создай PR в main с описанием
изменений: что сделано, почему именно так, на что обратить внимание
при ревью. Используй gh pr create.

Агент сформирует описание PR на основе коммитов и diff — не шаблонное, а по содержимому изменений. Выглядит примерно так:

::widget{id="rc-3"}


::widget{id="rc-2"}


::widget{id="rc-1"}

## What
Adds CSV export for the Users table via `/api/export/users.csv`.

## Why
Product requested bulk data export for enterprise customers (#234).
Chose CSV over XLSX: no external dependencies, smaller output.

## Notes for reviewer
- `src/export/csv.ts` handles streaming for large datasets (>10k rows)
- Rate-limited to 1 request/minute per user to prevent DB overload
- Migration not needed — uses existing User model

Если в репозитории подключена GitHub-интеграция через @claude (устанавливается командой /install-github-app), можно идти дальше: упомянуть @claude в комментарии к PR — и агент запустится в облаке, проверит код, оставит замечания. Это уже уровень GitHub Actions и автоматический code review.

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

Конфликты при merge или rebase — задача, с которой Claude Code справляется лучше, чем кажется. Агент может читать маркеры конфликтов (<<<<<<<, =======, >>>>>>>) и понимать, какое из изменений логически правильное.

Рабочий подход:

При выполнении git merge появились конфликты в src/auth/session.ts
и src/api/routes.ts. Разбери конфликты: в auth/session.ts приоритет
за изменениями из feature-ветки, в routes.ts — нужно объединить оба.
После разрешения — запусти npm test и закоммить.

Bez context — агент рискует угадать неправильно. С контекстом о том, что важнее — справляется точно. Главное: не давайте агенту разрешать конфликты «как лучше» без указания приоритетов. У него нет бизнес-контекста, только код.

Для сложных конфликтов полезен паттерн из Субагенты и контекстная изоляция: один субагент изучает feature-ветку, второй — main, третий принимает решение с обоими резюме в контексте.

Встраивание в командный процесс

Несколько практических правил, которые помогают не создавать трений с командой.

Называйте ветки осмысленно с первого промпта. Агент использует имя ветки в сообщениях коммитов и PR. feature/csv-export-users лучше, чем feature/task-42.

Один PR — одна задача. Если агент в процессе работы нашёл баг и хочет его заодно исправить — попросите создать отдельную ветку и отдельный PR. Это стандартная практика ревью, и агент её понимает.

Задавайте --base явно. При создании PR через gh pr create уточните целевую ветку:

Создай PR в ветку develop (не main) через gh pr create --base develop.

Проверяйте diff перед PR. Попросите агента показать git diff main...HEAD --stat перед созданием PR — так вы видите объём изменений и можете поймать случайно включённые файлы.

# Агент выполнит что-то вроде:
git diff main...HEAD --stat

# Типичный вывод:
src/parsers/csv.ts           | 87 ++++++++++++++++
src/parsers/csv.test.ts      | 43 ++++++++
src/parsers/index.ts         |  3 +
3 files changed, 133 insertions(+)

Если в diff попал node_modules или .env — лучше поймать это здесь, а не после пуша.

See also

• Best practices и паттерны организации кода — принципы дисциплины контекста и декомпозиции задач, на которых строится git-процесс
• Субагенты и контекстная изоляция — паттерн Writer/Reviewer и параллельная обработка через субагентов
• Headless-режим и скриптинг через CLI — автоматизация git-операций в CI/CD через claude -p
• GitHub Actions и автоматический code review — интеграция @claude в PR-ревью через GitHub Actions
• Облачные агенты: web, routines и фоновые задачи — запуск агентов по git-событиям в облаке
• Типовые рабочие процессы: исследование, план, реализация — полный цикл от задачи до коммита