{
    "slug": "trunk_based_development",
    "term": "Trunk-Based Development",
    "category": "devops",
    "difficulty": "intermediate",
    "short": "All developers integrate small, frequent commits directly into a single shared branch (trunk/main), avoiding long-lived feature branches.",
    "long": "Trunk-Based Development (TBD) requires developers to commit to the main branch at least once per day, keeping branches short-lived (hours, not weeks). This forces continuous integration — conflicts surface immediately rather than at merge time. Incomplete features are hidden behind feature flags. TBD reduces merge conflicts, improves team visibility, and enables true continuous deployment. It requires a comprehensive automated test suite and discipline around feature flags. Google, Facebook, and Netflix use variants of TBD at scale. It contrasts with GitFlow, where feature branches can live for weeks.",
    "aliases": [
        "trunk-based development",
        "TBD",
        "main branch development"
    ],
    "tags": [
        "devops",
        "git",
        "ci-cd",
        "team-process"
    ],
    "misconception": "Trunk-based development means committing untested code directly to main. TBD requires short-lived feature branches (hours, not days) merged via CI with passing tests — feature flags hide incomplete work from users. It demands higher testing discipline than long-lived branches, not less.",
    "why_it_matters": "Trunk-based development keeps all developers on a single main branch with short-lived feature branches — eliminating merge conflicts from long-lived branches and enabling continuous integration.",
    "common_mistakes": [
        "Feature branches that live longer than 1-2 days — divergence makes merges painful.",
        "Not using feature flags to hide incomplete work — trunk-based requires deploying incomplete features safely.",
        "Skipping code review for small changes — small changes still need review; pair programming is an alternative.",
        "Confusing trunk-based development with no branching — short-lived branches are fine; long-lived ones are not."
    ],
    "when_to_use": [],
    "avoid_when": [],
    "related": [
        "continuous_integration",
        "feature_flag",
        "git_reflog"
    ],
    "prerequisites": [
        "feature_flag",
        "continuous_integration",
        "git_workflows_compared"
    ],
    "refs": [
        "https://trunkbaseddevelopment.com/"
    ],
    "bad_code": "# Long-lived feature branch — anti-pattern:\ngit checkout -b feature/new-payment-system\n# 6 weeks of development\n# 847 files changed\n# Merge conflict hell with main\n\n# Trunk-based:\ngit checkout -b feature/payment-step-1  # 1 day max\n# Small, releasable increment behind a feature flag\ngit merge main  # Easy — only 1 day of divergence",
    "good_code": "# Trunk-based: all devs commit to main (or short-lived branches <1 day)\n\n# Feature in progress but not ready → hide behind a flag\n# 1. Create branch, work, push small commits daily\ngit checkout -b feat/new-checkout\n# 2. Merge to main within a day — feature flag hides incomplete work\ngit checkout main && git merge feat/new-checkout\n\n# Feature flag keeps it off for users until complete\nif (\\$this->flags->isEnabled('new_checkout', \\$user)) {\n    return \\$this->newCheckout->handle(\\$cart);\n}\nreturn \\$this->legacyCheckout->handle(\\$cart);\n\n# CI runs on every push to main — must stay green\n# If you break main, fix forward or revert immediately",
    "quick_fix": "Commit directly to main (or short-lived branches <2 days) and use feature flags to hide incomplete work — this eliminates merge conflicts and keeps CI green at all times",
    "severity": "info",
    "effort": "high",
    "created": "2026-03-15",
    "updated": "2026-03-22",
    "citation": {
        "canonical_url": "https://codeclaritylab.com/glossary/trunk_based_development",
        "html_url": "https://codeclaritylab.com/glossary/trunk_based_development",
        "json_url": "https://codeclaritylab.com/glossary/trunk_based_development.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": "[Trunk-Based Development](https://codeclaritylab.com/glossary/trunk_based_development) (CodeClarityLab)",
                "footer_credit": "Source: CodeClarityLab Glossary — https://codeclaritylab.com/glossary/trunk_based_development"
            }
        }
    }
}