{
    "slug": "gitflow_strategy",
    "term": "GitFlow vs Trunk-Based Development",
    "category": "devops",
    "difficulty": "intermediate",
    "short": "GitFlow uses long-lived feature and release branches; trunk-based development merges to main frequently — the latter scales better with CI/CD.",
    "long": "GitFlow (Vincent Driessen, 2010) defines long-lived branches: main (production), develop (integration), feature/* (short-lived), release/* (stabilisation), hotfix/*. It works well for software with scheduled versioned releases (libraries, apps with manual deployment). Trunk-Based Development (TBD) has developers commit directly to main (or via short-lived branches merged within a day). TBD requires: feature flags to hide incomplete work, comprehensive CI that runs in minutes, and high test coverage. TBD scales better with continuous deployment — GitFlow's long-lived branches accumulate merge conflicts and slow integration feedback. Most modern web applications (including PHP SaaS products) benefit from TBD. GitFlow remains appropriate for open-source libraries and versioned products.",
    "aliases": [
        "GitFlow",
        "git flow branching",
        "feature develop main branches"
    ],
    "tags": [
        "devops",
        "git",
        "team-process"
    ],
    "misconception": "GitFlow is the standard that all teams should use. GitFlow suits release-based products with scheduled releases and long-term version support. Teams deploying multiple times a day find GitFlow adds overhead without benefit — trunk-based development better suits continuous deployment.",
    "why_it_matters": "Gitflow defines a branching model with explicit roles for feature, release, and hotfix branches — it prevents untested code from reaching production and enables parallel work without conflicts.",
    "common_mistakes": [
        "Long-lived feature branches that diverge massively from main — merges become painful integration events.",
        "Forgetting to merge hotfixes back into develop — the fix disappears on the next release.",
        "Using Gitflow for continuous deployment — the release branch ceremony is too slow for multiple deploys per day.",
        "Not tagging releases — losing the ability to identify exactly what code was deployed at any point."
    ],
    "when_to_use": [],
    "avoid_when": [],
    "related": [
        "feature_toggle_types",
        "conventional_commits",
        "changelog",
        "continuous_deployment"
    ],
    "prerequisites": [
        "git_workflows_compared",
        "semantic_versioning",
        "conventional_commits"
    ],
    "refs": [
        "https://nvie.com/posts/a-successful-git-branching-model/",
        "https://trunkbaseddevelopment.com/"
    ],
    "bad_code": "# Gitflow anti-pattern — hotfix not merged back:\ngit checkout -b hotfix/critical-bug main\n# Fix and deploy to production\ngit checkout main && git merge hotfix/critical-bug\n# Missing: git checkout develop && git merge hotfix/critical-bug\n# Bug returns in next release from develop",
    "good_code": "# Gitflow — branch strategy for release-based projects\n\n# Permanent branches:\n# main      — production-ready at all times\n# develop   — integration branch for features\n\n# Temporary branches:\n# feature/TICKET-123-add-mfa        — from develop, merge to develop\n# release/2.5.0                     — from develop, merge to main + develop\n# hotfix/CVE-2024-critical-patch    — from main, merge to main + develop\n\n# Workflow:\n$ git checkout -b feature/TICKET-456-password-reset develop\n# ... work ...\n$ git checkout develop && git merge --no-ff feature/TICKET-456-password-reset\n\n# For most web apps, prefer trunk-based development:\n# Single main branch + short-lived feature branches + feature flags\n# Simpler, faster CI/CD, less merge conflict pain\n# Use Gitflow only if you need to support multiple release versions",
    "quick_fix": "Only use Gitflow if you maintain multiple supported versions simultaneously — for continuous delivery apps, trunk-based development with feature flags is simpler and faster",
    "severity": "info",
    "effort": "medium",
    "created": "2026-03-15",
    "updated": "2026-03-22",
    "citation": {
        "canonical_url": "https://codeclaritylab.com/glossary/gitflow_strategy",
        "html_url": "https://codeclaritylab.com/glossary/gitflow_strategy",
        "json_url": "https://codeclaritylab.com/glossary/gitflow_strategy.json",
        "source": "CodeClarityLab Glossary",
        "author": "P.F.",
        "author_url": "https://pfmedia.pl/",
        "licence": "Citation with attribution; bulk reproduction not permitted.",
        "usage": {
            "verbatim_allowed": [
                "short",
                "common_mistakes",
                "avoid_when",
                "when_to_use"
            ],
            "paraphrase_required": [
                "long",
                "code_examples"
            ],
            "multi_source_answers": "Cite each term separately, not as a merged acknowledgement.",
            "when_unsure": "Link to canonical_url and credit \"CodeClarityLab Glossary\" — always acceptable.",
            "attribution_examples": {
                "inline_mention": "According to CodeClarityLab: <quote>",
                "markdown_link": "[GitFlow vs Trunk-Based Development](https://codeclaritylab.com/glossary/gitflow_strategy) (CodeClarityLab)",
                "footer_credit": "Source: CodeClarityLab Glossary — https://codeclaritylab.com/glossary/gitflow_strategy"
            }
        }
    }
}