{"id":77520,"date":"2026-07-07T05:02:02","date_gmt":"2026-07-07T05:02:02","guid":{"rendered":"https:\/\/www.devopsschool.com\/blog\/?p=77520"},"modified":"2026-07-07T05:02:05","modified_gmt":"2026-07-07T05:02:05","slug":"trunk-based-development-master-tutorial","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/blog\/trunk-based-development-master-tutorial\/","title":{"rendered":"Trunk-Based Development Master Tutorial"},"content":{"rendered":"\n

From Beginner to Advanced: A Complete One-Stop Guide to Fast, Safe, Continuous Software Delivery<\/h2>\n\n\n\n
\n\n\n\n

1. What is trunk-based development?<\/h1>\n\n\n\n

Trunk-based development<\/strong>, often shortened as TBD<\/strong>, is a source-control branching strategy where developers integrate small changes frequently into one shared main branch.<\/p>\n\n\n\n

That shared branch is usually called:<\/p>\n\n\n

main\nmaster\ntrunk\nmainline\n<\/code><\/span><\/pre>\n\n\n
Modern repositories usually call it main<\/code>.<\/p>\n\n\n\n
The core definition:<\/p>\n\n\n\n
\n
Trunk-based development is a branching model where developers collaborate around a single main branch and avoid long-lived development branches.<\/strong><\/p>\n<\/blockquote>\n\n\n\n
The trunk-based development reference site defines it as a source-control branching model where developers collaborate on code in a single branch called trunk and resist creating long-lived development branches by using supporting techniques.<\/p>\n\n\n\n
\n\n\n\n
2. The simplest mental model<\/h1>\n\n\n\n
Traditional branch-heavy model:<\/p>\n\n\n
Work privately for days\/weeks \u2192 merge later \u2192 suffer integration pain\n<\/code><\/span><\/pre>\n\n\n
Trunk-based model:<\/p>\n\n\n
Integrate tiny changes continuously \u2192 catch<\/span> problems early \u2192 keep main releasable\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
In one line:<\/p>\n\n\n
Trunk-based development makes integration continuous instead of occasional.\n<\/code><\/span><\/pre>\n\n\n
\n\n\n\n
3. The big idea<\/h1>\n\n\n\n
The big idea is not \u201ceveryone randomly pushes to main.\u201d<\/p>\n\n\n\n
That is chaos, not trunk-based development.<\/p>\n\n\n\n
The real idea is:<\/p>\n\n\n
Everyone works close to main.\nChanges are small.\nCI is fast.\nMain stays healthy.\nIncomplete work is hidden with<\/span> feature flags.\nProduction can be released or rolled back safely.\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n
flowchart<\/span> TD<\/span>\n    A<\/span>[Small change]<\/span> --<\/span>> B<\/span>[Short-lived branch or direct commit]<\/span>\n    B<\/span> --<\/span>> C<\/span>[Fast CI]<\/span>\n    C<\/span> --<\/span>> D<\/span>[Review or pair review]<\/span>\n    D<\/span> --<\/span>> E<\/span>[Merge to trunk\/main]<\/span>\n    E<\/span> --<\/span>> F<\/span>[Build artifact]<\/span>\n    F<\/span> --<\/span>> G<\/span>[Deploy safely]<\/span>\n    G<\/span> --<\/span>> H<\/span>[Release with flag or rollout]<\/span>\n    H<\/span> --<\/span>> I<\/span>[Observe]<\/span>\n    I<\/span> --<\/span>> J<\/span>[Rollback or continue]<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
AWS DevOps Guidance recommends trunk-based development paired with a pull-request workflow using short-lived feature branches as an effective DevOps branching strategy, mainly because it promotes continuous integration and helps teams discover integration problems earlier.<\/p>\n\n\n\n
\n\n\n\n
4. Why trunk-based development exists<\/h1>\n\n\n\n
Software teams often suffer from delayed integration.<\/p>\n\n\n\n
Example:<\/p>\n\n\n
Developer A works on feature branch for 2 weeks.\nDeveloper B works on another branch for 2 weeks.\nDeveloper C changes shared code.\nQA starts late.\nMerge conflicts explode.\nRelease becomes scary.\n<\/code><\/span><\/pre>\n\n\n
Trunk-based development attacks this problem directly.<\/p>\n\n\n\n
It says:<\/p>\n\n\n
Do<\/span> not delay integration.\nMake integration small, frequent, automated, and<\/span> safe.\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
\n\n\n\n
5. The trunk<\/h1>\n\n\n\n
The trunk<\/strong> is the central branch.<\/p>\n\n\n\n
Usually:<\/p>\n\n\n
main\n<\/code><\/span><\/pre>\n\n\n
Sometimes:<\/p>\n\n\n
trunk\nmaster\nmainline\n<\/code><\/span><\/pre>\n\n\n
Rules:<\/p>\n\n\n\n
    \n
  • Trunk must stay healthy.<\/li>\n\n\n\n
  • Trunk must be protected.<\/li>\n\n\n\n
  • Trunk must have fast feedback.<\/li>\n\n\n\n
  • Trunk must be releasable or close to releasable.<\/li>\n\n\n\n
  • Trunk must not become a dumping ground.<\/li>\n\n\n\n
  • Trunk should not contain uncontrolled broken work.<\/li>\n<\/ul>\n\n\n
    gitGraph\n    commit id: \"A\"<\/span>\n    commit id: \"B\"<\/span>\n    commit id: \"C\"<\/span>\n    commit id: \"D\"<\/span>\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
    Simple trunk-only history looks boring. That is the point. Boring history, exciting delivery. Chef\u2019s kiss.<\/p>\n\n\n\n
    \n\n\n\n
    6. Trunk-based development is not the same as no branches<\/h1>\n\n\n\n
    There are two common styles.<\/p>\n\n\n\n
    6.1 Direct-to-trunk<\/h2>\n\n\n\n
    Developers commit directly to main<\/code>.<\/p>\n\n\n
    gitGraph\n    commit id: \"A\"<\/span>\n    commit id: \"small fix\"<\/span>\n    commit id: \"tiny feature\"<\/span>\n    commit id: \"refactor\"<\/span>\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
    Best for:<\/p>\n\n\n\n
      \n
    • very small teams<\/li>\n\n\n\n
    • pair programming<\/li>\n\n\n\n
    • extremely strong CI<\/li>\n\n\n\n
    • mature engineering culture<\/li>\n\n\n\n
    • internal tools<\/li>\n\n\n\n
    • teams with high trust and fast rollback<\/li>\n<\/ul>\n\n\n\n
      6.2 Short-lived branch to trunk<\/h2>\n\n\n\n
      Developers create tiny branches and merge them quickly through PR\/MR.<\/p>\n\n\n
      gitGraph\n    commit id: \"A\"<\/span>\n    branch small-change\n    checkout small-change\n    commit id: \"B\"<\/span>\n    checkout main\n    merge small-change\n    commit id: \"C\"<\/span>\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
      Best for most teams.<\/p>\n\n\n\n
      The trunk-based development reference describes short-lived feature branches as branches that are destined to come back as pull requests into main\/trunk.<\/p>\n\n\n\n
      \n\n\n\n
      7. Direct-to-trunk vs short-lived PR branches<\/h1>\n\n\n\n
      Area<\/th>Direct-to-trunk<\/th>Short-lived PR branch<\/th><\/tr><\/thead>
      Speed<\/td>Very high<\/td>High<\/td><\/tr>
      Review<\/td>Pair\/mob\/post-commit review<\/td>Pull request review<\/td><\/tr>
      Risk<\/td>Higher without discipline<\/td>Lower<\/td><\/tr>
      CI requirement<\/td>Critical<\/td>Critical<\/td><\/tr>
      Best for<\/td>tiny mature teams<\/td>most professional teams<\/td><\/tr>
      Branch lifetime<\/td>none<\/td>hours to 1\u20132 days<\/td><\/tr>
      Governance<\/td>lighter<\/td>stronger<\/td><\/tr>
      Common in enterprise?<\/td>less common<\/td>more common<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
      Recommended default:<\/p>\n\n\n
      Use<\/span> short<\/span>-lived<\/span> PR<\/span> branches<\/span> into<\/span> trunk<\/span>.\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
      This gives you trunk-based development benefits while keeping review and CI gates.<\/p>\n\n\n\n
      \n\n\n\n
      8. Trunk-based development vs feature branch workflow<\/h1>\n\n\n\n
      Area<\/th>Feature branch workflow<\/th>Trunk-based development<\/th><\/tr><\/thead>
      Branch lifetime<\/td>can be days\/weeks<\/td>hours\/days<\/td><\/tr>
      Integration<\/td>delayed<\/td>frequent<\/td><\/tr>
      Release readiness<\/td>depends on branch discipline<\/td>trunk stays releasable<\/td><\/tr>
      Merge conflicts<\/td>higher if branches live long<\/td>lower<\/td><\/tr>
      Review size<\/td>can become large<\/td>small PRs<\/td><\/tr>
      Feature flags<\/td>useful<\/td>very important<\/td><\/tr>
      CI<\/td>important<\/td>critical<\/td><\/tr>
      Delivery speed<\/td>medium\/high<\/td>high<\/td><\/tr>
      Team maturity needed<\/td>medium<\/td>high<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
      \n\n\n\n
      9. Trunk-based development vs Gitflow<\/h1>\n\n\n\n
      Area<\/th>Gitflow<\/th>Trunk-based development<\/th><\/tr><\/thead>
      Main branches<\/td>main<\/code> + develop<\/code><\/td>mostly main<\/code><\/td><\/tr>
      Feature branches<\/td>common<\/td>very short-lived<\/td><\/tr>
      Release branches<\/td>normal<\/td>optional\/rare<\/td><\/tr>
      Hotfix branches<\/td>explicit<\/td>usually revert\/fix forward\/hotfix from trunk<\/td><\/tr>
      Best for<\/td>scheduled\/versioned releases<\/td>continuous delivery<\/td><\/tr>
      Complexity<\/td>high<\/td>lower branch complexity<\/td><\/tr>
      Speed<\/td>medium<\/td>high<\/td><\/tr>
      Governance<\/td>branch-driven<\/td>automation-driven<\/td><\/tr>
      Feature flags<\/td>useful<\/td>nearly essential<\/td><\/tr>
      Risk control<\/td>release branches<\/td>CI, flags, rollback, progressive rollout<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
      Gitflow can be excellent for mobile, desktop, firmware, SDKs, or products with formal release windows. Trunk-based development is usually stronger for SaaS, APIs, web systems, platform services, and teams practicing continuous delivery.<\/p>\n\n\n\n
      \n\n\n\n
      10. The core rule<\/h1>\n\n\n
      Integrate at least daily.\nPrefer multiple times per day.\n<\/code><\/span><\/pre>\n\n\n
      A branch that lives too long becomes a private universe.<\/p>\n\n\n\n
      Private universes eventually collide.<\/p>\n\n\n
      xychart-beta\n    title \"Branch age vs integration risk\"<\/span>\n    x-axis [\"1 hour\"<\/span>, \"1 day\"<\/span>, \"3 days\"<\/span>, \"1 week\"<\/span>, \"2 weeks\"<\/span>, \"1 month\"<\/span>]\n    y-axis \"Integration risk\"<\/span> 0<\/span> --> 100<\/span>\n    bar [5<\/span>, 10<\/span>, 25<\/span>, 45<\/span>, 75<\/span>, 95<\/span>]\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
      The exact numbers are conceptual, but the pattern is real: the longer the branch lives, the more assumptions drift.<\/p>\n\n\n\n
      \n\n\n\n
      11. The trunk-based development promise<\/h1>\n\n\n\n
      Trunk-based development promises:<\/p>\n\n\n\n
        \n
      • less merge pain<\/li>\n\n\n\n
      • faster feedback<\/li>\n\n\n\n
      • cleaner releases<\/li>\n\n\n\n
      • more reliable CI<\/li>\n\n\n\n
      • smaller pull requests<\/li>\n\n\n\n
      • easier rollback<\/li>\n\n\n\n
      • simpler branch structure<\/li>\n\n\n\n
      • better continuous delivery<\/li>\n\n\n\n
      • less branch archaeology<\/li>\n\n\n\n
      • less \u201cworks on my branch\u201d drama<\/li>\n<\/ul>\n\n\n\n
        But it only works when the team also commits to:<\/p>\n\n\n\n
          \n
        • small changes<\/li>\n\n\n\n
        • strong CI<\/li>\n\n\n\n
        • automated tests<\/li>\n\n\n\n
        • feature flags<\/li>\n\n\n\n
        • protected trunk<\/li>\n\n\n\n
        • observability<\/li>\n\n\n\n
        • rollback discipline<\/li>\n\n\n\n
        • fast code review<\/li>\n<\/ul>\n\n\n\n
          DORA lists trunk-based development as a technical capability associated with software delivery and operational performance, within its broader catalog of DevOps capabilities.<\/p>\n\n\n\n
          \n\n\n\n
          12. The basic trunk-based workflow<\/h1>\n\n\n
          flowchart TD\n    A[Start from<\/span> latest main] --> B[Create tiny branch]\n    B --> C[Make small change]\n    C --> D[Run local checks]\n    D --> E[Push branch]\n    E --> F[Open PR\/MR]\n    F --> G[CI runs]\n    F --> H[Review]\n    G --> I{CI green?}\n    H --> J{Approved?}\n    I -- No --> C\n    J -- No --> C\n    I -- Yes --> K[Merge to main]\n    J -- Yes --> K\n    K --> L[Delete branch]\n    L --> M[Deploy\/release safely]\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
          Commands<\/h2>\n\n\n
          git checkout main\ngit pull --ff-only origin main\n\ngit checkout -b small\/change-login-error\n\n# edit files<\/span>\nmake test\n\ngit add .\ngit commit -m \"fix(auth): show clear error for expired session\"<\/span>\ngit push -u origin small\/change-login-error\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
          After PR merge:<\/p>\n\n\n
          git checkout main\ngit pull --ff-only origin main\ngit branch -d small\/change-login-error\ngit fetch --prune\n<\/code><\/span><\/pre>\n\n\n
          \n\n\n\n
          13. The advanced trunk-based workflow<\/h1>\n\n\n
          flowchart TD\n    A[Small work item] --> B[Design if<\/span> risky]\n    B --> C[Short-lived branch]\n    C --> D[Code behind feature flag if<\/span> incomplete]\n    D --> E[Local checks]\n    E --> F[PR\/MR]\n    F --> G[Fast CI]\n    G --> H[Security and<\/span> quality gates]\n    H --> I[Merge to trunk]\n    I --> J[Build immutable artifact]\n    J --> K[Deploy to lower environment]\n    K --> L[Progressive production rollout]\n    L --> M[Observe metrics]\n    M --> N{Healthy?}\n    N -- Yes --> O[Continue<\/span> rollout]\n    N -- No --> P[Rollback \/ disable flag \/ revert]\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
          This is the grown-up version. Less drama. More control.<\/p>\n\n\n\n
          \n\n\n\n
          14. Branch naming in trunk-based development<\/h1>\n\n\n\n
          Because branches are short-lived, branch names should be simple and meaningful.<\/p>\n\n\n\n
          Recommended patterns:<\/p>\n\n\n
          small\/<description<\/span>><\/span>\nfeature\/<ticket<\/span>><\/span>-<description<\/span>><\/span>\nbugfix\/<ticket<\/span>><\/span>-<description<\/span>><\/span>\nchore\/<ticket<\/span>><\/span>-<description<\/span>><\/span>\ndocs\/<ticket<\/span>><\/span>-<description<\/span>><\/span>\nsecurity\/<ticket<\/span>><\/span>-<description<\/span>><\/span>\n<\/code><\/span>Code language:<\/span> HTML, XML<\/span> (<\/span>xml<\/span>)<\/span><\/small><\/pre>\n\n\n
          Examples:<\/p>\n\n\n
          feature\/EVP-123-add-device-filter\nbugfix\/EVP-224-fix-token-refresh\nchore\/EVP-301-upgrade-logging-lib\nsecurity\/EVP-777-mask-api-key\ndocs\/EVP-410-update-runbook\n<\/code><\/span><\/pre>\n\n\n
          Avoid:<\/p>\n\n\n
          rajesh-work\ntest\nfinal\nnew<\/span>\nchanges\nbig-feature\ndo<\/span>-not-delete<\/span>\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
          That last one is how branches become haunted houses.<\/p>\n\n\n\n
          \n\n\n\n
          15. Branch lifetime policy<\/h1>\n\n\n\n
          Branch type<\/th>Ideal lifetime<\/th>Maximum recommended<\/th><\/tr><\/thead>
          tiny fix<\/td>minutes to hours<\/td>same day<\/td><\/tr>
          small feature<\/td>hours to 1 day<\/td>2\u20133 days<\/td><\/tr>
          refactor slice<\/td>hours to 1 day<\/td>2\u20133 days<\/td><\/tr>
          risky change behind flag<\/td>1\u20132 days<\/td>under 1 week<\/td><\/tr>
          experiment<\/td>hours\/days<\/td>1 week<\/td><\/tr>
          release branch, if used<\/td>short stabilization window<\/td>product-dependent<\/td><\/tr>
          long-lived feature branch<\/td>avoid<\/td>avoid<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
          Hard rule:<\/p>\n\n\n
          A trunk-based feature branch should not become a second integration branch.\n<\/code><\/span><\/pre>\n\n\n
          \n\n\n\n
          16. Pull request size policy<\/h1>\n\n\n\n
          Trunk-based development is powered by small PRs.<\/p>\n\n\n\n
          PR size<\/th>Review quality<\/th><\/tr><\/thead>
          1\u2013100 lines<\/td>excellent<\/td><\/tr>
          100\u2013300 lines<\/td>good<\/td><\/tr>
          300\u2013600 lines<\/td>acceptable with context<\/td><\/tr>
          600\u20131,000 lines<\/td>risky<\/td><\/tr>
          1,000+ lines<\/td>split unless generated<\/td><\/tr>
          5,000+ lines<\/td>archaeology, not review<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
          Recommended:<\/p>\n\n\n
          Small PRs, fast review, fast merge.\n<\/code><\/span><\/pre>\n\n\n
          \n\n\n\n
          17. What \u201csmall\u201d really means<\/h1>\n\n\n\n
          A small change is not just fewer lines.<\/p>\n\n\n\n
          A small change has:<\/p>\n\n\n\n
            \n
          • one purpose<\/li>\n\n\n\n
          • clear rollback<\/li>\n\n\n\n
          • clear test scope<\/li>\n\n\n\n
          • clear owner<\/li>\n\n\n\n
          • low hidden risk<\/li>\n\n\n\n
          • readable diff<\/li>\n\n\n\n
          • limited blast radius<\/li>\n<\/ul>\n\n\n\n
            Bad PR:<\/p>\n\n\n
            Add payment retries, refactor billing, update UI, rename database fields, upgrade framework\n<\/code><\/span><\/pre>\n\n\n
            Good PR split:<\/p>\n\n\n
            PR 1: add retry config type\nPR 2: add idempotency key support\nPR 3: add retry logic behind flag\nPR 4: add metrics\nPR 5: enable internally\nPR 6: enable gradually\n<\/code><\/span><\/pre>\n\n
            flowchart<\/span> LR<\/span>\n    A<\/span>[Big risky feature]<\/span> --<\/span>> B<\/span>[Safe slice 1]<\/span>\n    A<\/span> --<\/span>> C<\/span>[Safe slice 2]<\/span>\n    A<\/span> --<\/span>> D<\/span>[Safe slice 3]<\/span>\n    A<\/span> --<\/span>> E<\/span>[Safe slice 4]<\/span>\n    B<\/span> --<\/span>> F<\/span>[Merge to trunk]<\/span>\n    C<\/span> --<\/span>> F<\/span>\n    D<\/span> --<\/span>> F<\/span>\n    E<\/span> --<\/span>> F<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
            \n\n\n\n
            18. The role of CI in trunk-based development<\/h1>\n\n\n\n
            CI is not optional in trunk-based development.<\/p>\n\n\n\n
            CI answers:<\/p>\n\n\n
            Can this<\/span> tiny change safely join trunk?\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n
            flowchart TD\n    A[PR to main] --> B[Checkout]\n    B --> C[Install dependencies]\n    C --> D[Format check]\n    D --> E[Lint]\n    E --> F[Unit tests]\n    F --> G[Build]\n    G --> H[Integration tests]\n    H --> I[Security checks]\n    I --> J{Green?}\n    J -- Yes --> K[Merge allowed]\n    J -- No --> L[Merge blocked]\n<\/code><\/span><\/pre>\n\n\n
            GitHub protected branch rules can require status checks, reviews, linear history, and other constraints before changes land on important branches.<\/p>\n\n\n\n
            \n\n\n\n
            19. CI speed matters<\/h1>\n\n\n\n
            If CI takes too long, trunk-based development slows down.<\/p>\n\n\n\n
            CI duration<\/th>Effect<\/th><\/tr><\/thead>
            under 5 minutes<\/td>excellent<\/td><\/tr>
            5\u201310 minutes<\/td>good<\/td><\/tr>
            10\u201320 minutes<\/td>acceptable<\/td><\/tr>
            20\u201345 minutes<\/td>painful<\/td><\/tr>
            45+ minutes<\/td>developers batch changes and avoid frequent integration<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
            Best practice:<\/p>\n\n\n
            Fast CI for merge.\nDeep CI after merge or nightly.\n<\/code><\/span><\/pre>\n\n\n
            Two-level CI model<\/h2>\n\n\n
            flowchart<\/span> TD<\/span>\n    A<\/span>[PR CI]<\/span> --<\/span>> B<\/span>[Fast checks]<\/span>\n    B<\/span> --<\/span>> C<\/span>[Merge to main]<\/span>\n    C<\/span> --<\/span>> D<\/span>[Post-merge CI]<\/span>\n    D<\/span> --<\/span>> E<\/span>[Deeper integration tests]<\/span>\n    D<\/span> --<\/span>> F<\/span>[Performance tests]<\/span>\n    D<\/span> --<\/span>> G<\/span>[Security scans]<\/span>\n    D<\/span> --<\/span>> H<\/span>[Nightly\/regression]<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
            \n\n\n\n
            20. Required CI gates<\/h1>\n\n\n\n
            Minimum gates<\/h2>\n\n\n\n
            Gate<\/th>Purpose<\/th><\/tr><\/thead>
            format check<\/td>consistent code<\/td><\/tr>
            lint<\/td>static mistakes<\/td><\/tr>
            unit tests<\/td>logic correctness<\/td><\/tr>
            build<\/td>package validity<\/td><\/tr>
            type check<\/td>compile\/type safety<\/td><\/tr>
            secret scan<\/td>prevent leaked credentials<\/td><\/tr>
            dependency scan<\/td>vulnerable library detection<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
            Stronger gates<\/h2>\n\n\n\n
            Gate<\/th>Purpose<\/th><\/tr><\/thead>
            integration tests<\/td>cross-component confidence<\/td><\/tr>
            contract tests<\/td>API compatibility<\/td><\/tr>
            container scan<\/td>image safety<\/td><\/tr>
            IaC scan<\/td>cloud misconfig detection<\/td><\/tr>
            license scan<\/td>compliance<\/td><\/tr>
            policy-as-code<\/td>enforce standards<\/td><\/tr>
            smoke test<\/td>deployment confidence<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
            \n\n\n\n
            21. Protected trunk policy<\/h1>\n\n\n\n
            Trunk must be protected.<\/p>\n\n\n\n
            Recommended rules for main<\/code>:<\/p>\n\n\n
            No direct push for most teams\nPull request required\nRequired CI checks\nAt least one approval\nCODEOWNERS for critical paths\nNo force push\nNo branch deletion\nSecret scanning enabled\nLinear history optional\nAdmin bypass audited\n<\/code><\/span><\/pre>\n\n\n
            GitHub documentation says branch protection rules can define whether collaborators can delete or force-push to a branch and can require conditions such as status checks or linear history.<\/p>\n\n\n\n
            \n\n\n\n
            22. Merge strategy for trunk-based development<\/h1>\n\n\n\n
            Common merge options:<\/p>\n\n\n\n
            Merge type<\/th>Description<\/th>Fit for TBD<\/th><\/tr><\/thead>
            squash merge<\/td>PR becomes one clean commit<\/td>excellent default<\/td><\/tr>
            rebase merge<\/td>keeps linear history<\/td>good for disciplined teams<\/td><\/tr>
            merge commit<\/td>preserves branch shape<\/td>okay, but noisier<\/td><\/tr>
            fast-forward<\/td>pointer moves only<\/td>good for direct\/trunk-heavy teams<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
            Recommended default:<\/p>\n\n\n
            Use<\/span> squash<\/span> merge<\/span> for<\/span> normal<\/span> small<\/span> PRs<\/span>.\nUse<\/span> rebase<\/span> merge<\/span> if<\/span> commits<\/span> are<\/span> clean<\/span>.\nAvoid<\/span> noisy<\/span> merge<\/span> commits<\/span> for<\/span> tiny<\/span> branches<\/span> unless<\/span> audit<\/span> requires<\/span> them<\/span>.\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
            \n\n\n\n
            23. Commit message standard<\/h1>\n\n\n\n
            Use meaningful commit messages.<\/p>\n\n\n\n
            Recommended:<\/p>\n\n\n
            <type<\/span>><\/span>(scope): summary\n<\/code><\/span>Code language:<\/span> HTML, XML<\/span> (<\/span>xml<\/span>)<\/span><\/small><\/pre>\n\n\n
            Examples:<\/p>\n\n\n
            feat(auth)<\/span>: add session renewal flag\nfix(payment)<\/span>: handle gateway timeout\nchore(ci)<\/span>: speed up unit test cache\ndocs(runbook)<\/span>: add rollback steps\ntest(api)<\/span>: add contract test for vehicle endpoint\n<\/code><\/span>Code language:<\/span> HTTP<\/span> (<\/span>http<\/span>)<\/span><\/small><\/pre>\n\n\n
            Conventional Commits defines a lightweight structure for commit messages that gives human-readable and machine-readable meaning to history, and aligns with semantic versioning concepts such as features, fixes, and breaking changes.<\/p>\n\n\n\n
            \n\n\n\n
            24. Feature flags: the engine of trunk-based development<\/h1>\n\n\n\n
            Feature flags let teams merge incomplete or risky work into trunk safely.<\/p>\n\n\n\n
            Without feature flags:<\/p>\n\n\n
            Feature incomplete \u2192 keep branch open\n<\/code><\/span><\/pre>\n\n\n
            With feature flags:<\/p>\n\n\n
            Feature incomplete \u2192 merge to trunk with<\/span> flag OFF\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
            Martin Fowler\u2019s feature toggle article explains that release toggles allow in-progress features to be checked into a shared integration branch while keeping that branch deployable to production.<\/p>\n\n\n
            flowchart<\/span> TD<\/span>\n    A<\/span>[Code feature]<\/span> --<\/span>> B<\/span>[Wrap with feature flag]<\/span>\n    B<\/span> --<\/span>> C<\/span>[Merge to trunk]<\/span>\n    C<\/span> --<\/span>> D<\/span>[Deploy with flag OFF]<\/span>\n    D<\/span> --<\/span>> E<\/span>[Enable for internal users]<\/span>\n    E<\/span> --<\/span>> F<\/span>[Enable for beta users]<\/span>\n    F<\/span> --<\/span>> G<\/span>[Enable for 10%]<\/span>\n    G<\/span> --<\/span>> H<\/span>[Enable for 100%]<\/span>\n    H<\/span> --<\/span>> I<\/span>[Remove flag]<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
            \n\n\n\n
            25. Feature flag types<\/h1>\n\n\n\n
            Flag type<\/th>Purpose<\/th>Example<\/th><\/tr><\/thead>
            release flag<\/td>hide incomplete feature<\/td>new_checkout_enabled<\/code><\/td><\/tr>
            ops flag<\/td>kill switch<\/td>payment_retry_enabled<\/code><\/td><\/tr>
            experiment flag<\/td>A\/B test<\/td>homepage_variant_b<\/code><\/td><\/tr>
            permission flag<\/td>customer\/role control<\/td>premium_reports_enabled<\/code><\/td><\/tr>
            migration flag<\/td>gradual backend switch<\/td>use_new_search_index<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
            Martin Fowler\u2019s feature-flag taxonomy discusses release toggles, experiment toggles, ops toggles, and permissioning toggles as different uses of feature flags.<\/p>\n\n\n\n
            \n\n\n\n
            26. Feature flag rules<\/h1>\n\n\n\n
            Every flag must have:<\/p>\n\n\n\n
            Metadata<\/th>Example<\/th><\/tr><\/thead>
            owner<\/td>payments team<\/td><\/tr>
            creation date<\/td>2026-07-07<\/td><\/tr>
            expiry date<\/td>2026-08-07<\/td><\/tr>
            default state<\/td>off<\/td><\/tr>
            rollout plan<\/td>internal \u2192 10% \u2192 50% \u2192 100%<\/td><\/tr>
            rollback action<\/td>disable flag<\/td><\/tr>
            cleanup ticket<\/td>remove after rollout<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
            Flag hygiene rule<\/h2>\n\n\n
            A feature flag without an expiry date is future technical debt.\n<\/code><\/span><\/pre>\n\n\n
            Atlassian notes that feature flags complement trunk-based development and encourage small-batch updates by allowing inactive code paths to be activated later.<\/p>\n\n\n\n
            \n\n\n\n
            27. Branch by abstraction<\/h1>\n\n\n\n
            Branch by abstraction is how teams do large changes without long-lived branches.<\/p>\n\n\n\n
            Instead of building a giant feature branch for months, you introduce an abstraction and migrate gradually.<\/p>\n\n\n
            flowchart<\/span> TD<\/span>\n    A<\/span>[Old implementation]<\/span> --<\/span>> B<\/span>[Create abstraction\/interface]<\/span>\n    B<\/span> --<\/span>> C<\/span>[Route old behavior through abstraction]<\/span>\n    C<\/span> --<\/span>> D<\/span>[Add new implementation behind flag]<\/span>\n    D<\/span> --<\/span>> E<\/span>[Migrate callers gradually]<\/span>\n    E<\/span> --<\/span>> F<\/span>[Remove old implementation]<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
            Example:<\/p>\n\n\n
            OldPaymentClient\n       \u2193\nPaymentProvider interface\n       \u2193\nStripeProvider + NewProvider\n       \u2193\nflag: use_new_payment_provider\n<\/code><\/span><\/pre>\n\n\n
            PR sequence<\/h2>\n\n\n
            PR 1<\/span>: add PaymentProvider interface\nPR 2<\/span>: route old provider through interface\nPR 3<\/span>: add new<\/span> provider behind flag\nPR 4<\/span>: migrate one payment path\nPR 5<\/span>: migrate all paths\nPR 6<\/span>: remove old provider and flag\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
            This is one of the most powerful advanced techniques in trunk-based development.<\/p>\n\n\n\n
            \n\n\n\n
            28. Expand-migrate-contract for databases<\/h1>\n\n\n\n
            Database changes are dangerous in trunk-based development unless phased.<\/p>\n\n\n\n
            Use:<\/p>\n\n\n
            Expand \u2192 Migrate \u2192 Contract\n<\/code><\/span><\/pre>\n\n
            flowchart<\/span> LR<\/span>\n    A<\/span>[Expand schema]<\/span> --<\/span>> B<\/span>[Deploy backward-compatible app]<\/span>\n    B<\/span> --<\/span>> C<\/span>[Backfill data]<\/span>\n    C<\/span> --<\/span>> D<\/span>[Switch reads\/writes]<\/span>\n    D<\/span> --<\/span>> E<\/span>[Contract old schema]<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
            Bad migration<\/h2>\n\n\n
            ALTER TABLE users DROP COLUMN name;\n<\/code><\/span><\/pre>\n\n\n
            Safer migration<\/h2>\n\n\n
            1.<\/span> Add new<\/span> column.\n2.<\/span> Deploy app that writes both old and<\/span> new<\/span>.\n3.<\/span> Backfill data.\n4.<\/span> Switch<\/span> reads to new<\/span> column.\n5.<\/span> Wait and<\/span> monitor.\n6.<\/span> Remove old column later.\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
            Rule<\/h2>\n\n\n
            Trunk must support safe rolling deployment.\n<\/code><\/span><\/pre>\n\n\n
            That means new code and old code may run together during rollout.<\/p>\n\n\n\n
            \n\n\n\n
            29. Release from trunk<\/h1>\n\n\n\n
            In trunk-based development, releases usually come from trunk.<\/p>\n\n\n
            flowchart<\/span> TD<\/span>\n    A<\/span>[main\/trunk]<\/span> --<\/span>> B<\/span>[Build artifact]<\/span>\n    B<\/span> --<\/span>> C<\/span>[Deploy to staging]<\/span>\n    C<\/span> --<\/span>> D<\/span>[Deploy to production]<\/span>\n    D<\/span> --<\/span>> E<\/span>[Release using flag or rollout]<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
            Common release models:<\/p>\n\n\n\n
            Model<\/th>How it works<\/th><\/tr><\/thead>
            deploy every merge<\/td>every green main commit deploys<\/td><\/tr>
            scheduled deploy from trunk<\/td>deploy selected trunk build<\/td><\/tr>
            release tag from trunk<\/td>tag known-good commit<\/td><\/tr>
            release branch from trunk<\/td>short stabilization branch<\/td><\/tr>
            feature flag release<\/td>deploy code, release later<\/td><\/tr>
            progressive delivery<\/td>canary\/blue-green\/rolling<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
            \n\n\n\n
            30. Release branches in trunk-based development<\/h1>\n\n\n\n
            Trunk-based development tries to avoid long-lived development branches, but short-lived release branches can still exist.<\/p>\n\n\n\n
            Use release branches when:<\/p>\n\n\n\n
              \n
            • mobile app store approval is needed<\/li>\n\n\n\n
            • enterprise release certification is needed<\/li>\n\n\n\n
            • a release needs short stabilization<\/li>\n\n\n\n
            • production patching must happen separately<\/li>\n\n\n\n
            • customers need supported old versions<\/li>\n<\/ul>\n\n\n\n
              Do not use release branches as hidden feature branches.<\/p>\n\n\n
              gitGraph\n    commit id: \"A\"<\/span>\n    commit id: \"B\"<\/span>\n    branch release\/2.4<\/span>\n    checkout release\/2.4<\/span>\n    commit id: \"release fix\"<\/span>\n    checkout main\n    commit id: \"future work\"<\/span>\n    checkout release\/2.4<\/span>\n    commit id: \"tag v2.4.0\"<\/span>\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
              Microsoft describes using trunk-based branching together with a release branch flow model to develop products quickly, deploy regularly, and deliver changes safely to production.<\/p>\n\n\n\n
              \n\n\n\n
              31. Release branch rules<\/h1>\n\n\n\n
              If you use release branches with trunk-based development:<\/p>\n\n\n\n
              Allowed:<\/p>\n\n\n
              bug fixes\nversion bump\nrelease notes\nstabilization fixes\nsafe configuration corrections\n<\/code><\/span><\/pre>\n\n\n
              Not allowed:<\/p>\n\n\n
              new<\/span> features\nbig refactors\nexperimental dependency upgrades\nunrelated cleanup\narchitecture rewrites\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
              Rule:<\/p>\n\n\n
              Release branches stabilize; trunk continues.\n<\/code><\/span><\/pre>\n\n\n
              \n\n\n\n
              32. Hotfixes in trunk-based development<\/h1>\n\n\n\n
              Hotfix strategies:<\/p>\n\n\n\n
              Situation<\/th>Best action<\/th><\/tr><\/thead>
              bad feature behind flag<\/td>disable flag<\/td><\/tr>
              bad commit on trunk<\/td>revert commit<\/td><\/tr>
              urgent production bug<\/td>fix on trunk, deploy<\/td><\/tr>
              release branch active<\/td>fix trunk and cherry-pick\/backport<\/td><\/tr>
              old version affected<\/td>patch support\/release branch<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n
              flowchart TD\n    A[Production issue] --> B{Feature flag?}\n    B -- Yes --> C[Disable flag]\n    B -- No --> D{Bad commit?}\n    D -- Yes --> E[Revert on trunk]\n    D -- No --> F[Small hotfix to trunk]\n    F --> G[CI]\n    G --> H[Deploy]\n    E --> H\n    C --> I[Monitor]\n    H --> I\n<\/code><\/span><\/pre>\n\n\n
              \n\n\n\n
              33. Rollback strategy<\/h1>\n\n\n\n
              In trunk-based development, rollback must be boring.<\/p>\n\n\n\n
              Rollback methods:<\/p>\n\n\n\n
              Method<\/th>Best for<\/th><\/tr><\/thead>
              disable feature flag<\/td>bad feature behavior<\/td><\/tr>
              revert commit<\/td>bad source change<\/td><\/tr>
              redeploy previous artifact<\/td>bad deployment<\/td><\/tr>
              rollback config<\/td>bad configuration<\/td><\/tr>
              pause rollout<\/td>canary\/rolling issue<\/td><\/tr>
              fix forward<\/td>tiny safe correction<\/td><\/tr>
              restore backup<\/td>data loss\/corruption<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n
              flowchart TD\n    A[Issue detected] --> B{Can flag disable?}\n    B -- Yes --> C[Turn flag off]\n    B -- No --> D{Previous artifact known?}\n    D -- Yes --> E[Redeploy previous artifact]\n    D -- No --> F{Bad commit known?}\n    F -- Yes --> G[Revert commit]\n    F -- No --> H[Fix forward]\n<\/code><\/span><\/pre>\n\n\n
              \n\n\n\n
              34. Progressive delivery<\/h1>\n\n\n\n
              Progressive delivery is a natural partner for trunk-based development.<\/p>\n\n\n\n
              Strategies:<\/p>\n\n\n\n
                \n
              • rolling deployment<\/li>\n\n\n\n
              • canary deployment<\/li>\n\n\n\n
              • blue-green deployment<\/li>\n\n\n\n
              • feature flag rollout<\/li>\n\n\n\n
              • shadow traffic<\/li>\n\n\n\n
              • A\/B testing<\/li>\n<\/ul>\n\n\n\n
                Kubernetes rolling updates gradually replace old Pods with new Pods and can keep an application available by routing traffic only to Pods that can serve requests.<\/p>\n\n\n
                flowchart<\/span> LR<\/span>\n    A<\/span>[Deploy v2 to 1%]<\/span> --<\/span>> B<\/span>[Check metrics]<\/span>\n    B<\/span> --<\/span>> C<\/span>[Deploy to 10%]<\/span>\n    C<\/span> --<\/span>> D<\/span>[Check metrics]<\/span>\n    D<\/span> --<\/span>> E<\/span>[Deploy to 50%]<\/span>\n    E<\/span> --<\/span>> F<\/span>[Check metrics]<\/span>\n    F<\/span> --<\/span>> G<\/span>[Deploy to 100%]<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
                Canary gates<\/h2>\n\n\n\n
                Metric<\/th>Watch for<\/th><\/tr><\/thead>
                error rate<\/td>increase<\/td><\/tr>
                latency<\/td>regression<\/td><\/tr>
                CPU\/memory<\/td>saturation<\/td><\/tr>
                logs<\/td>new exceptions<\/td><\/tr>
                traces<\/td>slow spans<\/td><\/tr>
                business metric<\/td>conversion\/login\/payment drop<\/td><\/tr>
                user reports<\/td>complaints<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                \n\n\n\n
                35. Trunk-based development and continuous delivery<\/h1>\n\n\n\n
                Trunk-based development is one of the strongest foundations for continuous delivery.<\/p>\n\n\n\n
                Why?<\/p>\n\n\n
                Continuous delivery needs releasable code.\nReleasable code needs frequent integration.\nFrequent integration needs trunk-based development discipline.\n<\/code><\/span><\/pre>\n\n
                flowchart<\/span> LR<\/span>\n    A<\/span>[Small changes]<\/span> --<\/span>> B<\/span>[Frequent integration]<\/span>\n    B<\/span> --<\/span>> C<\/span>[Fast CI]<\/span>\n    C<\/span> --<\/span>> D<\/span>[Always releasable trunk]<\/span>\n    D<\/span> --<\/span>> E<\/span>[Continuous delivery]<\/span>\n    E<\/span> --<\/span>> F<\/span>[Fast feedback]<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
                AWS\u2019s Git branching guidance describes trunk-based development as keeping the codebase continuously releasable by integrating changes frequently and relying on automated testing and continuous integration.<\/p>\n\n\n\n
                \n\n\n\n
                36. Trunk-based development for small teams<\/h1>\n\n\n\n
                Small team model:<\/p>\n\n\n
                main\n<\/code><\/span><\/pre>\n\n\n
                or:<\/p>\n\n\n
                main\nshort-lived\/*\n<\/code><\/span><\/pre>\n\n\n
                Rules:<\/p>\n\n\n\n
                  \n
                • pair review or PR review<\/li>\n\n\n\n
                • CI required<\/li>\n\n\n\n
                • small commits<\/li>\n\n\n\n
                • feature flags for incomplete work<\/li>\n\n\n\n
                • deploy frequently<\/li>\n\n\n\n
                • revert quickly<\/li>\n<\/ul>\n\n\n
                  flowchart<\/span> TD<\/span>\n    A<\/span>[Developer]<\/span> --<\/span>> B<\/span>[Small change]<\/span>\n    B<\/span> --<\/span>> C<\/span>[CI]<\/span>\n    C<\/span> --<\/span>> D<\/span>[main]<\/span>\n    D<\/span> --<\/span>> E<\/span>[Deploy]<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
                  Small teams can move very fast with trunk-based development because communication cost is low.<\/p>\n\n\n\n
                  \n\n\n\n
                  37. Trunk-based development for larger teams<\/h1>\n\n\n\n
                  Large teams need more control.<\/p>\n\n\n\n
                  Recommended:<\/p>\n\n\n
                  main\nshort-lived feature branches\nCODEOWNERS\npath-based CI\nfeature flags\nrelease tags\nprogressive delivery\n<\/code><\/span><\/pre>\n\n
                  flowchart<\/span> TD<\/span>\n    A<\/span>[Team A change]<\/span> --<\/span>> D<\/span>[main]<\/span>\n    B<\/span>[Team B change]<\/span> --<\/span>> D<\/span>\n    C<\/span>[Team C change]<\/span> --<\/span>> D<\/span>\n    D<\/span> --<\/span>> E<\/span>[CI fan-out]<\/span>\n    E<\/span> --<\/span>> F<\/span>[Build affected artifacts]<\/span>\n    F<\/span> --<\/span>> G<\/span>[Deploy safely]<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
                  Controls:<\/p>\n\n\n\n
                    \n
                  • CODEOWNERS<\/li>\n\n\n\n
                  • branch protection<\/li>\n\n\n\n
                  • required checks<\/li>\n\n\n\n
                  • selective CI<\/li>\n\n\n\n
                  • service ownership<\/li>\n\n\n\n
                  • feature flag ownership<\/li>\n\n\n\n
                  • release dashboards<\/li>\n\n\n\n
                  • on-call ownership<\/li>\n<\/ul>\n\n\n\n
                    \n\n\n\n
                    38. Trunk-based development in monorepos<\/h1>\n\n\n\n
                    Trunk-based development works very well in monorepos, but only with tooling.<\/p>\n\n\n\n
                    Monorepo structure:<\/p>\n\n\n
                    repo\/\n  apps\/\n    web\/\n    admin\/\n  services\/\n    auth\/\n    payment\/\n    notification\/\n  packages\/\n    common\/\n    ui\/\n  infra\/\n  docs\/\n<\/code><\/span><\/pre>\n\n\n
                    Needs:<\/p>\n\n\n\n
                      \n
                    • path-based CI<\/li>\n\n\n\n
                    • affected-project detection<\/li>\n\n\n\n
                    • CODEOWNERS<\/li>\n\n\n\n
                    • dependency graph<\/li>\n\n\n\n
                    • caching<\/li>\n\n\n\n
                    • small PRs<\/li>\n\n\n\n
                    • feature flags<\/li>\n\n\n\n
                    • fast revert<\/li>\n<\/ul>\n\n\n
                      flowchart<\/span> TD<\/span>\n    A<\/span>[Commit to main]<\/span> --<\/span>> B<\/span>[Detect changed paths]<\/span>\n    B<\/span> --<\/span>> C<\/span>[Find affected services\/packages]<\/span>\n    C<\/span> --<\/span>> D<\/span>[Run targeted tests]<\/span>\n    D<\/span> --<\/span>> E<\/span>[Build affected artifacts]<\/span>\n    E<\/span> --<\/span>> F<\/span>[Deploy only affected services]<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
                      \n\n\n\n
                      39. Trunk-based development for microservices<\/h1>\n\n\n\n
                      Microservices need independent deployability.<\/p>\n\n\n\n
                      Do not use branches to coordinate service compatibility.<\/p>\n\n\n\n
                      Use:<\/p>\n\n\n\n
                        \n
                      • backward-compatible APIs<\/li>\n\n\n\n
                      • contract tests<\/li>\n\n\n\n
                      • feature flags<\/li>\n\n\n\n
                      • versioned endpoints<\/li>\n\n\n\n
                      • tolerant readers<\/li>\n\n\n\n
                      • gradual rollout<\/li>\n\n\n\n
                      • observability<\/li>\n<\/ul>\n\n\n
                        flowchart<\/span> TD<\/span>\n    A<\/span>[Service A change]<\/span> --<\/span>> B<\/span>[Backward-compatible API]<\/span>\n    B<\/span> --<\/span>> C<\/span>[Contract tests]<\/span>\n    C<\/span> --<\/span>> D<\/span>[Merge to trunk]<\/span>\n    D<\/span> --<\/span>> E<\/span>[Deploy Service A]<\/span>\n    E<\/span> --<\/span>> F<\/span>[Monitor Service B\/C consumers]<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
                        Bad:<\/p>\n\n\n
                        service-a waits for service-b branch\nservice-b waits for service-c branch\neverything waits for release day\n<\/code><\/span><\/pre>\n\n\n
                        That is distributed merge hell with extra steps.<\/p>\n\n\n\n
                        \n\n\n\n
                        40. Trunk-based development for Infrastructure as Code<\/h1>\n\n\n\n
                        IaC repositories can use trunk-based development, but with strong plan review.<\/p>\n\n\n\n
                        Recommended:<\/p>\n\n\n
                        main\nshort-lived\/*\n<\/code><\/span><\/pre>\n\n\n
                        Workflow:<\/p>\n\n\n
                        flowchart<\/span> TD<\/span>\n    A<\/span>[Small infra change]<\/span> --<\/span>> B<\/span>[PR to main]<\/span>\n    B<\/span> --<\/span>> C<\/span>[terraform fmt]<\/span>\n    C<\/span> --<\/span>> D<\/span>[terraform validate]<\/span>\n    D<\/span> --<\/span>> E<\/span>[terraform plan]<\/span>\n    E<\/span> --<\/span>> F<\/span>[security scan]<\/span>\n    F<\/span> --<\/span>> G<\/span>[cost\/blast-radius review]<\/span>\n    G<\/span> --<\/span>> H<\/span>[merge to main]<\/span>\n    H<\/span> --<\/span>> I<\/span>[apply through pipeline]<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
                        Rules:<\/p>\n\n\n\n
                          \n
                        • no direct prod apply from laptop<\/li>\n\n\n\n
                        • plan output required<\/li>\n\n\n\n
                        • cost\/security review for risky changes<\/li>\n\n\n\n
                        • production approval where needed<\/li>\n\n\n\n
                        • state protected<\/li>\n\n\n\n
                        • secrets never committed<\/li>\n\n\n\n
                        • small changes only<\/li>\n<\/ul>\n\n\n\n
                          \n\n\n\n
                          41. Trunk-based development for Kubernetes GitOps<\/h1>\n\n\n\n
                          GitOps plus trunk-based development is a strong combination.<\/p>\n\n\n\n
                          Recommended:<\/p>\n\n\n
                          main\nshort-lived\/*\n<\/code><\/span><\/pre>\n\n\n
                          Repository layout:<\/p>\n\n\n
                          gitops\/\n  apps\/\n    auth\/\n    payment\/\n  clusters\/\n    dev\/\n    staging\/\n    production\/\n  platform\/\n    ingress\/\n    monitoring\/\n<\/code><\/span><\/pre>\n\n\n
                          Flow:<\/p>\n\n\n
                          flowchart<\/span> LR<\/span>\n    A<\/span>[App source merged to main]<\/span> --<\/span>> B<\/span>[Build image]<\/span>\n    B<\/span> --<\/span>> C<\/span>[Update GitOps repo]<\/span>\n    C<\/span> --<\/span>> D<\/span>[PR to main]<\/span>\n    D<\/span> --<\/span>> E<\/span>[Argo CD \/ Flux sync]<\/span>\n    E<\/span> --<\/span>> F<\/span>[Kubernetes cluster]<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
                          Rules:<\/p>\n\n\n\n
                            \n
                          • Git is desired state.<\/li>\n\n\n\n
                          • Changes go through PR.<\/li>\n\n\n\n
                          • Production changes are reviewed.<\/li>\n\n\n\n
                          • Rollback is Git revert or previous artifact.<\/li>\n\n\n\n
                          • Use immutable image tags\/digests.<\/li>\n\n\n\n
                          • Build once, promote same artifact.<\/li>\n<\/ul>\n\n\n\n
                            \n\n\n\n
                            42. Trunk-based development for mobile apps<\/h1>\n\n\n\n
                            Mobile apps often need release branches even if development is trunk-based.<\/p>\n\n\n\n
                            Recommended:<\/p>\n\n\n
                            main\nshort-lived\/*\nrelease\/ios-5.1.0\nrelease\/android-5.1.0\n<\/code><\/span><\/pre>\n\n\n
                            Flow:<\/p>\n\n\n
                            flowchart<\/span> TD<\/span>\n    A<\/span>[main]<\/span> --<\/span>> B<\/span>[release\/mobile-5.1.0]<\/span>\n    B<\/span> --<\/span>> C<\/span>[QA]<\/span>\n    C<\/span> --<\/span>> D<\/span>[TestFlight\/Internal track]<\/span>\n    D<\/span> --<\/span>> E<\/span>[App Store\/Play review]<\/span>\n    E<\/span> --<\/span>> F<\/span>[Staged rollout]<\/span>\n    F<\/span> --<\/span>> G<\/span>[tag v5.1.0]<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
                            Rules:<\/p>\n\n\n\n
                              \n
                            • trunk continues normal development<\/li>\n\n\n\n
                            • release branch gets stabilization fixes only<\/li>\n\n\n\n
                            • tags match shipped builds<\/li>\n\n\n\n
                            • backend APIs remain backward compatible<\/li>\n\n\n\n
                            • use remote config\/feature flags carefully<\/li>\n<\/ul>\n\n\n\n
                              \n\n\n\n
                              43. Trunk-based development for libraries and SDKs<\/h1>\n\n\n\n
                              Libraries can use trunk-based development with release tags and support branches.<\/p>\n\n\n\n
                              Recommended:<\/p>\n\n\n
                              main\nshort-lived\/*\nrelease\/* optional\nsupport\/* optional\n<\/code><\/span><\/pre>\n\n\n
                              Rules:<\/p>\n\n\n\n
                                \n
                              • main contains latest development<\/li>\n\n\n\n
                              • tag every release<\/li>\n\n\n\n
                              • use Semantic Versioning<\/li>\n\n\n\n
                              • backport critical fixes if supporting old versions<\/li>\n\n\n\n
                              • use release branches only when stabilization is needed<\/li>\n<\/ul>\n\n\n\n
                                \n\n\n\n
                                44. Trunk-based development and semantic versioning<\/h1>\n\n\n\n
                                Trunk-based development does not remove versioning.<\/p>\n\n\n\n
                                Use tags:<\/p>\n\n\n
                                v1<\/span>.0<\/span>.0<\/span>\nv1<\/span>.1<\/span>.0<\/span>\nv1<\/span>.1<\/span>.1<\/span>\nv2<\/span>.0<\/span>.0<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
                                Common mapping:<\/p>\n\n\n\n
                                Change<\/th>Version impact<\/th><\/tr><\/thead>
                                bug fix<\/td>patch<\/td><\/tr>
                                backward-compatible feature<\/td>minor<\/td><\/tr>
                                breaking change<\/td>major<\/td><\/tr>
                                internal refactor<\/td>no public version change<\/td><\/tr>
                                security fix<\/td>patch or major depending compatibility<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                                \n\n\n\n
                                45. Trunk-based development PR template<\/h1>\n\n\n
                                ## Summary<\/span>\n\nExplain the change in 2<\/span>\u20135<\/span> lines.\n\n## Why<\/span>\n\nWhat problem does this solve?\n\n## Scope<\/span>\n\n- [ ] Small isolated change\n- [ ] Behind feature flag\n- [ ] Refactor only\n- [ ] Bug fix\n- [ ] Infrastructure\/config change\n\n## Testing<\/span>\n\n- [ ] Unit tests\n- [ ] Integration tests\n- [ ] Contract tests\n- [ ] Manual validation\n- [ ] Not applicable\n\n## Risk<\/span>\n\nLow \/ Medium \/ High\n\n## Feature flag<\/span>\n\nFlag name:\nDefault<\/span> state:\nRollout plan:\nCleanup ticket:\n\n## Rollback<\/span>\n\nHow can this be reverted, disabled, or<\/span> rolled back?\n\n## Checklist<\/span>\n\n- [ ] CI passes\n- [ ] Change is small\n- [ ] No secrets committed\n- [ ] Backward compatibility considered\n- [ ] Observability considered\n- [ ] Rollback path known\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
                                \n\n\n\n
                                46. Company-ready trunk-based policy<\/h1>\n\n\n
                                Trunk-Based Development Policy\n\n1.<\/span> main is the single shared trunk.\n2.<\/span> main must always remain healthy and releasable.\n3.<\/span> Long-lived feature branches are not allowed.\n4.<\/span> Developers must use small changes and short-lived branches.\n5.<\/span> Branches should merge within hours or a few days.\n6.<\/span> All changes must pass CI before merge.\n7.<\/span> Pull requests must be small and reviewable.\n8.<\/span> Incomplete features must be hidden behind feature flags.\n9.<\/span> Feature flags must have owners and expiry dates.\n10.<\/span> Production releases must be traceable to commits and artifacts.\n11.<\/span> Rollback must be possible through flag disablement, revert, or redeploy.\n12.<\/span> CI\/CD pipeline changes require<\/span> owner review.\n13.<\/span> Database changes must be backward compatible.\n14.<\/span> Stale branches must be deleted.\n15.<\/span> Trunk health is a team responsibility.\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                                \n\n\n\n
                                47. Branch protection policy<\/h1>\n\n\n\n
                                For main<\/code>:<\/p>\n\n\n
                                - require<\/span> pull request\n- require<\/span> status checks\n- require<\/span> one or more approvals\n- require<\/span> CODEOWNERS for<\/span> critical paths\n- block force push\n- block deletion\n- require<\/span> branch to be up to date before merge\n- require<\/span> secret scanning\n- optionally require<\/span> signed commits\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                                For short-lived\/*<\/code> branches:<\/p>\n\n\n
                                - owner can push\n- CI runs automatically\n- PR required before merge\n- delete<\/span> after merge\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                                \n\n\n\n
                                48. CODEOWNERS example<\/h1>\n\n\n
                                # Platform and CI\/CD<\/span>\n\/.github\/workflows\/ @devops-team\n\/infra\/ @platform-team\n\n# Services<\/span>\n\/services\/auth\/ @identity-team\n\/services\/payment\/ @payment-team\n\/services\/notification\/ @backend-team\n\n# Sensitive areas<\/span>\n\/security\/ @security-team\n\/database\/migrations\/ @backend-leads @platform-team\n\n# Shared libraries<\/span>\n\/packages\/common\/ @architecture-team\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
                                \n\n\n\n
                                49. Developer daily checklist<\/h1>\n\n\n\n
                                Before opening PR:<\/p>\n\n\n
                                - Branch is based on latest main.\n- Change is small.\n- Tests are added or updated.\n- Local checks pass.\n- Feature flag exists if feature is incomplete.\n- Rollback path is clear.\n- No secrets are committed.\n- PR description explains why.\n<\/code><\/span><\/pre>\n\n\n
                                Before merging:<\/p>\n\n\n
                                - CI is green.\n- Review is complete.\n- Risk is understood.\n- Main is healthy.\n- Feature flag default<\/span> is safe.\n- Monitoring exists if<\/span> production behavior changes.\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                                \n\n\n\n
                                50. Reviewer checklist<\/h1>\n\n\n\n
                                Reviewers should check:<\/p>\n\n\n\n
                                  \n
                                • Is this change small enough?<\/li>\n\n\n\n
                                • Does it belong on trunk now?<\/li>\n\n\n\n
                                • Is incomplete work hidden?<\/li>\n\n\n\n
                                • Are tests adequate?<\/li>\n\n\n\n
                                • Is it backward compatible?<\/li>\n\n\n\n
                                • Is rollback possible?<\/li>\n\n\n\n
                                • Is the feature flag safe?<\/li>\n\n\n\n
                                • Is observability adequate?<\/li>\n\n\n\n
                                • Does it affect database schema?<\/li>\n\n\n\n
                                • Does it affect deployment or security?<\/li>\n<\/ul>\n\n\n\n
                                  \n\n\n\n
                                  51. Release checklist<\/h1>\n\n\n\n
                                  Before production rollout:<\/p>\n\n\n
                                  - Artifact built from<\/span> main.\n- Commit SHA known.\n- CI passed.\n- Security scans passed.\n- Feature flags configured.\n- Database migrations safe.\n- Rollback plan ready.\n- Dashboard ready.\n- Alerts active.\n- On-call owner aware.\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                                  After rollout:<\/p>\n\n\n
                                  - Monitor errors.\n- Monitor latency.\n- Monitor business metric.\n- Continue<\/span>\/pause rollout.\n- Remove old feature flags after success.\n- Document incident if<\/span> rollback was needed.\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
                                  \n\n\n\n
                                  52. Migration path from Gitflow to trunk-based development<\/h1>\n\n\n\n
                                  Many teams cannot jump directly from Gitflow to trunk-based development.<\/p>\n\n\n\n
                                  Use a gradual migration.<\/p>\n\n\n
                                  flowchart<\/span> TD<\/span>\n    A<\/span>[Current Gitflow]<\/span> --<\/span>> B<\/span>[Protect develop\/main]<\/span>\n    B<\/span> --<\/span>> C<\/span>[Reduce feature branch lifetime]<\/span>\n    C<\/span> --<\/span>> D<\/span>[Improve CI speed]<\/span>\n    D<\/span> --<\/span>> E<\/span>[Introduce feature flags]<\/span>\n    E<\/span> --<\/span>> F<\/span>[Merge features to develop daily]<\/span>\n    F<\/span> --<\/span>> G<\/span>[Remove long-lived develop dependency]<\/span>\n    G<\/span> --<\/span>> H<\/span>[Make main the trunk]<\/span>\n    H<\/span> --<\/span>> I<\/span>[Release from main]<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
                                  Step-by-step<\/h2>\n\n\n\n
                                  Step<\/th>Action<\/th><\/tr><\/thead>
                                  1<\/td>measure current branch age<\/td><\/tr>
                                  2<\/td>limit feature branches to under one week<\/td><\/tr>
                                  3<\/td>require CI on PRs<\/td><\/tr>
                                  4<\/td>add feature flags<\/td><\/tr>
                                  5<\/td>split large PRs<\/td><\/tr>
                                  6<\/td>make develop<\/code> always green<\/td><\/tr>
                                  7<\/td>merge more frequently<\/td><\/tr>
                                  8<\/td>move toward main<\/code> as trunk<\/td><\/tr>
                                  9<\/td>use release branches only when needed<\/td><\/tr>
                                  10<\/td>delete stale branches<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                                  \n\n\n\n
                                  53. Readiness checklist<\/h1>\n\n\n\n
                                  You are ready for trunk-based development when:<\/p>\n\n\n
                                  - CI is reliable.\n- CI is fast enough.\n- Tests catch<\/span> important failures.\n- Developers can make small PRs.\n- Feature flags are available.\n- Main branch is protected<\/span>.\n- Rollback is known.\n- Production has observability.\n- Team can review quickly.\n- Database changes are backward compatible.\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
                                  You are not ready when:<\/p>\n\n\n
                                  - CI is flaky.\n- Tests are weak.\n- PRs are huge.\n- Developers keep branches for weeks.\n- No feature flag system exists.\n- Main breaks often.\n- Rollback is manual panic.\n- Production monitoring is weak.\n<\/code><\/span><\/pre>\n\n\n
                                  \n\n\n\n
                                  54. Trunk-based anti-patterns<\/h1>\n\n\n\n
                                  Anti-pattern 1: Everyone pushes broken code to main<\/h2>\n\n\n\n
                                  That is not trunk-based development.<\/p>\n\n\n\n
                                  Fix:<\/p>\n\n\n
                                  protect main\nrequire<\/span> CI\nrequire<\/span> review or pair programming\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                                  \n\n\n\n
                                  Anti-pattern 2: Short-lived branches become long-lived branches<\/h2>\n\n\n\n
                                  Problem:<\/p>\n\n\n
                                  feature\/big-refactor lives for 6 weeks\n<\/code><\/span><\/pre>\n\n\n
                                  Fix:<\/p>\n\n\n
                                  split work\nuse<\/span> feature<\/span> flags<\/span>\nuse<\/span> branch<\/span> by<\/span> abstraction<\/span>\nmerge<\/span> small<\/span> slices<\/span>\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
                                  \n\n\n\n
                                  Anti-pattern 3: Feature flags never get removed<\/h2>\n\n\n\n
                                  Problem:<\/p>\n\n\n
                                  hundreds of flags\nnobody knows which are active\n<\/code><\/span><\/pre>\n\n\n
                                  Fix:<\/p>\n\n\n
                                  owner\nexpiry date\ncleanup ticket\nflag dashboard\nregular cleanup\n<\/code><\/span><\/pre>\n\n\n
                                  \n\n\n\n
                                  Anti-pattern 4: CI is too slow<\/h2>\n\n\n\n
                                  Problem:<\/p>\n\n\n
                                  developers batch changes because feedback takes too long\n<\/code><\/span><\/pre>\n\n\n
                                  Fix:<\/p>\n\n\n
                                  parallelize tests\ncache dependencies\nsplit fast and deep CI\nrun targeted tests\nremove flaky tests from<\/span> merge gate only with<\/span> owner\/deadline\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                                  \n\n\n\n
                                  Anti-pattern 5: Big bang release from trunk<\/h2>\n\n\n\n
                                  Problem:<\/p>\n\n\n
                                  many hidden features enabled at once\n<\/code><\/span><\/pre>\n\n\n
                                  Fix:<\/p>\n\n\n
                                  progressive rollout\ncanary\nfeature flags\nsmall releases\n<\/code><\/span><\/pre>\n\n\n
                                  \n\n\n\n
                                  Anti-pattern 6: Database changes break rolling deploys<\/h2>\n\n\n\n
                                  Problem:<\/p>\n\n\n
                                  new<\/span> code requires new<\/span> schema immediately\nold pods still running\ndeployment fails\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                                  Fix:<\/p>\n\n\n
                                  expand-migrate-contract\nbackward-compatible migrations\nsafe rollout\n<\/code><\/span><\/pre>\n\n\n
                                  \n\n\n\n
                                  55. Trunk-based development metrics<\/h1>\n\n\n\n
                                  Measure the system.<\/p>\n\n\n\n
                                  Metric<\/th>Why it matters<\/th><\/tr><\/thead>
                                  branch age<\/td>integration delay<\/td><\/tr>
                                  PR size<\/td>review quality<\/td><\/tr>
                                  PR cycle time<\/td>flow speed<\/td><\/tr>
                                  CI duration<\/td>feedback speed<\/td><\/tr>
                                  CI failure rate<\/td>quality signal<\/td><\/tr>
                                  flaky test rate<\/td>pipeline trust<\/td><\/tr>
                                  main branch health<\/td>trunk stability<\/td><\/tr>
                                  deployment frequency<\/td>delivery flow<\/td><\/tr>
                                  change failure rate<\/td>production risk<\/td><\/tr>
                                  rollback time<\/td>recovery strength<\/td><\/tr>
                                  feature flag age<\/td>flag debt<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                                  Healthy signals:<\/p>\n\n\n
                                  branches live hours\/days\nPRs are small\nmain is usually green\nCI is trusted\nrollbacks are fast\nfeature flags are removed\ndeployments are routine\n<\/code><\/span><\/pre>\n\n\n
                                  \n\n\n\n
                                  56. Practical examples<\/h1>\n\n\n\n
                                  Example 1: small bug fix<\/h2>\n\n\n
                                  git checkout main\ngit pull --ff-only origin main\ngit checkout -b bugfix\/clear-login-error\n\n# edit<\/span>\nmake test\n\ngit add .\ngit commit -m \"fix(auth): show clear login error\"<\/span>\ngit push -u origin bugfix\/clear-login-error\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
                                  Merge same day.<\/p>\n\n\n\n
                                  \n\n\n\n
                                  Example 2: incomplete feature with flag<\/h2>\n\n\n
                                  git checkout main\ngit pull --ff-only origin main\ngit checkout -b feature\/payment-retry-flag\n<\/code><\/span><\/pre>\n\n\n
                                  Code:<\/p>\n\n\n
                                  if<\/span> payment_retry_enabled:\n    retry_gateway_timeout()\nelse<\/span>:\n    current_payment_flow()\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
                                  Commit:<\/p>\n\n\n
                                  git commit -m \"feat(payment): add retry flow behind feature flag\"<\/span>\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                                  Deploy with flag off. Enable gradually later.<\/p>\n\n\n\n
                                  \n\n\n\n
                                  Example 3: large refactor using branch by abstraction<\/h2>\n\n\n
                                  PR 1<\/span>: introduce interface\nPR 2<\/span>: route old implementation through interface\nPR 3<\/span>: add new<\/span> implementation behind flag\nPR 4<\/span>: migrate one caller\nPR 5<\/span>: migrate remaining callers\nPR 6<\/span>: remove old implementation\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                                  No giant branch. No merge war. No \u201csee you in six weeks\u201d energy.<\/p>\n\n\n\n
                                  \n\n\n\n
                                  57. Trunk-based development for teams: operating model<\/h1>\n\n\n\n
                                  Developer<\/h2>\n\n\n\n
                                    \n
                                  • makes small changes<\/li>\n\n\n\n
                                  • keeps branch fresh<\/li>\n\n\n\n
                                  • writes tests<\/li>\n\n\n\n
                                  • uses feature flags<\/li>\n\n\n\n
                                  • opens small PRs<\/li>\n\n\n\n
                                  • merges quickly<\/li>\n<\/ul>\n\n\n\n
                                    Reviewer<\/h2>\n\n\n\n
                                      \n
                                    • reviews quickly<\/li>\n\n\n\n
                                    • focuses on correctness\/risk<\/li>\n\n\n\n
                                    • encourages smaller PRs<\/li>\n\n\n\n
                                    • checks rollback<\/li>\n\n\n\n
                                    • blocks unsafe trunk changes<\/li>\n<\/ul>\n\n\n\n
                                      Tech lead<\/h2>\n\n\n\n
                                        \n
                                      • watches trunk health<\/li>\n\n\n\n
                                      • splits large work<\/li>\n\n\n\n
                                      • enforces flag cleanup<\/li>\n\n\n\n
                                      • improves CI reliability<\/li>\n\n\n\n
                                      • guides migration patterns<\/li>\n<\/ul>\n\n\n\n
                                        DevOps\/platform<\/h2>\n\n\n\n
                                          \n
                                        • keeps CI fast<\/li>\n\n\n\n
                                        • enforces branch protection<\/li>\n\n\n\n
                                        • provides deployment safety<\/li>\n\n\n\n
                                        • enables observability<\/li>\n\n\n\n
                                        • automates rollback<\/li>\n<\/ul>\n\n\n\n
                                          Product<\/h2>\n\n\n\n
                                            \n
                                          • accepts incremental delivery<\/li>\n\n\n\n
                                          • uses feature flags for release timing<\/li>\n\n\n\n
                                          • avoids forcing giant branches<\/li>\n\n\n\n
                                          • helps define rollout phases<\/li>\n<\/ul>\n\n\n\n
                                            \n\n\n\n
                                            58. Trunk-based development decision tree<\/h1>\n\n\n
                                            flowchart TD\n    A[Should we use<\/span> trunk<\/span>-based<\/span> development<\/span>?] --> B<\/span>{Can<\/span> main<\/span> be<\/span> protected<\/span> and<\/span> kept<\/span> green<\/span>?}\n    B<\/span> -- No<\/span> --> C<\/span>[Improve<\/span> CI<\/span> and<\/span> branch<\/span> protection<\/span> first<\/span>]\n    B<\/span> -- Yes<\/span> --> D<\/span>{Can<\/span> changes<\/span> be<\/span> small<\/span>?}\n    D<\/span> -- No<\/span> --> E<\/span>[Introduce<\/span> slicing<\/span> and<\/span> branch<\/span> by<\/span> abstraction<\/span>]\n    D<\/span> -- Yes<\/span> --> F<\/span>{Do<\/span> we<\/span> have<\/span> feature<\/span> flags<\/span>?}\n    F<\/span> -- No<\/span> --> G<\/span>[Use<\/span> short<\/span> branches<\/span> carefully<\/span> and<\/span> add<\/span> flags<\/span>]\n    F<\/span> -- Yes<\/span> --> H<\/span>{Can<\/span> we<\/span> rollback<\/span> quickly<\/span>?}\n    H<\/span> -- No<\/span> --> I<\/span>[Improve<\/span> rollback<\/span> and<\/span> observability<\/span>]\n    H<\/span> -- Yes<\/span> --> J<\/span>[Use<\/span> trunk<\/span>-based<\/span> development<\/span>]\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
                                            \n\n\n\n
                                            59. One-page trunk-based standard<\/h1>\n\n\n
                                            Trunk-Based Development Standard\n\nBranch model:\n- main is the trunk.\n- short-lived branches are allowed.\n- long-lived feature branches are not allowed.\n- release branches are optional and short-lived.\n\nRules:\n- main must always be healthy.\n- all changes are small.\n- all changes pass CI.\n- incomplete features use feature flags.\n- branches merge within hours or days.\n- production releases are traceable.\n- rollback is planned.\n- feature flags are removed after rollout.\n- stale branches are deleted.\n\nMerge policy:\n- squash merge by default<\/span>.\n- rebase local branches only.\n- no force push to main.\n- revert instead of<\/span> rewriting shared history.\n\nRelease policy:\n- build from<\/span> main.\n- promote immutable artifacts.\n- use flags\/canary\/rolling rollout.\n- tag releases when needed.\n- monitor after deployment.\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                                            \n\n\n\n
                                            60. Final wisdom<\/h1>\n\n\n\n
                                            A beginner thinks trunk-based development means:<\/p>\n\n\n
                                            Everyone commits to main.\n<\/code><\/span><\/pre>\n\n\n
                                            A senior engineer knows it means:<\/p>\n\n\n
                                            Everyone integrates safely and frequently.\n<\/code><\/span><\/pre>\n\n\n
                                            An architect knows it means:<\/p>\n\n\n
                                            A delivery system built around small changes, fast feedback, automation, feature flags, rollback, and continuous learning.\n<\/code><\/span><\/pre>\n\n\n
                                            Trunk-based development is not a shortcut.<\/p>\n\n\n\n
                                            It is discipline.<\/p>\n\n\n\n
                                            It removes branch complexity and replaces it with engineering maturity:<\/p>\n\n\n
                                            small batches\nfast CI\nstrong tests\nfeature flags\nprotected<\/span> main\nsafe rollout\nquick rollback\nobservability\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
                                            Final principle:<\/p>\n\n\n
                                            Trunk-based development is not about having fewer branches.\nIt is about having fewer delayed problems.\n<\/code><\/span><\/pre>\n\n\n
                                            When done badly, it breaks main.<\/p>\n\n\n\n
                                            When done well, it becomes one of the strongest foundations for continuous delivery.<\/p>\n","protected":false},"excerpt":{"rendered":"
                                            From Beginner to Advanced: A Complete One-Stop Guide to Fast, Safe, Continuous Software Delivery 1. What is trunk-based development? Trunk-based development, often shortened as TBD, is a… <\/p>\n","protected":false},"author":1,"featured_media":77521,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_joinchat":[],"footnotes":""},"categories":[11138],"tags":[],"class_list":["post-77520","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-best-tools"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/77520","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/comments?post=77520"}],"version-history":[{"count":1,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/77520\/revisions"}],"predecessor-version":[{"id":77522,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/77520\/revisions\/77522"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/media\/77521"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/media?parent=77520"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/categories?post=77520"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/tags?post=77520"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}