Какой workflow выбрать — practical decision matrix

В прошлых трёх уроках мы изучили GitHub Flow, GitFlow, Trunk-Based. Каждый имеет свои use cases. Junior часто застревает на вопросе «какой именно мне использовать?». В этом уроке: practical decision matrix по факторам, реальные примеры из DE-команд (Airflow, dbt, Spark), и почему «hybrid» — часто optimal.

Главные факторы выбора

1. Размер команды

Больше людей -> больше merge conflicts -> нужна более disciplined workflow.

2. Deployment frequency

Чем чаще деплой -> тем проще workflow нужен.

3. Тип продукта

4. CI/CD зрелость

Workflow не спасёт от отсутствия CI/CD. Чем проще workflow при отсутствии automation — тем лучше.

5. Junior ratio

Junior нужна простота. TBD с дисциплиной flag management — рискованно для junior team.

Decision tree

Что юзают реальные DE команды

Airflow community (Apache Airflow source repo)

Workflow: GitHub Flow с release branches.

• main для активной разработки (Airflow 3.x).
• v2-10-stable, v2-9-stable — release branches для патчей.
• Hotfix на release branch + cherry-pick на main (или manual port).

Это hybrid: основной flow GitHub Flow, но с поддержкой нескольких versions через release branches. Не чистый GitFlow (нет develop), не чистый GitHub Flow (есть release branches).

dbt community (dbt-core source repo)

Workflow: GitHub Flow с tagged releases.

• main continuous.
• Tags v1.7.0, v1.7.1 для releases.
• Hotfix -> patch release.
• Иногда release/v1.7 branch для backports.

Большинство внутренних dbt репо в компаниях (analytical models) — pure GitHub Flow без release branches.

Apache Spark

Workflow: GitFlow-like.

• master (main) для активной разработки.
• branch-3.5, branch-3.4 для releases.
• Strict release process с release planning.

Apache projects часто GitFlow-style — community-driven, multiple supported versions, versioned releases.

Netflix data team (internal)

Workflow: Trunk-Based.

• Все коммитят в main.
• Feature flags через internal service.
• Continuous deployment.
• Тысячи commits/day.

Internal data platform в medium company

Workflow: GitHub Flow.

• 10 DE.
• Один main.
• Feature branches 1-3 дня.
• CI на BigQuery (dbt test, dbt run на staging).
• Auto-deploy on merge.

Это типичный DE setup в 2026.

Junior pet project / freelancer

Workflow: Direct push to main.

• Solo dev, нет review.
• Маленькие commits, descriptive messages.
• GitHub Pages / Vercel auto-deploy.
• Никаких branches кроме экспериментов.

OK для solo, но сразу как только присоединится второй человек -> переход на GitHub Flow.

Hybrid workflows — нормально

В реальности команды редко используют чистый GitHub Flow или чистый GitFlow. Гибриды:

GitHub Flow + release branches

main (continuous)
├── feature/* (короткие, merge в main)
├── release/v1.x (long-lived, для патчей legacy)
└── release/v2.x (long-lived)

Когда нужно поддерживать несколько versions, но основной workflow continuous deployment.

GitHub Flow + tagged releases

main (continuous)
├── feature/* (короткие)
└── tags v1.0.0, v1.1.0, v1.1.1 (точки в истории main для deploy)

Каждый tag — release. Можно rollback через redeploy старого тега. Без release branches, просто markers в main.

TBD + emergency branches

main (commits continuously)
└── hotfix/* (only when urgent prod issues, обычно нет)

В нормальной ситуации всё в main с flags. Hotfix branch — для emergency когда flag-disable не работает (например, security issue в main вне flag).

Как принять решение в новой команде

Если ты junior и присоединился к команде:

1. Спроси «какой у нас workflow?». Tech lead должен ответить.

2. Читай CONTRIBUTING.md или docs в репо. Многие команды документируют процесс.

3. Смотри git log --graph --oneline -50. История покажет паттерн (merge commits vs squash vs linear).

4. Открой 5-10 recent merged PRs. Смотри:

   • Из какой ветки в какую (feature -> main? или -> develop?).
   • Какой merge type (squash vs merge commit).
   • Длительность open period.

5. Спроси у peer. «Я открыл первый PR — посмотри, делаю правильно?»

Не предполагай — узнавай.

Анти-pattern: cargo cult GitFlow

Junior читает Driessen 2010, копирует в DE-репо: создаёт develop branch, release branches. Команда не понимает зачем, но «junior сказал так делать». Через 3 месяца:

• Merge feature -> develop -> main двойные (forgotten merges).
• Release branches которые никто не использует, dead.
• Hotfix flow для regular bugs — overhead.
• Скорость упала 3x.

Fix: спроси «зачем». Если нет конкретной причины (versioned releases, multiple supported versions, regulatory audit) — не используй GitFlow.

Анти-pattern: cargo cult TBD без infra

Junior читает про Google TBD, копирует: все коммитят в main, нет feature flags, тесты неполные. Через 2 недели:

• Main сломан 3 раза в день.
• Все коммиты ревертятся, дев в стрессе.
• Deployment лагает в production.

Fix: TBD требует infra. Без comprehensive tests и feature flags TBD не работает. Сначала инвестируй в CI/CD, потом мигрируй.

Killer matrix для DE команды

Большинство junior DE (90%+) попадут в GitHub Flow setup. Это твоя primary знание.

Killer takeaway

Decision factors: размер команды, deploy frequency, тип продукта, CI/CD зрелость, junior ratio. DE в продуктовой компании = почти всегда GitHub Flow (90% случаев). GitFlow — для versioned products (mobile, library, SDK). Trunk-Based — для mature high-velocity (FAANG-level). Hybrids нормально — pure workflows редко match real world. Junior должен спросить tech lead и изучить commit history, не предполагать. Cargo cult любого workflow (особенно GitFlow) — anti-pattern: используй то что match-ит конкретные team needs.