(+351) 21 24 10006  ·  info@bconcepts.pt
Carnaxide, Lisbon
Infraestrutura como Código & DevOps
Infraestrutura como Código & DevOps 1 min

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.

Share: