Какую стратегию ветвления (Branching Strategy) ты используешь?

В проектах на Node.js мы обычно адаптируем стратегию под размер команды и цикл релизов.

Для средних/крупных проектов с регулярными релизами мы используем модифицированный GitFlow:

• main (master) — всегда отражает состояние production.
• develop — основная ветка для интеграции новой функциональности.
• feature/* — создаются от develop для разработки новой фичи. Например, feature/user-auth.
• release/* — ветка для финального тестирования и подготовки к релизу, создается от develop. Сюда вносятся только исправления багов.
• hotfix/* — создаются от main для срочных исправлений в production, затем мерджатся и в main, и в develop.

Процесс для новой фичи:

# Создаем ветку от актуальной develop
$ git checkout -b feature/add-payment-webhook develop

# Весь код пишется, коммитится и пушится в эту ветку
# После код-ревью и успешных проверок CI...
$ git checkout develop
$ git merge --no-ff feature/add-payment-webhook
$ git branch -d feature/add-payment-webhook

Для небольших сервисов или команд часто переходим на более простой GitHub Flow / Trunk-Based Development:

• Есть одна долгоживущая ветка main.
• Вся разработка ведется в короткоживущих feature-ветках, которые через Pull Request мерджатся в main.
• Каждый мердж в main автоматически деплоится в staging-окружение. Это отлично сочетается с CI/CD пайплайнами в GitHub Actions.

Ключевое правило: Ветка main всегда должна быть в деплоябельном состоянии.