Branching strategies for data teams: GitFlow vs trunk-based
João Barros
23 de January de 2026
1 min read
The branching strategy defines how changes flow from development to production. For data teams, the choice between GitFlow and trunk-based development has direct implications on deploy frequency and merge complexity.
GitFlow — structure and flow
Permanent branches:
main → production code (protected, merge via PR)
develop → integration of in-progress features
Temporary branches:
feature/ingest-customers-v2 → new functionality
hotfix/fix-watermark → urgent prod fix
release/2024-Q2 → release preparation
Flow:
feature/* → develop → (tests) → release/* → main
hotfix/* → main + develop
Trunk-Based Development
A single main branch: main
Very short feature branches (< 2 days)
Automatic deploy after a merged PR
Flow:
main ← feature/fix (PR with 1-2 commits, short-lived)
Each merge → automatic CI/CD → deploy to staging → (approval) → prod
For large features: feature flags
if FEATURE_FLAG_NEW_INGESTION:
run_new_pipeline()
else:
run_legacy_pipeline()
Comparison for data teams
GitFlow — better when:
✓ Scheduled releases (monthly, quarterly)
✓ Multiple analysts working in parallel
✓ Power BI reports with a long validation cycle
✓ Team less experienced with git
Trunk-based — better when:
✓ Continuous deploy of data pipelines
✓ Notebooks testable automatically
✓ Team experienced with CI/CD
✓ Feature flags for gradual rollout
Practical recommendation for data
For most data teams:
- Simplified GitFlow: main + develop + feature/*
- PR mandatory for develop and main
- CI pipeline on every PR (lint + tests)
- Automatic deploy to dev/test, manual approval for prod
- Protect main and develop: require 1 reviewer + green CI
Conclusion
Simplified GitFlow (without separate release/* branches) is the right balance for most data teams. It provides enough structure to coordinate multiple contributors without the overhead of pure trunk-based, which requires feature flags and very mature deploy pipelines.