Стартовый ритуал и Git baseline

1. Безопасный старт важнее быстрого старта

Самая частая ошибка — «сейчас открою проект и сразу попрошу Claude всё сделать». Claude работает не с вашей идеей, а с реальными файлами, реальной историей Git и реальным состоянием папки. Скорость без порядка не ускоряет работу — она удлиняет будущую уборку.

Запомните главную мысль лекции: Git — это не финальная церемония перед PR. Это первая страховка перед AI-изменениями.

Сначала проверяете директорию, потом состояние Git, заводите отдельную ветку — и только потом зовёте Claude. Это не тормоз. Это дешёвый способ откатиться, если что-то пойдёт не туда. Выгоднее, чем потом разбирать десять изменённых файлов и вспоминать, какие правил ты, какие — Claude, а какие задело случайно.

2. Git baseline на практике

Git baseline — это понятное и безопасное стартовое состояние проекта перед сессией с Claude. Вы знаете, в каком репозитории находитесь, видите локальные изменения, работаете в отдельной ветке, не тащите в репозиторий секреты и заранее очертили границы задачи.

Это не один пункт, а короткий стартовый ритуал:

git status

.gitignore

Эту же мысль можно увидеть как простую схему:

flowchart TD
    A[Нужная папка] --> B[git status]
    B --> C[Понятное состояние]
    C --> D[Отдельная ветка]
    D --> E[.gitignore и secrets]
    E --> F[Project trust]
    F --> G[Короткий scope]
    G --> H[Старт Claude]

Здесь особенно важно слово «понятное». Проект не обязан быть абсолютно стерильным в философском смысле. Но он обязан быть понятным вам. Если в рабочем дереве уже есть изменения и вы не можете за тридцать секунд объяснить, что это за правки и зачем они нужны, baseline ещё не готов.

3. Стартовый ритуал на Commerce OS

Чтобы всё это не осталось теорией из серии «в вакууме всё работает», давайте пройдём стартовый ритуал на репозитории Commerce OS. Представим, что вы собираетесь заняться маленькой задачей в зоне refund-логики, но саму задачу пока не делаете. Сегодня нас интересует именно безопасный вход в проект, а не реализация изменения.

Начинается всё с очень простых команд:

pwd 				# получаем текущую диркторию
# /Users/anna/projects/commerce-os

git status	# проверяем git-статус
# On branch main
# nothing to commit, working tree clean

git switch -c fix/refund-inbox-order # переключаемся на новую git-ветку
# Switched to a new branch 'fix/refund-inbox-order'

Первая команда кажется почти смешной по своей простоте, но именно pwd часто спасает от глупой ошибки «ой, я был не в том проекте». Если у вас рядом лежат commerce-os, commerce-os-old, commerce-os-playground и ещё один репозиторий «точно последний финальный 2», то проверить путь — это не паранойя, а взрослая привычка.

Команда git status — это первый медицинский осмотр проекта. Если Git отвечает working tree clean, это хороший знак: вы стартуете с ровной поверхности. Если вместо этого вы видите modified, deleted, untracked, не делайте вид, что «потом разберусь». Git тут не душнит. Git предупреждает.

После этого создаётся отдельная ветка. Почему не работать прямо в main? Потому что отдельная ветка — это дешёвая изоляция. Даже если Claude предложит неудачную серию изменений, у вас останется понятный контейнер для эксперимента. Можно выйти из него, вернуться позже, сравнить, откатить или вообще оставить как неудачную попытку. Работа в main лишает вас этой дешёвой безопасности и делает любую ошибку дороже, чем она должна быть.

Здесь полезно запомнить ещё одну формулу: Сначала понятное состояние проекта, потом AI-помощь. Не наоборот.

Именно поэтому baseline делают до первой просьбы «Claude, посмотри задачу».

4. Clean working tree и отдельная ветка

На словах «чистое рабочее дерево» звучит как что-то из области садоводства, но смысл здесь очень практический. Clean working tree означает, что Git не видит неожиданных локальных изменений относительно последнего коммита в текущей ветке. И это состояние особенно важно перед сессией с Claude, потому что тогда любой новый diff читается легко: всё, что появилось после старта, действительно относится к текущей задаче.

А теперь неприятный, но жизненный сценарий. Вы открываете репозиторий и видите вот такое:

git status
# On branch main
# Changes not staged for commit:
#   modified: src/support/refund/RefundInboxService.java
#   modified: src/orders/OrderSummary.java

git diff src/support/refund/RefundInboxService.java
# Git покажет построчно, что именно уже изменено

В этот момент худшее решение — сказать себе: «Ладно, Claude разберётся». Нет, не разберётся. Точнее, он может попытаться, но тогда новая итерация с Claude смешается с уже существующими локальными правками, и через двадцать минут вы будете читать один общий diff как археолог, который раскопал три эпохи сразу.

Если рабочее дерево грязное, нужно сначала понять, что это за изменения. Если это ваша незавершённая предыдущая работа, её стоит либо довести до понятной точки, либо временно убрать с дороги. Если это случайный мусор, который уже не нужен, его нужно осознанно выбросить. Только после этого baseline снова становится безопасным.

Отдельная ветка в этой истории — вторая страховка. Она полезна не только для будущего PR, но и для психологического спокойствия. Ветка говорит вам: «даже если сейчас эксперимент окажется неудачным, вы не развалите рабочее состояние проекта целиком». В разработке с AI это особенно ценно, потому что неудачная попытка часто выглядит не как один плохой файл, а как серия правок сразу в нескольких местах.

5. Scope до запуска Claude

На этом этапе легко подумать: «Раз мы ещё не формулируем задачу подробно, значит, и scope сейчас не нужен». На самом деле нужен — просто в очень лёгкой форме. Здесь scope — это не большой инженерный документ, а короткая рамка: что мы готовы менять в этой сессии, а что трогать не собираемся. Эта рамка резко снижает шанс получить «полезный, но лишний» diff.

Для нашего примера с Commerce OS черновик scope может выглядеть так:

# Черновик scope

Задача: проверить и поправить порядок refund-запросов в inbox.
Можно менять: `src/support/refund/**`, связанные тесты.
Нельзя менять: API-контракты, миграции БД, `.env*`, настройки окружения.

Такой фрагмент хорош тем, что он короткий, понятный и сразу уменьшает радиус случайных изменений. Claude Code вообще-то любит помогать. Иногда даже слишком любит. Если вы не обозначили границы, он вполне может заодно предложить переименовать соседние классы, «чуть улучшить» общую структуру модуля или подтянуть что-то в конфигурации. Формально это может выглядеть разумно. На практике же это превращает маленькую задачу в широкий diff, который потом долго и скучно ревьюить.

Здесь важно не путать scope с полной инженерной спецификацией. Сегодня нам достаточно короткой рамки. Полноценная постановка задачи — отдельная большая тема курса. Но привычка обозначать границы до старта нужна уже сейчас. Даже одна фраза «трогаем только refund-модуль и его тесты» работает на удивление хорошо. И для вас, и для Claude.

6. .gitignore, secrets и project trust

Есть два тихих риска, которые новички обычно замечают слишком поздно. Первый — забытый .gitignore. Второй — слишком автоматическое нажатие на подтверждение project trust. Оба кажутся мелочами, пока не выясняется, что в рабочей папке лежал .env, локальный дамп, временный файл с ключом или что вы вообще доверили Claude не тот проект.

Проверка .gitignore может быть очень короткой:

git check-ignore -v .env
# .gitignore:12:.env    .env

Если Git показывает, что .env игнорируется нужным правилом, это хороший знак. Если не показывает ничего, надо остановиться и проверить .gitignore до старта работы. Причина простая: Claude может прочитать файл, о существовании которого вы уже забыли, а потом невольно опереться на его содержимое в диалоге, сводке или изменениях. Это не «злая воля AI», а обычная цена неаккуратной рабочей папки.

Нормальный фрагмент .gitignore в таком проекте может выглядеть так:

.env
.env.*
!.env.example
.claude/CLAUDE.local.md

Отдельно стоит сказать про project trust. Точный текст окна и название кнопок могут отличаться в разных версиях и разных поверхностях, но суть не меняется: вы подтверждаете, что этому проекту можно доверять в контексте запуска Claude Code. И здесь полезно не нажимать «да-да, быстрее пропусти», а на секунду задать себе три простых вопроса. Это точно тот репозиторий? Я понимаю, что в этой папке могут запускаться команды и читаться файлы? Нет ли здесь лишних чувствительных данных, которые вообще не должны участвовать в сессии с AI?

Project trust — это не назойливое модальное окно. Это точка осознанного решения: «я действительно разрешаю работать именно с этим проектом». И когда вы воспринимаете его так, он начинает помогать, а не раздражать.

7. Выход из неудачной AI-итерации

Очень полезно ещё до старта работы понимать, как вы будете выбираться из неудачной итерации. Не после. До. Это снимает лишнее напряжение и делает Claude не страшным существом с доступом к файлам, а быстрым помощником, чьи действия можно проверить и при необходимости откатить. И главным инструментом выхода здесь остаётся не новый prompt «почини всё», а старый добрый Git.

Минимальный набор выглядит так:

git diff
# показывает, что именно изменилось построчно

git restore src/support/refund/RefundInboxService.java
git status
# working tree clean

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

Если вся попытка оказалась неудачной и вы хотите просто выйти из неё, помогает и ветка, которую мы создали в начале. Например, можно вернуться в main, а экспериментальную ветку оставить на потом для разбора или удалить позже, когда решение уже принято. Смысл не в том, чтобы никогда не ошибаться. Смысл в том, чтобы ошибка оставалась дешёвой.

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

1

Задача

Claude code, 2 уровень, 0 лекция

Недоступна

Стартовый ритуал перед первой AI-сессией

Стартовый ритуал перед первой AI-сессией

Открыть