Хаос в Git — главная причина «мы не можем выкатить в пятницу». Простая политика веток и релизов снимает половину инцидентов ещё до деплоя.
Trunk-based vs GitFlow
Для продуктов с частыми релизами (SaaS, iGaming, маркетплейсы) обычно достаточно trunk-based: короткоживущие feature-ветки, merge в main через PR, релизный тег.
GitFlow оправдан, если у вас несколько версий on-premise с длительной поддержкой. Для облачного продукта он часто создаёт лишние merge-коммиты и задержки.
- main/master — всегда deployable
- feature/* — живёт не дольше 2–3 дней
- release/* — только фиксы перед тегом, без новых фич
- hotfix/* — от production tag, backport в main
Semver и теги
MAJOR.MINOR.PATCH: breaking / features / fixes. Теги v1.4.2 привязаны к CHANGELOG и артефактам CI.
Каждый деплой в prod должен быть воспроизводим: commit SHA + docker image digest в release notes.
Protected branches и PR
- Запрет push в main, только merge через PR
- Обязательный CI (lint, test, build)
- Минимум 1 approve, для критичных модулей — 2
- Squash или merge commit — зафиксируйте одну политику
Типичные ошибки
- Долгоживущие feature-ветки без rebase → конфликты на недели
- Hotfix только на prod, забыли в main → регресс на следующем релизе
- Нет связи тега с миграциями БД
Чеклист
- Есть documented branching policy в README
- CI блокирует merge при красных тестах
- Release checklist: миграции, feature flags, rollback plan
- Hotfix playbook на 1 страницу
Как внедрить за одну неделю
День 1–2: зафиксируйте политику в README и согласуйте с командой. День 3: включите protected branch на main, required CI и минимум один approve.
День 4–5: проведите учебный hotfix от production-тега и backport в main. На retro проверьте, что release checklist реально используется, а не лежит мёртвым PDF.
Пример release checklist
- Миграции БД применены на staging и prod
- Feature flags для рискованных фич выключены по умолчанию
- Rollback = предыдущий docker tag + откат миграции (если contract ещё не сделан)
- Smoke-тест ключевых URL после деплоя
Связь Git и CI/CD
Pipeline должен знать, какой commit ушёл в prod: tag v2.3.1 → docker image backend:2.3.1 → migrate job → smoke. Если tag ставится вручную «когда успеем», воспроизвести инцидент невозможно.
Feature flags отвязывают merge от release: код в main, но фича выключена до готовности контента и legal. Hotfix идёт от prod tag, не от случайного commit в feature-ветке.
Если релизы всё равно буксуют
- Выгрузите список открытых веток старше 3 дней — закройте или rebase
- Проверьте, что CI на main зелёный и блокирует merge
- Проведите учебный hotfix: tag → fix → backport → tag
- Зафиксируйте release checklist в README, не в переписке