Как организовать Gitflow, чтобы каждая фича выпускалась в релиз сразу по готовности?

Классический Gitflow предполагает накопление фич в ветке develop и периодические релизы. Для непрерывной доставки (Continuous Delivery) его нужно адаптировать. Мы использовали подход, близкий к GitHub Flow или Trunk-Based Development с короткоживущими feature-ветками.

Основной workflow:

1. main (master) — это всегда рабочая, стабильная версия, готовая к продакшену. Каждый коммит сюда автоматически деплоится.
2. Для каждой новой фичи/задачи создается короткоживущая ветка от main.

   git checkout -b feature/JIRA-123-new-payment-gateway main

3. Разработка ведется в этой ветке. Каждый пулл-реквест (PR) должен содержать исчерпывающие тесты.
4. По готовности создается PR в main. После прохождения code review и всех этапов CI/CD (сборка, unit-тесты, интеграционные тесты, сборка артефакта) PR мержится.
5. Момент мержа в main и является релизом. Автоматический пайплайн (например, в GitLab CI или GitHub Actions) сразу разворачивает этот коммит на staging, а после успешных smoke-тестов — и на продакшен (или требует ручного подтверждения).

Пример конфигурации .gitlab-ci.yml для такого подхода:

stages:
  - test
  - build
  - deploy-staging
  - deploy-prod

# Запускается для всех веток и PR
unit-test:
  stage: test
  script:
    - npm run test

build:
  stage: build
  script:
    - npm run build
  artifacts:
    paths:
      - dist/

# Делаем деплой на staging для каждой фичи, попавшей в main
deploy-to-staging:
  stage: deploy-staging
  script:
    - ./deploy.sh staging
  only:
    - main

# Деплой на prod — вручную или автоматически после тестов на staging
deploy-to-production:
  stage: deploy-prod
  script:
    - ./deploy.sh production
  only:
    - main
  when: manual # Требует ручного клика для запуска

Ключевое: Нет долгоживущих веток develop и release/*. Фича становится доступной пользователям сразу после мержа в main и прохождения пайплайна. Горячие фиксы — это такие же короткие ветки от main, которые мержатся обратно.