Стартовий ритуал і 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-статус
# На гілці main
# немає що комітити, робоче дерево чисте

git switch -c fix/refund-inbox-order # переключаємося на нову git-гілку
# Перемкнено на нову гілку '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
# На гілці main
# Зміни не додано до коміту:
#   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 варто вважати спільними для всієї команди.