раздел 09 · подстраница 3

Несколько чатов одновременно

Запустить два-три Claude в разных терминалах - простой способ распараллелить работу без всяких субагентов. Но если делать без правил, они быстро наступят друг другу на пятки: общие файлы, общий dev-сервер, общая БД. Вот правила, которые проверены практикой.

Правила

1. Каждому чату - своя ветка

Никогда не работайте двумя Claude в одной ветке. Один закоммитит, второй сделает rebase, третий получит conflict - и пол-дня уйдёт на починку git.

Перед стартом каждого чата:

git worktree add ../app-feat-x feat-x
cd ../app-feat-x
claude

См. главу про worktrees.

2. Общие файлы - только по одному за раз

Если оба чата правят package.json, tsconfig.json или конфиг хоть какой - заранее договоритесь, кто его трогает первым. Второй ждёт мержа первого и подтягивает изменения через rebase.

Список типовых общих файлов:

  • package.json, pnpm-lock.yaml
  • tsconfig.json, next.config.ts
  • docker-compose.yml
  • .env.example, CLAUDE.md

Если оба правят независимые файлы - конфликтов нет, спокойно работайте параллельно.

3. Dev-сервер и БД - только в одном чате

npm run dev слушает порт. Запустите его в двух worktree - второй упадёт с EADDRINUSE. Локальный Postgres - тоже один на всех.

Договоритесь: dev-сервер крутится в чате №1. Чат №2 либо подключается к тому же серверу (если фронт-only), либо работает без него (если backend-only и тестит через unit-тесты).

# Чат 1: фронт + dev-сервер
cd ../app-feat-ui
npm run dev    # порт 3000

# Чат 2: бэкенд, без сервера, только тесты
cd ../app-feat-api
pytest

4. Деплой - только из main после мержа обоих

Никогда не деплойте из ветки одного чата, пока второй ещё не замержен. Иначе на проде окажется только половина фичи.

Workflow:

1. Чат 1 закончил → PR → review → merge в main
2. Чат 2 закончил → rebase на свежий main → PR → review → merge
3. Deploy from main

Реальный кейс из практики

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

  • Чат 1 - feature ветка, dev-сервер, фронт-разработка
  • Чат 2 - test ветка, отдельный worktree, только тесты + unit-запуски
  • Общий .env через симлинк на воркспейсный
  • Каждые час-два - чат 2 делает rebase на свежий feature-ветку, чтобы тесты не отставали от кода

Минусы тоже есть: если в чате 1 поменялись типы, чат 2 узнаёт об этом только после rebase. Не делайте чаты слишком автономными от друг друга.

Как держать состояние в голове

Когда чатов больше двух - я теряюсь, кто что делает. Помогает:

  • Именовать терминальные вкладки: app · feat-auth, app · tests
  • Цвет промпта в каждой ветке (через oh-my-zsh git plugin)
  • Короткие заметки в NOTES.md после каждого чата - что сделано, что осталось

Антипаттерны

  • Открыть два Claude в одной папке "на скорую руку". Гарантированный конфликт через 5 минут.
  • Игнорировать сообщения от другого чата ("он сам разберётся"). Не разберётся. Координация - на вас.
  • Запускать тесты, которые пишут в общую БД, из двух чатов. Тесты будут падать рандомно.
  • Деплоить из feature-ветки одного чата, пока другой не замержен. Сломаете прод.

Полезные ссылки