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 — не шаблонное, а по содержимому изменений. Выглядит примерно так:

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](/lessons/254125da-d07f-44fd-aed7-374d07a4dd1a/26).

---

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

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

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

При выполнении git merge появились конфликты в src/auth/session.ts

и src/api/routes.ts. Разбери конфликты: в auth/session.ts приоритет

за изменениями из feature-ветки, в routes.ts — нужно объединить оба.

После разрешения — запусти npm test и закоммить.

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

Для сложных конфликтов полезен паттерн из [Субагенты и контекстная изоляция](/lessons/254125da-d07f-44fd-aed7-374d07a4dd1a/16): один субагент изучает 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-событиям в облаке
• Типовые рабочие процессы: исследование, план, реализация — полный цикл от задачи до коммита