Як ми працюємо з гілками: dev — пісочниця, у release потрапляють тільки готові feature-гілки, деплой запускається тегом, а QA тестує конкретну версію. Нижче — навіщо це і як саме працює.
Раніше ланцюжок був лінійний: feature → dev → release → prod. Кожен наступний крок — мерж усієї попередньої гілки. Це означає: мержачи dev у release, ти береш не свою фічу, а весь поточний стан dev — включно з тим, що туди поклали інші й ще не доробили.
Даніш почав CEX-адаптер, але не зміг дотестувати — клієнт не видав API keys. Його незавершені зміни лишилися в dev. Сашко зробив DEX-адаптери, протестував свої зміни на кожному етапі й помержив dev → release → prod. Разом із його кодом у прод поїхав і недороблений CEX-адаптер — хоча його ніхто туди не відправляв свідомо.
У release мержиться не dev, а конкретна feature-гілка. dev існує лише щоб погратись/потестувати — з нього зазвичай нічого нікуди не їде.
Кожна фіча живе у своїй гілці від початку до самого релізу. Хочеш перевірити на дев-стенді — мержиш фічу в dev. Готовий релізитись — мержиш ту саму фічу в release. Два незалежні маршрути з одного джерела:
Нова фіча = нова гілка. Вся робота — тільки в ній.
git checkout -b feature/sasha-dex-adapters
dev — спільна пісочниця: інтеграції, ручні перевірки, експерименти. Це необов'язковий крок і він ні до чого не зобов'язує — фіча в dev ≠ фіча в релізі.
feature/sasha-dex-adapters → dev
Ключовий момент: у release їде тільки твоя feature-гілка, а не dev. Що лежить у dev — release не стосується.
feature/sasha-dex-adapters → release
Мерж у release сам по собі нічого не деплоїть. Кілька девів можуть змержити свої фічі. Коли стан стабільний — ставимо tag, і деплоїться саме цей коміт.
git tag v1.1.0-three-new-adapters
Не «поточний стан гілки», а зафіксований tag. Усі знають, що саме перевіряється, і гілка може жити далі, не ламаючи тестування.
У прод потрапляє рівно той код, який пройшов QA. Знайшли баг? Фікс у тій самій feature-гілці (або окремій fix-гілці) → знову в release → новий tag → QA тестує нову версію.
Пуш чи мерж у release не запускає деплой автоматично. Це дає свободу: кілька людей спокійно мержать свої фічі, а деплой стається один раз — коли команда свідомо фіксує стабільний стан тегом.
Версія + людська назва, щоб одразу було видно, що в релізі:
v1.1.0-whitebit-adapter v1.1.0-three-new-adapters
Код тече тільки вниз: release → dev. Після кожного релізу (або просто регулярно) мержимо release у dev — так пісочниця завжди містить актуальний продовий код, і фічі тестуються на свіжій базі, а не на застарілій.
git checkout dev && git merge release
dev — пісочниця, тому з часом у ньому накопичуються покинуті експерименти та фічі, які так і не доїхали до релізу. Це нормально. Коли сміття заважає (конфлікти при мержах, стенд поводиться не як прод) — dev просто перестворюємо з release:
git checkout release && git branch -f dev && git push --force origin dev
Перестворення dev — це force-push спільної гілки: спершу попередь команду. Нічиї напрацювання при цьому не губляться — вся робота живе у feature-гілках, і потрібні фічі просто мержаться в свіжий dev заново.
feature/* гілкаdev, щоб потестити на стендіreleasereleaserelease у фічу, вирішуємо конфліктиtag на коміті в releaserelease → devrelease (попередивши команду)release у maindev → release (головне правило; винятки — лише свідомі й рідкісні)release фічі, які не готові («ще без API keys» = не готова)release в обхід feature/fix-гілкиНеготовий код фізично не може «випадково поїхати» в прод: він живе у своїй гілці, поки автор сам не змержить його в release. Кожен реліз — це свідомий набір конкретних фіч + зафіксована тегом версія, яку перевірив QA.
| Гілка / штука | Роль | Звідки приходить код | Куди йде далі |
|---|---|---|---|
| feature/* | Вся робота над фічею, від першого коміту до фіксів після QA | відгалужується від актуального коду | → dev (тест), → release (реліз) |
| dev | Пісочниця: інтеграції, експерименти, ручні тести на стенді | будь-які feature-гілки + release (синхронізація вниз) | зазвичай нікуди — глухий кут за дизайном |
| release | Кандидат у прод: тільки свідомо вибрані готові фічі | конкретні feature/fix-гілки | → tag → QA → main |
| tag | Зафіксована версія. Створення tag = запуск деплою | ставиться на коміт у release | деплой → QA тестує цю версію |
| main / prod | Те, що реально працює в проді | release після апруву QA | — |