← Back to glossary

Git Workflows Compared

Q: What is a common misconception about Git Workflows Compared?

Gitflow is the industry standard — trunk-based development is standard in high-performing teams per DORA research; Gitflow's long-lived branches conflict with continuous integration principles.

Q: Why does Git Workflows Compared matter?

Gitflow with 2-week feature branches produces massive merge conflicts and integration bugs at the end of each sprint — trunk-based development with daily merges catches integration issues immediately.

Q: How do I fix Git Workflows Compared?

Use trunk-based development with short-lived feature branches (

Git 1.5 Intermediate

debt(d7/e7/b7/t7)

d7 Detectability Operational debt — how invisible misuse is to your safety net

Closest to 'only careful code review or runtime testing' (d7). Detection hints explicitly state 'automated: no' and rely on observable symptoms (feature branches open >1 week, complex merge conflicts, diverging release branches). No automated tool flags the wrong workflow choice — it takes a retrospective or code review to surface the mismatch.

e7 Effort Remediation debt — work required to fix once spotted

Closest to 'cross-cutting refactor across the codebase' (e7). The quick_fix involves switching from Gitflow to trunk-based development with feature flags, which requires changing branching conventions, CI/CD pipelines, branch protection rules, and developer habits across the entire team and codebase — not a single-file or single-component fix.

b7 Burden Structural debt — long-term weight of choosing wrong

Closest to 'strong gravitational pull' (b7). The branching strategy applies to 'any' context and is tagged as devops/ci-cd/workflow, making it a foundational choice that shapes every PR, release, and deployment decision. Long-lived Gitflow branches impose ongoing integration pain on all development streams and can persist for months or years.

t7 Trap Cognitive debt — how counter-intuitive correct behaviour is

Closest to 'serious trap' (t7). The misconception field explicitly states 'Gitflow is the industry standard' — a belief that directly contradicts DORA research showing trunk-based development outperforms it. This is a documented, well-known gotcha that misleads even experienced developers because Gitflow's name recognition gives false authority.

About DEBT scoring → scored by claude-sonnet-4-6 · 2026-05-08 · reviewed by human

Also Known As

Gitflow trunk-based development GitHub flow branching strategy

TL;DR

Gitflow (feature/develop/release/main branches) vs Trunk-Based Development (short-lived branches merged to main daily) — TBD is preferred for CI/CD, Gitflow for release-based software.

Explanation

Gitflow: dedicated branches for features, develop, release, and hotfix. Good for: release-scheduled software with parallel version support, non-continuous deployment. Drawbacks: complex, large long-lived branches, merge hell. Trunk-Based Development: developers push to main (or merge short-lived feature branches < 24 hours). Feature flags hide incomplete work. Good for: SaaS with continuous deployment, microservices. Drawbacks: requires feature flags, CI must be fast and reliable. GitHub Flow is a simplified middle ground — feature branches merged via PR to main.

Diagram

flowchart TD
    subgraph Gitflow
        GF_MAIN[main] --- GF_DEV[develop]
        GF_DEV --- GF_FEAT[feature/x<br/>lives for weeks]
        GF_DEV --- GF_REL[release/1.0]
        GF_REL -->|merge| GF_MAIN
    end
    subgraph Trunk-Based
        TB_MAIN[main - trunk]
        TB_SHORT1[branch - 1 day max]
        TB_SHORT2[branch - 1 day max]
        TB_SHORT1 -->|merge fast| TB_MAIN
        TB_SHORT2 -->|merge fast| TB_MAIN
        FF[Feature flags<br/>hide incomplete work] -.-> TB_MAIN
    end
    style TB_MAIN fill:#238636,color:#fff
    style GF_FEAT fill:#d29922,color:#fff

Common Misconception

✗ Gitflow is the industry standard — trunk-based development is standard in high-performing teams per DORA research; Gitflow's long-lived branches conflict with continuous integration principles.

Why It Matters

Gitflow with 2-week feature branches produces massive merge conflicts and integration bugs at the end of each sprint — trunk-based development with daily merges catches integration issues immediately.

Common Mistakes

Trunk-based development without feature flags — incomplete features visible to users.
Gitflow with weekly releases treated as daily deployments — mismatch causes confusion.
Long-lived feature branches regardless of workflow — the longer a branch lives, the worse the merge.
No branch protection rules — direct pushes to main/develop bypass code review.

Code Examples

✗ Vulnerable

# Gitflow anti-pattern — 3-week feature branch:
git checkout -b feature/payment-redesign
# 3 weeks of work in isolation
# Meanwhile: main has 47 commits
# Merge attempt: 150 conflicts
# Integration testing: finds 12 bugs
# Total time: 3 weeks feature + 1 week merge = 4 weeks

✓ Fixed

# Trunk-based: feature flags + daily merges:
git checkout -b feature/payment-ui  # Short-lived
# Day 1: implement basic structure, hide behind flag
git push && git merge main  # Merge daily — 0-3 conflicts
# Day 2: add core logic, still behind flag
git merge main
# Day 3: complete, enable flag for beta users
git merge main && delete branch
# Total: 3 days, continuous integration

References

https://trunkbaseddevelopment.com/