{"id":77517,"date":"2026-07-07T04:12:35","date_gmt":"2026-07-07T04:12:35","guid":{"rendered":"https:\/\/www.devopsschool.com\/blog\/?p=77517"},"modified":"2026-07-07T04:12:38","modified_gmt":"2026-07-07T04:12:38","slug":"gitflow-master-tutorial","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/blog\/gitflow-master-tutorial\/","title":{"rendered":"Gitflow Master Tutorial"},"content":{"rendered":"\n

From Basic to Advanced: A Complete One-Stop Guide to Gitflow Branching, Releases, Hotfixes, CI\/CD, and Governance<\/h2>\n\n\n\n
\n\n\n\n

1. What is Gitflow?<\/h1>\n\n\n\n

Gitflow<\/strong> is a structured Git branching model designed for teams that release software in planned versions.<\/p>\n\n\n\n

It uses several branch types, each with a specific job:<\/p>\n\n\n

main \/ master\ndevelop\nfeature\/*\nrelease\/*\nhotfix\/*\nsupport\/* optional\n<\/code><\/span><\/pre>\n\n\n
In simple words:<\/p>\n\n\n\n
\n
Gitflow is a release-focused branching strategy.<\/strong><\/p>\n<\/blockquote>\n\n\n\n
It is especially useful when a team needs:<\/p>\n\n\n\n
    \n
  • scheduled releases<\/li>\n\n\n\n
  • release stabilization<\/li>\n\n\n\n
  • hotfix handling<\/li>\n\n\n\n
  • version tags<\/li>\n\n\n\n
  • support for older versions<\/li>\n\n\n\n
  • QA cycles<\/li>\n\n\n\n
  • approval gates<\/li>\n\n\n\n
  • controlled production delivery<\/li>\n<\/ul>\n\n\n\n
    The original Gitflow model was introduced by Vincent Driessen in 2010 as a branching strategy for developing and releasing version-based software. In his later 2020 note, he warned that teams should not treat Gitflow as a universal standard or dogma, and specifically suggested simpler workflows for continuously delivered web apps.<\/p>\n\n\n\n
    \n\n\n\n
    2. The simplest mental model<\/h1>\n\n\n\n
    Gitflow separates software work into five lanes:<\/p>\n\n\n
    feature work     \u2192 feature\/*\nintegration      \u2192 develop\nrelease prep     \u2192 release\/*\nproduction       \u2192 main\nemergency repair \u2192 hotfix\/*\n<\/code><\/span><\/pre>\n\n
    flowchart<\/span> LR<\/span>\n    A<\/span>[feature\/*]<\/span> --<\/span>> B<\/span>[develop]<\/span>\n    B<\/span> --<\/span>> C<\/span>[release\/*]<\/span>\n    C<\/span> --<\/span>> D<\/span>[main \/ production]<\/span>\n    D<\/span> --<\/span>> E<\/span>[hotfix\/*]<\/span>\n    E<\/span> --<\/span>> D<\/span>\n    E<\/span> --<\/span>> B<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
    The core idea:<\/p>\n\n\n\n
    \n
    Developers can continue building the next version while another branch is being stabilized for release.<\/p>\n<\/blockquote>\n\n\n\n
    That is the magic of Gitflow.<\/p>\n\n\n\n
    \n\n\n\n
    3. Why Gitflow exists<\/h1>\n\n\n\n
    Without Gitflow, teams often struggle with this problem:<\/p>\n\n\n
    Some developers are building future features.\nQA wants to test the next release.\nProduction has a critical bug.\nCustomers still need old versions supported.\n<\/code><\/span><\/pre>\n\n\n
    Gitflow gives each problem a separate branch lane.<\/p>\n\n\n\n
    Problem<\/th>Gitflow solution<\/th><\/tr><\/thead>
    New feature work<\/td>feature\/*<\/code><\/td><\/tr>
    Shared next-release integration<\/td>develop<\/code><\/td><\/tr>
    Release testing and stabilization<\/td>release\/*<\/code><\/td><\/tr>
    Production-ready history<\/td>main<\/code> \/ master<\/code><\/td><\/tr>
    Emergency production fix<\/td>hotfix\/*<\/code><\/td><\/tr>
    Older version maintenance<\/td>support\/*<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
    AWS describes Gitflow as a model that uses multiple branches to move code from development to production, and says it works well for scheduled release cycles where a collection of features is grouped into a release.<\/p>\n\n\n\n
    \n\n\n\n
    4. Gitflow is not just \u201cmore branches\u201d<\/h1>\n\n\n\n
    Bad understanding:<\/p>\n\n\n
    Gitflow = create many branches\n<\/code><\/span><\/pre>\n\n\n
    Correct understanding:<\/p>\n\n\n
    Gitflow = separate development, release stabilization, production, and hotfix work\n<\/code><\/span><\/pre>\n\n\n
    A branch in Gitflow must have a clear purpose.<\/p>\n\n\n
    flowchart TD\n    A[Need a branch?] --> B{What is the purpose?}\n    B -- New<\/span> feature --> C[feature\/*]\n    B -- Integrate next release --> D[develop]\n    B -- Stabilize release --> E[release\/*]\n    B -- Production code --> F[main]\n    B -- Emergency fix --> G[hotfix\/*]\n    B -- Old version support --> H[support\/*]\n    B -- No clear purpose --> I[Do not create branch]\n<\/span><\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
    \n\n\n\n
    5. The full Gitflow branch family<\/h1>\n\n\n
    gitGraph\n    commit id: \"v1.0.0\"<\/span>\n    branch develop\n    checkout develop\n    commit id: \"dev work\"<\/span>\n    branch feature\/login\n    checkout feature\/login\n    commit id: \"login 1\"<\/span>\n    commit id: \"login 2\"<\/span>\n    checkout develop\n    merge feature\/login\n    branch release\/1.1<\/span>.0<\/span>\n    checkout release\/1.1<\/span>.0<\/span>\n    commit id: \"release fix\"<\/span>\n    checkout main\n    merge release\/1.1<\/span>.0<\/span> tag: \"v1.1.0\"<\/span>\n    checkout develop\n    merge release\/1.1<\/span>.0<\/span>\n    checkout main\n    branch hotfix\/1.1<\/span>.1<\/span>\n    checkout hotfix\/1.1<\/span>.1<\/span>\n    commit id: \"prod fix\"<\/span>\n    checkout main\n    merge hotfix\/1.1<\/span>.1<\/span> tag: \"v1.1.1\"<\/span>\n    checkout develop\n    merge hotfix\/1.1<\/span>.1<\/span>\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
    \n\n\n\n
    6. Main branches in Gitflow<\/h1>\n\n\n\n
    Gitflow has two long-lived primary branches:<\/p>\n\n\n
    main \/ master\ndevelop\n<\/code><\/span><\/pre>\n\n\n
    The original Gitflow model used master<\/code>; modern teams often rename it to main<\/code>.<\/p>\n\n\n\n
    6.1 main<\/code> branch<\/h2>\n\n\n\n
    The main<\/code> branch represents production-ready code.<\/p>\n\n\n
    main = production history\n<\/code><\/span><\/pre>\n\n\n
    Rules:<\/p>\n\n\n\n
      \n
    • Every commit on main<\/code> should represent a production release or production-ready state.<\/li>\n\n\n\n
    • Releases are tagged on main<\/code>.<\/li>\n\n\n\n
    • Direct pushes should be blocked.<\/li>\n\n\n\n
    • Only release branches and hotfix branches merge into main<\/code>.<\/li>\n<\/ul>\n\n\n\n
      Vincent Driessen\u2019s original model defines origin\/master<\/code> as the branch where HEAD<\/code> always reflects a production-ready state; in modern naming, this is usually origin\/main<\/code>.<\/p>\n\n\n\n
      \n\n\n\n
      6.2 develop<\/code> branch<\/h2>\n\n\n\n
      The develop<\/code> branch is the integration branch for the next release.<\/p>\n\n\n
      develop = next release integration\n<\/code><\/span><\/pre>\n\n\n
      Rules:<\/p>\n\n\n\n
        \n
      • Feature branches merge into develop<\/code>.<\/li>\n\n\n\n
      • develop<\/code> should be stable enough for integration testing.<\/li>\n\n\n\n
      • When develop<\/code> has enough features for a release, create a release\/*<\/code> branch.<\/li>\n\n\n\n
      • Hotfixes from production must eventually flow back into develop<\/code>.<\/li>\n<\/ul>\n\n\n\n
        The original model describes develop<\/code> as the branch where the latest delivered development changes for the next release are integrated.<\/p>\n\n\n\n
        \n\n\n\n
        7. Supporting branches in Gitflow<\/h1>\n\n\n\n
        Gitflow uses short-lived supporting branches.<\/p>\n\n\n
        feature\/*\nrelease\/*\nhotfix\/*\nsupport\/* optional\n<\/code><\/span><\/pre>\n\n\n
        Vincent Driessen\u2019s original Gitflow article defines feature, release, and hotfix branches as supporting branches with limited lifetimes and strict rules about where they start and where they merge.<\/p>\n\n\n\n
        \n\n\n\n
        8. Gitflow branch responsibility table<\/h1>\n\n\n\n
        Branch<\/th>Starts from<\/th>Merges into<\/th>Lifetime<\/th>Purpose<\/th><\/tr><\/thead>
        main<\/code><\/td>none<\/td>none directly<\/td>permanent<\/td>production-ready releases<\/td><\/tr>
        develop<\/code><\/td>main<\/code> initially<\/td>release\/hotfix merges back<\/td>permanent<\/td>next release integration<\/td><\/tr>
        feature\/*<\/code><\/td>develop<\/code><\/td>develop<\/code><\/td>short<\/td>build new features<\/td><\/tr>
        release\/*<\/code><\/td>develop<\/code><\/td>main<\/code> and develop<\/code><\/td>temporary<\/td>stabilize release<\/td><\/tr>
        hotfix\/*<\/code><\/td>main<\/code><\/td>main<\/code> and develop<\/code><\/td>very short<\/td>fix production urgently<\/td><\/tr>
        support\/*<\/code><\/td>release tag \/ main<\/code><\/td>depends<\/td>long<\/td>maintain old versions<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
        \n\n\n\n
        9. Gitflow branch naming standard<\/h1>\n\n\n\n
        Recommended naming<\/h2>\n\n\n
        feature\/<ticket<\/span>><\/span>-<short-description<\/span>><\/span>\nrelease\/<version<\/span>><\/span>\nhotfix\/<version<\/span>><\/span>-<short-description<\/span>><\/span>\nsupport\/<version-or-line<\/span>><\/span>\n<\/code><\/span>Code language:<\/span> HTML, XML<\/span> (<\/span>xml<\/span>)<\/span><\/small><\/pre>\n\n\n
        Examples<\/h2>\n\n\n
        feature\/EVP-123-add-device-search\nfeature\/EVP-140-payment-retry\nrelease\/2.4.0\nrelease\/mobile-5.1.0\nhotfix\/2.4.1-login-crash\nhotfix\/2.4.2-security-token-rotation\nsupport\/1.9-lts\nsupport\/2.x\n<\/code><\/span><\/pre>\n\n\n
        Avoid<\/h2>\n\n\n
        my-branch\ntest\nfinal<\/span>\nnew<\/span>\nfix\nrajesh-work\nrelease-latest\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
        Good branch names should explain purpose before anyone opens the code.<\/p>\n\n\n\n
        \n\n\n\n
        10. Gitflow lifecycle overview<\/h1>\n\n\n
        flowchart TD\n    A[Start from<\/span> develop] --> B[Create feature branch]\n    B --> C[Develop feature]\n    C --> D[Merge feature into develop]\n    D --> E{Enough features for<\/span> release?}\n    E -- No --> B\n    E -- Yes --> F[Create release branch]\n    F --> G[QA \/ bug fixes \/ version bump]\n    G --> H[Merge release into main]\n    H --> I[Tag version]\n    I --> J[Merge release back into develop]\n    J --> K[Delete release branch]\n    H --> L{Production issue?}\n    L -- Yes --> M[Create hotfix from<\/span> main]\n    M --> N[Fix and test]\n    N --> O[Merge hotfix into main]\n    O --> P[Tag patch version]\n    P --> Q[Merge hotfix into develop]\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
        \n\n\n\n
        11. Step 1: Initialize a Gitflow-style repository<\/h1>\n\n\n\n
        Start with main<\/code>.<\/p>\n\n\n
        git init\ngit checkout -b main\necho<\/span> \"# My Project\"<\/span> > README.md\ngit add README.md\ngit commit -m \"chore: initial commit\"<\/span>\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
        Create develop<\/code>.<\/p>\n\n\n
        git checkout -b develop\ngit push -u origin main\ngit push -u origin develop\n<\/code><\/span><\/pre>\n\n\n
        Now your repository has:<\/p>\n\n\n
        main\ndevelop\n<\/code><\/span><\/pre>\n\n\n
        \n\n\n\n
        12. Step 2: Feature branch workflow<\/h1>\n\n\n\n
        Feature branches are created from develop<\/code>.<\/p>\n\n\n
        flowchart<\/span> LR<\/span>\n    A<\/span>[develop]<\/span> --<\/span>> B<\/span>[feature\/add-login]<\/span>\n    B<\/span> --<\/span>> C<\/span>[work + commits]<\/span>\n    C<\/span> --<\/span>> D<\/span>[pull request]<\/span>\n    D<\/span> --<\/span>> E<\/span>[merge into develop]<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
        Create a feature branch<\/h2>\n\n\n
        git checkout develop\ngit pull --ff-only origin develop\ngit checkout -b feature\/EVP-123-add-login\n<\/code><\/span><\/pre>\n\n\n
        Work and commit<\/h2>\n\n\n
        git add .\ngit commit -m \"feat(auth): add login endpoint\"<\/span>\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
        Push feature branch<\/h2>\n\n\n
        git push -u origin feature\/EVP-123-add-login\n<\/code><\/span><\/pre>\n\n\n
        Merge feature into develop<\/code><\/h2>\n\n\n\n
        Option A: via pull request \/ merge request.<\/p>\n\n\n\n
        Option B: command line.<\/p>\n\n\n
        git checkout develop\ngit pull --ff-only origin develop\ngit merge --no-ff feature\/EVP-123-add-login\ngit push origin develop\n<\/code><\/span><\/pre>\n\n\n
        The original Gitflow article uses --no-ff<\/code> when merging finished feature branches into develop<\/code> so the historical existence of the feature branch remains visible.<\/p>\n\n\n\n
        Delete feature branch<\/h2>\n\n\n
        git branch -d feature\/EVP-123<\/span>-add-login\ngit push origin --delete<\/span> feature\/EVP-123<\/span>-add-login\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
        \n\n\n\n
        13. Feature branch rules<\/h1>\n\n\n\n
        Feature branches should:<\/p>\n\n\n\n
          \n
        • start from develop<\/code><\/li>\n\n\n\n
        • be short-lived<\/li>\n\n\n\n
        • contain one feature or one logical change<\/li>\n\n\n\n
        • be reviewed before merging<\/li>\n\n\n\n
        • pass CI before merging<\/li>\n\n\n\n
        • merge only into develop<\/code><\/li>\n\n\n\n
        • be deleted after merge<\/li>\n<\/ul>\n\n\n\n
          Feature branches should not:<\/p>\n\n\n\n
            \n
          • start from main<\/code><\/li>\n\n\n\n
          • merge directly into main<\/code><\/li>\n\n\n\n
          • include multiple unrelated features<\/li>\n\n\n\n
          • live for months<\/li>\n\n\n\n
          • contain production hotfixes<\/li>\n\n\n\n
          • contain release-only version bumps<\/li>\n<\/ul>\n\n\n\n
            \n\n\n\n
            14. Step 3: Release branch workflow<\/h1>\n\n\n\n
            A release branch is created from develop<\/code> when the team decides that the next release has enough features.<\/p>\n\n\n
            flowchart<\/span> TD<\/span>\n    A<\/span>[develop]<\/span> --<\/span>> B<\/span>[release\/2.4.0]<\/span>\n    B<\/span> --<\/span>> C<\/span>[QA testing]<\/span>\n    C<\/span> --<\/span>> D<\/span>[Bug fixes only]<\/span>\n    D<\/span> --<\/span>> E<\/span>[Version bump \/ release notes]<\/span>\n    E<\/span> --<\/span>> F<\/span>[Merge to main]<\/span>\n    F<\/span> --<\/span>> G<\/span>[Tag v2.4.0]<\/span>\n    B<\/span> --<\/span>> H<\/span>[Merge back to develop]<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
            Create a release branch<\/h2>\n\n\n
            git checkout develop\ngit pull --ff-only origin develop\ngit checkout -b release\/2.4.0\ngit push -u origin release\/2.4.0\n<\/code><\/span><\/pre>\n\n\n
            Bump version<\/h2>\n\n\n\n
            Example file:<\/p>\n\n\n
            VERSION=2.4.0\n<\/code><\/span><\/pre>\n\n\n
            Commit:<\/p>\n\n\n
            git add VERSION\ngit commit -m \"chore(release): bump version to 2.4.0\"<\/span>\ngit push origin release\/2.4<\/span>.0<\/span>\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
            Fix release bugs<\/h2>\n\n\n
            git add .\ngit commit -m \"fix(release): correct payment retry configuration\"<\/span>\ngit push origin release\/2.4<\/span>.0<\/span>\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
            Finish release<\/h2>\n\n\n\n
            Merge into main<\/code>.<\/p>\n\n\n
            git checkout main\ngit pull --ff-only origin main\ngit merge --no-ff release\/2.4<\/span>.0<\/span>\ngit tag -a v2.4<\/span>.0<\/span> -m \"Release v2.4.0\"<\/span>\ngit push origin main v2.4<\/span>.0<\/span>\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
            Merge back into develop<\/code>.<\/p>\n\n\n
            git checkout develop\ngit pull --ff-only origin develop\ngit merge --no-ff release\/2.4.0\ngit push origin develop\n<\/code><\/span><\/pre>\n\n\n
            Delete release branch.<\/p>\n\n\n
            git branch -d release\/2.4<\/span>.0<\/span>\ngit push origin --delete<\/span> release\/2.4<\/span>.0<\/span>\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
            The original Gitflow model says release branches start from develop<\/code>, merge back into both main<\/code> and develop<\/code>, and are used for final release preparation such as minor bug fixes and release metadata.<\/p>\n\n\n\n
            \n\n\n\n
            15. Release branch rules<\/h1>\n\n\n\n
            Allowed on release\/*<\/code>:<\/p>\n\n\n
            bug fixes\nversion bump\nrelease notes\ndocumentation correction\nsafe configuration correction\ntest fixes related to release\n<\/code><\/span><\/pre>\n\n\n
            Not allowed on release\/*<\/code>:<\/p>\n\n\n
            new<\/span> features\nlarge refactors\nexperimental work\nunrelated cleanup\nrisky dependency upgrades\nmajor architecture changes\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
            Important rule:<\/p>\n\n\n\n
            \n
            A release branch is for stabilization, not innovation.<\/p>\n<\/blockquote>\n\n\n\n
            \n\n\n\n
            16. Step 4: Hotfix branch workflow<\/h1>\n\n\n\n
            A hotfix branch is created when production is broken and cannot wait for the next scheduled release.<\/p>\n\n\n
            flowchart<\/span> TD<\/span>\n    A<\/span>[Production issue]<\/span> --<\/span>> B<\/span>[Create hotfix from main]<\/span>\n    B<\/span> --<\/span>> C<\/span>[Fix issue]<\/span>\n    C<\/span> --<\/span>> D<\/span>[Test]<\/span>\n    D<\/span> --<\/span>> E<\/span>[Merge into main]<\/span>\n    E<\/span> --<\/span>> F<\/span>[Tag patch release]<\/span>\n    F<\/span> --<\/span>> G<\/span>[Merge into develop]<\/span>\n    G<\/span> --<\/span>> H<\/span>[Delete hotfix branch]<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
            Create hotfix branch<\/h2>\n\n\n
            git checkout main\ngit pull --ff-only origin main\ngit checkout -b hotfix\/2.4.1-login-crash\n<\/code><\/span><\/pre>\n\n\n
            Bump patch version<\/h2>\n\n\n
            echo<\/span> \"2.4<\/span>.1<\/span>\" > VERSION<\/span>\ngit<\/span> add<\/span> VERSION<\/span>\ngit<\/span> commit<\/span> -m<\/span> \"chore<\/span>(hotfix<\/span>): bump<\/span> version<\/span> to<\/span> 2.4<\/span>.1<\/span>\"\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
            Fix production bug<\/h2>\n\n\n
            git add .\ngit commit -m \"fix(auth): prevent crash on expired login token\"<\/span>\ngit push -u origin hotfix\/2.4<\/span>.1<\/span>-login-crash\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
            Finish hotfix<\/h2>\n\n\n\n
            Merge into main<\/code>.<\/p>\n\n\n
            git checkout main\ngit pull --ff-only origin main\ngit merge --no-ff hotfix\/2.4<\/span>.1<\/span>-login-crash\ngit tag -a v2.4<\/span>.1<\/span> -m \"Hotfix v2.4.1\"<\/span>\ngit push origin main v2.4<\/span>.1<\/span>\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
            Merge into develop<\/code>.<\/p>\n\n\n
            git checkout develop\ngit pull --ff-only origin develop\ngit merge --no-ff hotfix\/2.4.1-login-crash\ngit push origin develop\n<\/code><\/span><\/pre>\n\n\n
            Delete branch.<\/p>\n\n\n
            git branch -d hotfix\/2.4<\/span>.1<\/span>-login-crash\ngit push origin --delete<\/span> hotfix\/2.4<\/span>.1<\/span>-login-crash\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
            In the original model, hotfix branches start from master<\/code>\/main<\/code> and must merge back into both master<\/code>\/main<\/code> and develop<\/code>; if a release branch currently exists, the hotfix should also be merged into that release branch so the release includes the fix.<\/p>\n\n\n\n
            \n\n\n\n
            17. Hotfix branch rules<\/h1>\n\n\n\n
            Hotfix branches should:<\/p>\n\n\n\n
              \n
            • start from main<\/code> or the production tag<\/li>\n\n\n\n
            • fix only the production issue<\/li>\n\n\n\n
            • be small<\/li>\n\n\n\n
            • be reviewed quickly<\/li>\n\n\n\n
            • run critical tests<\/li>\n\n\n\n
            • merge into main<\/code><\/li>\n\n\n\n
            • be tagged as a patch release<\/li>\n\n\n\n
            • merge back into develop<\/code><\/li>\n\n\n\n
            • merge into active release\/*<\/code> branch if one exists<\/li>\n<\/ul>\n\n\n\n
              Hotfix branches should not:<\/p>\n\n\n\n
                \n
              • include new features<\/li>\n\n\n\n
              • include refactoring<\/li>\n\n\n\n
              • include broad dependency upgrades<\/li>\n\n\n\n
              • include unrelated cleanup<\/li>\n\n\n\n
              • bypass source control<\/li>\n\n\n\n
              • remain open after deployment<\/li>\n<\/ul>\n\n\n\n
                \n\n\n\n
                18. What if a release branch exists during hotfix?<\/h1>\n\n\n\n
                This is a common Gitflow confusion.<\/p>\n\n\n\n
                Situation:<\/p>\n\n\n
                main = production v2.4.0\ndevelop = future v2.6.0 work\nrelease\/2.5.0 = currently in QA\nproduction has critical bug\n<\/code><\/span><\/pre>\n\n\n
                Flow:<\/p>\n\n\n
                flowchart<\/span> TD<\/span>\n    A<\/span>[main]<\/span> --<\/span>> B<\/span>[hotfix\/2.4.1]<\/span>\n    B<\/span> --<\/span>> C<\/span>[merge to main]<\/span>\n    C<\/span> --<\/span>> D<\/span>[tag v2.4.1]<\/span>\n    B<\/span> --<\/span>> E<\/span>[merge to release\/2.5.0]<\/span>\n    E<\/span> --<\/span>> F<\/span>[eventually release branch merges to develop]<\/span>\n    B<\/span> --<\/span>> G<\/span>[optionally merge to develop immediately if needed]<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
                Practical rule:<\/p>\n\n\n
                Hotfix must reach every branch that still needs the fix.\n<\/code><\/span><\/pre>\n\n\n
                Usually:<\/p>\n\n\n\n
                  \n
                • merge hotfix into main<\/code><\/li>\n\n\n\n
                • merge hotfix into active release\/*<\/code><\/li>\n\n\n\n
                • merge hotfix into develop<\/code> now or via release branch later<\/li>\n<\/ul>\n\n\n\n
                  \n\n\n\n
                  19. Optional support branch workflow<\/h1>\n\n\n\n
                  Use support branches when older versions must be maintained.<\/p>\n\n\n
                  support\/1.9-lts\nsupport\/2.x\n<\/code><\/span><\/pre>\n\n
                  flowchart<\/span> LR<\/span>\n    A<\/span>[main latest]<\/span> --<\/span>> B<\/span>[support\/2.x]<\/span>\n    A<\/span> --<\/span>> C<\/span>[support\/1.9-lts]<\/span>\n    D<\/span>[security fix]<\/span> --<\/span>> B<\/span>\n    D<\/span> --<\/span>> C<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
                  Create support branch<\/h2>\n\n\n
                  git checkout v1.9.0\ngit checkout -b support\/1.9-lts\ngit push -u origin support\/1.9-lts\n<\/code><\/span><\/pre>\n\n\n
                  Backport fix<\/h2>\n\n\n
                  git checkout support\/1.9-lts\ngit cherry-pick <fix-commit-sha<\/span>><\/span>\ngit push origin support\/1.9-lts\n<\/code><\/span>Code language:<\/span> HTML, XML<\/span> (<\/span>xml<\/span>)<\/span><\/small><\/pre>\n\n\n
                  Tag support release<\/h2>\n\n\n
                  git<\/span> tag<\/span> -a<\/span> v1<\/span>.9<\/span>.7<\/span> -m<\/span> \"Support<\/span> release<\/span> v1<\/span>.9<\/span>.7<\/span>\"\ngit<\/span> push<\/span> origin<\/span> v1<\/span>.9<\/span>.7<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
                  Use support branches only when the product genuinely needs long-term maintenance for older versions.<\/p>\n\n\n\n
                  \n\n\n\n
                  20. Gitflow with Semantic Versioning<\/h1>\n\n\n\n
                  Gitflow works naturally with Semantic Versioning.<\/p>\n\n\n
                  MAJOR<\/span>.MINOR<\/span>.PATCH<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
                  Examples:<\/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
                  Semantic Versioning defines major versions for incompatible API changes, minor versions for backward-compatible functionality, and patch versions for backward-compatible bug fixes.<\/p>\n\n\n\n
                  Mapping Gitflow to SemVer<\/h2>\n\n\n\n
                  Gitflow action<\/th>Version effect<\/th><\/tr><\/thead>
                  feature merged into release<\/td>usually minor<\/td><\/tr>
                  bug fix in release branch<\/td>patch before release<\/td><\/tr>
                  hotfix from production<\/td>patch<\/td><\/tr>
                  breaking change<\/td>major<\/td><\/tr>
                  support branch fix<\/td>patch for old version<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                  Example:<\/p>\n\n\n
                  release\/2.4.0 \u2192 tag v2.4.0\nhotfix\/2.4.1-login-crash \u2192 tag v2.4.1\nsupport\/1.9-lts \u2192 tag v1.9.8\n<\/code><\/span><\/pre>\n\n\n
                  \n\n\n\n
                  21. Gitflow with Conventional Commits<\/h1>\n\n\n\n
                  Conventional Commits makes Gitflow cleaner because commit messages become meaningful for changelogs and release notes.<\/p>\n\n\n\n
                  Format:<\/p>\n\n\n
                  <type<\/span>><\/span>(optional-scope): <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
                  feat(auth)<\/span>: add OAuth login\nfix(payment)<\/span>: retry gateway timeout\nchore(release)<\/span>: bump version to 2.4.0\ndocs(runbook)<\/span>: add hotfix process\n<\/code><\/span>Code language:<\/span> HTTP<\/span> (<\/span>http<\/span>)<\/span><\/small><\/pre>\n\n\n
                  The Conventional Commits specification defines a lightweight structure for commit messages that gives human-readable and machine-readable meaning to commit history and aligns with SemVer concepts like features, fixes, and breaking changes.<\/p>\n\n\n\n
                  \n\n\n\n
                  22. Gitflow commit type guide<\/h1>\n\n\n\n
                  Type<\/th>Use in Gitflow<\/th>Example<\/th><\/tr><\/thead>
                  feat<\/code><\/td>feature branches<\/td>feat(auth): add SSO login<\/code><\/td><\/tr>
                  fix<\/code><\/td>bugfix, release, hotfix<\/td>fix(api): handle null vehicle id<\/code><\/td><\/tr>
                  chore<\/code><\/td>version bump, maintenance<\/td>chore(release): bump version<\/code><\/td><\/tr>
                  docs<\/code><\/td>documentation<\/td>docs: update release checklist<\/code><\/td><\/tr>
                  test<\/code><\/td>tests<\/td>test(payment): add retry tests<\/code><\/td><\/tr>
                  refactor<\/code><\/td>internal cleanup<\/td>refactor(auth): simplify token parser<\/code><\/td><\/tr>
                  perf<\/code><\/td>performance<\/td>perf(cache): reduce lookup latency<\/code><\/td><\/tr>
                  ci<\/code><\/td>pipeline changes<\/td>ci: add release branch workflow<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                  \n\n\n\n
                  23. Gitflow command cheat sheet<\/h1>\n\n\n\n
                  Create develop<\/code><\/h2>\n\n\n
                  git checkout main\ngit checkout -b develop\ngit push -u origin develop\n<\/code><\/span><\/pre>\n\n\n
                  Create feature<\/h2>\n\n\n
                  git checkout develop\ngit pull --ff-only origin develop\ngit checkout -b feature\/EVP-123-add-login\n<\/code><\/span><\/pre>\n\n\n
                  Finish feature<\/h2>\n\n\n
                  git checkout develop\ngit pull --ff-only origin develop\ngit merge --no-ff feature\/EVP-123<\/span>-add-login\ngit push origin develop\ngit branch -d feature\/EVP-123<\/span>-add-login\ngit push origin --delete<\/span> feature\/EVP-123<\/span>-add-login\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                  Create release<\/h2>\n\n\n
                  git checkout develop\ngit pull --ff-only origin develop\ngit checkout -b release\/2.4.0\ngit push -u origin release\/2.4.0\n<\/code><\/span><\/pre>\n\n\n
                  Finish release<\/h2>\n\n\n
                  git checkout main\ngit pull --ff-only origin main\ngit merge --no-ff release\/2.4<\/span>.0<\/span>\ngit tag -a v2.4<\/span>.0<\/span> -m \"Release v2.4.0\"<\/span>\ngit push origin main v2.4<\/span>.0<\/span>\n\ngit checkout develop\ngit pull --ff-only origin develop\ngit merge --no-ff release\/2.4<\/span>.0<\/span>\ngit push origin develop\n\ngit branch -d release\/2.4<\/span>.0<\/span>\ngit push origin --delete<\/span> release\/2.4<\/span>.0<\/span>\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                  Create hotfix<\/h2>\n\n\n
                  git checkout main\ngit pull --ff-only origin main\ngit checkout -b hotfix\/2.4.1-login-crash\n<\/code><\/span><\/pre>\n\n\n
                  Finish hotfix<\/h2>\n\n\n
                  git checkout main\ngit pull --ff-only origin main\ngit merge --no-ff hotfix\/2.4<\/span>.1<\/span>-login-crash\ngit tag -a v2.4<\/span>.1<\/span> -m \"Hotfix v2.4.1\"<\/span>\ngit push origin main v2.4<\/span>.1<\/span>\n\ngit checkout develop\ngit pull --ff-only origin develop\ngit merge --no-ff hotfix\/2.4<\/span>.1<\/span>-login-crash\ngit push origin develop\n\ngit branch -d hotfix\/2.4<\/span>.1<\/span>-login-crash\ngit push origin --delete<\/span> hotfix\/2.4<\/span>.1<\/span>-login-crash\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                  \n\n\n\n
                  24. Gitflow with pull requests<\/h1>\n\n\n\n
                  Traditional Gitflow can be done with command-line merges, but modern teams should use pull requests or merge requests.<\/p>\n\n\n\n
                  Recommended PR flow<\/h2>\n\n\n
                  flowchart<\/span> TD<\/span>\n    A<\/span>[feature\/*]<\/span> --<\/span>> B<\/span>[PR to develop]<\/span>\n    C<\/span>[release\/*]<\/span> --<\/span>> D<\/span>[PR to main]<\/span>\n    C<\/span> --<\/span>> E<\/span>[PR back to develop]<\/span>\n    F<\/span>[hotfix\/*]<\/span> --<\/span>> G<\/span>[PR to main]<\/span>\n    F<\/span> --<\/span>> H<\/span>[PR to develop]<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
                  PR targets<\/h2>\n\n\n\n
                  Source branch<\/th>Target branch<\/th>Purpose<\/th><\/tr><\/thead>
                  feature\/*<\/code><\/td>develop<\/code><\/td>add feature to next release<\/td><\/tr>
                  release\/*<\/code><\/td>main<\/code><\/td>publish release<\/td><\/tr>
                  release\/*<\/code><\/td>develop<\/code><\/td>return release fixes<\/td><\/tr>
                  hotfix\/*<\/code><\/td>main<\/code><\/td>fix production<\/td><\/tr>
                  hotfix\/*<\/code><\/td>develop<\/code><\/td>keep future release fixed<\/td><\/tr>
                  hotfix\/*<\/code><\/td>active release\/*<\/code><\/td>include fix in in-progress release<\/td><\/tr>
                  support\/*<\/code><\/td>support branch<\/td>patch old version<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                  \n\n\n\n
                  25. Gitflow PR template<\/h1>\n\n\n
                  ## Summary<\/span>\n\nExplain what changed.\n\n## Branch type<\/span>\n\n- [ ] feature\/*\n- [ ] release\/*\n- [ ] hotfix\/*\n- [ ] support\/*\n\n## Target branch\n\n- [ ] develop\n- [ ] main\n- [ ] release\/*\n- [ ] support\/*\n\n## Why\n\nExplain the reason for this change.\n\n## Changes\n\n- Added:\n- Changed:\n- Fixed:\n- Removed:\n\n## Testing\n\n- [ ] Unit tests\n- [ ] Integration tests\n- [ ] Regression tests\n- [ ] Manual validation\n- [ ] Staging validation\n\n## Release impact\n\n- Version:\n- Release branch:\n- Changelog updated:\n- Migration required:\n\n## Risk\n\nLow \/ Medium \/ High\n\n## Rollback plan\n\nExplain how to revert, redeploy, or disable the change.\n\n## Checklist\n\n- [ ] CI passed\n- [ ] Review completed\n- [ ] No secrets committed\n- [ ] Version updated if needed\n- [ ] Release notes updated if needed\n- [ ] Hotfix merged back to develop if needed\n<\/span><\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
                  \n\n\n\n
                  26. Gitflow CI\/CD design<\/h1>\n\n\n\n
                  Gitflow needs branch-aware CI\/CD.<\/p>\n\n\n
                  flowchart TD\n    A[Branch pushed] --> B{Branch type?}\n    B -- feature\/* --> C[Run lint, unit tests, build]\n    B -- develop --> D[Full CI + deploy integration\/dev]\n    B -- release\/* --> E[Full regression + deploy staging\/UAT]\n    B -- main --> F[Build production artifact + tag release]\n    B -- hotfix\/* --> G[Critical CI + emergency validation]\n    B -- support\/* --> H[Version-specific tests]\n<\/code><\/span><\/pre>\n\n\n
                  Recommended pipeline behavior<\/h2>\n\n\n\n
                  Branch<\/th>Pipeline behavior<\/th><\/tr><\/thead>
                  feature\/*<\/code><\/td>lint, unit test, build<\/td><\/tr>
                  develop<\/code><\/td>full CI, integration tests, deploy dev\/test<\/td><\/tr>
                  release\/*<\/code><\/td>full regression, security scan, deploy staging\/UAT<\/td><\/tr>
                  main<\/code><\/td>production release pipeline<\/td><\/tr>
                  hotfix\/*<\/code><\/td>critical tests, focused regression<\/td><\/tr>
                  support\/*<\/code><\/td>tests for old version compatibility<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                  \n\n\n\n
                  27. Gitflow environment mapping<\/h1>\n\n\n\n
                  A common Gitflow environment mapping:<\/p>\n\n\n
                  feature\/*  \u2192 no deployment or ephemeral env\ndevelop    \u2192 dev \/ integration\nrelease\/*  \u2192 staging \/ UAT\nmain       \u2192 production\nhotfix\/*   \u2192 emergency staging + production\n<\/code><\/span><\/pre>\n\n
                  flowchart<\/span> LR<\/span>\n    A<\/span>[feature\/*]<\/span> --<\/span>> B<\/span>[local \/ preview env]<\/span>\n    C<\/span>[develop]<\/span> --<\/span>> D<\/span>[dev \/ integration]<\/span>\n    E<\/span>[release\/*]<\/span> --<\/span>> F<\/span>[staging \/ UAT]<\/span>\n    G<\/span>[main]<\/span> --<\/span>> H<\/span>[production]<\/span>\n    I<\/span>[hotfix\/*]<\/span> --<\/span>> J<\/span>[emergency validation]<\/span>\n    J<\/span> --<\/span>> H<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
                  \n\n\n\n
                  28. Branch protection rules for Gitflow<\/h1>\n\n\n\n
                  Use branch protection to enforce Gitflow.<\/p>\n\n\n\n
                  GitHub branch protection rules can require approving reviews and passing status checks before merging into protected branches. They can also control deletion, force pushes, and other requirements for important branches.<\/p>\n\n\n\n
                  Recommended protections<\/h2>\n\n\n\n
                  Branch<\/th>Direct push<\/th>PR required<\/th>CI required<\/th>Review required<\/th>Force push<\/th><\/tr><\/thead>
                  main<\/code><\/td>no<\/td>yes<\/td>yes<\/td>yes<\/td>no<\/td><\/tr>
                  develop<\/code><\/td>no<\/td>yes<\/td>yes<\/td>yes<\/td>no<\/td><\/tr>
                  release\/*<\/code><\/td>no<\/td>yes<\/td>yes<\/td>yes<\/td>no<\/td><\/tr>
                  hotfix\/*<\/code><\/td>no or restricted<\/td>yes<\/td>critical CI<\/td>yes<\/td>no<\/td><\/tr>
                  support\/*<\/code><\/td>no<\/td>yes<\/td>yes<\/td>yes<\/td>no<\/td><\/tr>
                  feature\/*<\/code><\/td>allowed for owner<\/td>PR to develop<\/td>basic CI<\/td>before merge<\/td>avoid<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                  main<\/code> protection<\/h2>\n\n\n
                  - Require<\/span> pull request\n- Require<\/span> status checks\n- Require<\/span> approval\n- Require<\/span> CODEOWNERS for<\/span> critical files\n- Block force push\n- Block deletion\n- Require<\/span> signed tags or<\/span> signed commits if<\/span> needed\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
                  \n\n\n\n
                  29. CODEOWNERS for Gitflow<\/h1>\n\n\n\n
                  Example:<\/p>\n\n\n
                  # Platform and CI\/CD<\/span>\n\/.github\/workflows\/ @devops-team\n\/infrastructure\/ @platform-team\n\n# Services<\/span>\n\/services\/auth\/ @identity-team\n\/services\/payment\/ @payment-team\n\/services\/notification\/ @backend-team\n\n# Security-sensitive areas<\/span>\n\/security\/ @security-team\n\/database\/migrations\/ @backend-leads @platform-team\n\n# Release files<\/span>\n\/VERSION @release-managers\n\/CHANGELOG.md @release-managers\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
                  Recommended:<\/p>\n\n\n\n
                  Area<\/th>Required owner<\/th><\/tr><\/thead>
                  CI\/CD pipelines<\/td>DevOps\/platform<\/td><\/tr>
                  Infrastructure<\/td>Platform<\/td><\/tr>
                  Database migrations<\/td>Backend + platform<\/td><\/tr>
                  Authentication<\/td>Identity\/security<\/td><\/tr>
                  Payment<\/td>Payment owner<\/td><\/tr>
                  Release version files<\/td>Release manager<\/td><\/tr>
                  Production config<\/td>Service owner<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                  \n\n\n\n
                  30. Gitflow release checklist<\/h1>\n\n\n\n
                  Before creating release branch:<\/p>\n\n\n
                  - Planned features merged into develop\n- CI passing on develop\n- Known blockers reviewed\n- Version number agreed\n- Release owner assigned\n- Release scope frozen\n<\/code><\/span><\/pre>\n\n\n
                  Before merging release into main<\/code>:<\/p>\n\n\n
                  - Regression testing complete\n- Critical bugs fixed\n- Version bumped\n- Changelog updated\n- Release notes ready\n- Security scan passed\n- Deployment plan ready\n- Rollback plan ready\n- Approval completed\n<\/code><\/span><\/pre>\n\n\n
                  After release:<\/p>\n\n\n
                  - Tag pushed\n- Production deployed\n- Monitoring checked\n- Release branch merged back to develop\n- Release branch deleted or archived\n- Release notes published\n<\/code><\/span><\/pre>\n\n\n
                  \n\n\n\n
                  31. Gitflow hotfix checklist<\/h1>\n\n\n\n
                  Before hotfix:<\/p>\n\n\n
                  - Production issue confirmed\n- Severity agreed\n- Correct production version identified\n- Hotfix owner assigned\n- Rollback path understood\n<\/code><\/span><\/pre>\n\n\n
                  During hotfix:<\/p>\n\n\n
                  - Branch from<\/span> main or production tag\n- Fix only the production issue\n- Run focused tests\n- Open emergency PR\n- Get required approval\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                  After hotfix:<\/p>\n\n\n
                  - Merge into main\n- Tag patch version\n- Deploy production\n- Validate recovery\n- Merge into develop\n- Merge into active release branch if needed\n- Delete hotfix branch\n- Create follow-up ticket\n<\/code><\/span><\/pre>\n\n\n
                  \n\n\n\n
                  32. Gitflow with release candidates<\/h1>\n\n\n\n
                  For formal release cycles, release candidates are useful.<\/p>\n\n\n
                  v2<\/span>.4<\/span>.0-rc<\/span>.1<\/span>\nv2<\/span>.4<\/span>.0-rc<\/span>.2<\/span>\nv2<\/span>.4<\/span>.0<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
                  Flow:<\/p>\n\n\n
                  flowchart<\/span> TD<\/span>\n    A<\/span>[release\/2.4.0]<\/span> --<\/span>> B<\/span>[tag v2.4.0-rc.1]<\/span>\n    B<\/span> --<\/span>> C<\/span>[QA finds bug]<\/span>\n    C<\/span> --<\/span>> D<\/span>[fix on release branch]<\/span>\n    D<\/span> --<\/span>> E<\/span>[tag v2.4.0-rc.2]<\/span>\n    E<\/span> --<\/span>> F<\/span>[QA approves]<\/span>\n    F<\/span> --<\/span>> G<\/span>[merge to main]<\/span>\n    G<\/span> --<\/span>> H<\/span>[tag v2.4.0]<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
                  Commands:<\/p>\n\n\n
                  git checkout release\/2.4<\/span>.0<\/span>\ngit tag -a v2.4<\/span>.0<\/span>-rc.1<\/span> -m \"Release candidate 1 for v2.4.0\"<\/span>\ngit push origin v2.4<\/span>.0<\/span>-rc.1<\/span>\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                  Final release:<\/p>\n\n\n
                  git checkout main\ngit merge --no-ff release\/2.4<\/span>.0<\/span>\ngit tag -a v2.4<\/span>.0<\/span> -m \"Release v2.4.0\"<\/span>\ngit push origin main v2.4<\/span>.0<\/span>\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                  \n\n\n\n
                  33. Gitflow and database migrations<\/h1>\n\n\n\n
                  Gitflow needs careful database migration discipline.<\/p>\n\n\n\n
                  Dangerous pattern<\/h2>\n\n\n
                  feature branch changes schema\nrelease branch stabilizes old app\nhotfix needs production fix\ndevelop expects new<\/span> schema\nproduction still has old schema\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                  Tiny mess. Giant headache.<\/p>\n\n\n\n
                  Safe pattern: expand \u2192 migrate \u2192 contract<\/h2>\n\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 later]<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
                  Rules<\/h2>\n\n\n\n
                    \n
                  • Do not hide large migrations in feature branches.<\/li>\n\n\n\n
                  • Release branches should receive only safe migration fixes.<\/li>\n\n\n\n
                  • Destructive schema changes should be separated from feature rollout.<\/li>\n\n\n\n
                  • Hotfixes should avoid schema changes unless absolutely necessary.<\/li>\n\n\n\n
                  • develop<\/code>, release\/*<\/code>, and main<\/code> compatibility must be understood.<\/li>\n<\/ul>\n\n\n\n
                    \n\n\n\n
                    34. Gitflow with feature flags<\/h1>\n\n\n\n
                    Gitflow does not require feature flags, but feature flags make Gitflow safer.<\/p>\n\n\n\n
                    Without flags:<\/p>\n\n\n
                    unfinished feature stays in feature branch for weeks\n<\/code><\/span><\/pre>\n\n\n
                    With flags:<\/p>\n\n\n
                    feature can merge into develop safely but remain disabled\n<\/code><\/span><\/pre>\n\n
                    flowchart<\/span> TD<\/span>\n    A<\/span>[feature branch]<\/span> --<\/span>> B<\/span>[code behind flag]<\/span>\n    B<\/span> --<\/span>> C<\/span>[merge to develop]<\/span>\n    C<\/span> --<\/span>> D<\/span>[release branch]<\/span>\n    D<\/span> --<\/span>> E<\/span>[deploy with flag off]<\/span>\n    E<\/span> --<\/span>> F<\/span>[enable gradually]<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
                    Feature flags are especially useful when:<\/p>\n\n\n\n
                      \n
                    • release scope changes<\/li>\n\n\n\n
                    • a feature is code-complete but not business-ready<\/li>\n\n\n\n
                    • risky behavior needs gradual rollout<\/li>\n\n\n\n
                    • rollback should be instant<\/li>\n\n\n\n
                    • QA wants selective enablement<\/li>\n<\/ul>\n\n\n\n
                      \n\n\n\n
                      35. Gitflow with multiple teams<\/h1>\n\n\n\n
                      Gitflow gets harder as team size grows.<\/p>\n\n\n\n
                      Problems<\/h2>\n\n\n\n
                      Problem<\/th>Example<\/th><\/tr><\/thead>
                      develop<\/code> becomes unstable<\/td>too many features merged too early<\/td><\/tr>
                      release branch overload<\/td>many fixes during QA<\/td><\/tr>
                      unclear release scope<\/td>features sneak into release<\/td><\/tr>
                      hotfix back-merge forgotten<\/td>production bug returns later<\/td><\/tr>
                      long feature branches<\/td>huge conflicts<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                      Solutions<\/h2>\n\n\n\n
                      Problem<\/th>Solution<\/th><\/tr><\/thead>
                      unstable develop<\/code><\/td>protect develop<\/code>; require CI<\/td><\/tr>
                      release chaos<\/td>release owner and scope freeze<\/td><\/tr>
                      forgotten hotfix<\/td>checklist and automation<\/td><\/tr>
                      long features<\/td>feature flags and smaller PRs<\/td><\/tr>
                      QA overload<\/td>release candidate discipline<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                      \n\n\n\n
                      36. Gitflow for mobile apps<\/h1>\n\n\n\n
                      Gitflow fits mobile apps well because app releases often need QA, signing, approval, and staged rollout.<\/p>\n\n\n
                      flowchart<\/span> TD<\/span>\n    A<\/span>[develop]<\/span> --<\/span>> B<\/span>[release\/mobile-5.1.0]<\/span>\n    B<\/span> --<\/span>> C<\/span>[QA]<\/span>\n    C<\/span> --<\/span>> D<\/span>[Signed build]<\/span>\n    D<\/span> --<\/span>> E<\/span>[TestFlight \/ Internal testing]<\/span>\n    E<\/span> --<\/span>> F<\/span>[App Store \/ Play Store approval]<\/span>\n    F<\/span> --<\/span>> G<\/span>[Production rollout]<\/span>\n    G<\/span> --<\/span>> H<\/span>[tag v5.1.0]<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
                      Recommended branches:<\/p>\n\n\n
                      main\ndevelop\nfeature\/*\nrelease\/ios-5.1.0\nrelease\/android-5.1.0\nhotfix\/*\n<\/code><\/span><\/pre>\n\n\n
                      Rules:<\/p>\n\n\n\n
                        \n
                      • Release branch is frozen except fixes.<\/li>\n\n\n\n
                      • Version\/build numbers are bumped in release branch.<\/li>\n\n\n\n
                      • Tags must match shipped builds.<\/li>\n\n\n\n
                      • Hotfixes may require app-store patch releases.<\/li>\n\n\n\n
                      • Backend APIs must remain backward compatible for older app versions.<\/li>\n<\/ul>\n\n\n\n
                        \n\n\n\n
                        37. Gitflow for libraries and SDKs<\/h1>\n\n\n\n
                        Gitflow can fit libraries and SDKs because versions matter.<\/p>\n\n\n\n
                        Recommended branches:<\/p>\n\n\n
                        main\ndevelop\nfeature\/*\nrelease\/*\nhotfix\/*\nsupport\/*\n<\/code><\/span><\/pre>\n\n\n
                        Rules:<\/p>\n\n\n\n
                          \n
                        • Use Semantic Versioning.<\/li>\n\n\n\n
                        • Tag every published package.<\/li>\n\n\n\n
                        • Maintain support branches for old major versions.<\/li>\n\n\n\n
                        • Breaking changes require a major version.<\/li>\n\n\n\n
                        • Critical fixes may need backporting.<\/li>\n<\/ul>\n\n\n\n
                          Example:<\/p>\n\n\n
                          main \u2192 latest production release\ndevelop \u2192 next release\nsupport\/2.x \u2192 v2 maintenance\nsupport\/1.x-lts \u2192 v1 long-term support\n<\/code><\/span><\/pre>\n\n\n
                          \n\n\n\n
                          38. Gitflow for SaaS and web apps<\/h1>\n\n\n\n
                          Gitflow can be too heavy for fast web\/SaaS teams.<\/p>\n\n\n\n
                          Driessen\u2019s 2020 reflection says web apps are often continuously delivered and usually do not need multiple versions of the software running in the wild; for such teams, he suggested a simpler workflow such as GitHub Flow instead of forcing Gitflow.<\/p>\n\n\n\n
                          Use Gitflow for SaaS only when:<\/p>\n\n\n\n
                            \n
                          • releases are scheduled<\/li>\n\n\n\n
                          • release approvals are mandatory<\/li>\n\n\n\n
                          • customers need versioned releases<\/li>\n\n\n\n
                          • staging\/UAT is formal<\/li>\n\n\n\n
                          • compliance requires release evidence<\/li>\n\n\n\n
                          • multiple versions must be supported<\/li>\n<\/ul>\n\n\n\n
                            Otherwise, GitHub Flow or trunk-based development is usually simpler.<\/p>\n\n\n\n
                            \n\n\n\n
                            39. Gitflow vs trunk-based development<\/h1>\n\n\n\n
                            Area<\/th>Gitflow<\/th>Trunk-based development<\/th><\/tr><\/thead>
                            Core style<\/td>release branch model<\/td>single trunk\/main<\/td><\/tr>
                            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<\/td><\/tr>
                            Best for<\/td>scheduled\/versioned releases<\/td>continuous delivery<\/td><\/tr>
                            Complexity<\/td>higher<\/td>lower branch complexity<\/td><\/tr>
                            CI need<\/td>important<\/td>critical<\/td><\/tr>
                            Feature flags<\/td>useful<\/td>almost essential<\/td><\/tr>
                            Speed<\/td>medium<\/td>high<\/td><\/tr>
                            Governance<\/td>strong<\/td>automation-driven<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                            Atlassian notes that Gitflow assigns specific roles to different branches, including feature, release, and hotfix branches, and is suited to scheduled release cycles.<\/p>\n\n\n\n
                            \n\n\n\n
                            40. Gitflow vs GitHub Flow<\/h1>\n\n\n\n
                            Area<\/th>Gitflow<\/th>GitHub Flow<\/th><\/tr><\/thead>
                            Branches<\/td>many branch types<\/td>main<\/code> + short branches<\/td><\/tr>
                            Release branch<\/td>yes<\/td>usually no<\/td><\/tr>
                            develop<\/code> branch<\/td>yes<\/td>no<\/td><\/tr>
                            Production branch<\/td>main<\/code><\/td>main<\/code><\/td><\/tr>
                            Release style<\/td>scheduled\/versioned<\/td>continuous\/frequent<\/td><\/tr>
                            Best for<\/td>mobile, desktop, SDK, enterprise release<\/td>SaaS, web apps, APIs<\/td><\/tr>
                            Complexity<\/td>high<\/td>low<\/td><\/tr>
                            Hotfix path<\/td>explicit<\/td>branch from main and merge<\/td><\/tr>
                            QA cycle<\/td>release branch<\/td>staging from main<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                            \n\n\n\n
                            41. Gitflow pros and cons<\/h1>\n\n\n\n
                            Pros<\/h2>\n\n\n\n
                            Benefit<\/th>Why it matters<\/th><\/tr><\/thead>
                            Clear release structure<\/td>Everyone knows how code reaches production<\/td><\/tr>
                            Good for scheduled releases<\/td>Release branches support QA and stabilization<\/td><\/tr>
                            Strong hotfix model<\/td>Production fixes are isolated<\/td><\/tr>
                            Version-friendly<\/td>Tags and release branches map well to versions<\/td><\/tr>
                            Supports old versions<\/td>Optional support branches<\/td><\/tr>
                            Good governance<\/td>Works with approvals and release managers<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                            Cons<\/h2>\n\n\n\n
                            Cost<\/th>Why it hurts<\/th><\/tr><\/thead>
                            More complexity<\/td>More branches and merge paths<\/td><\/tr>
                            Slower delivery<\/td>More coordination<\/td><\/tr>
                            Merge conflicts<\/td>Long-lived branches drift<\/td><\/tr>
                            develop<\/code> instability<\/td>Can become a dumping ground<\/td><\/tr>
                            Overkill for continuous delivery<\/td>Too much process for fast web teams<\/td><\/tr>
                            Hotfix back-merge risk<\/td>Easy to forget merging back<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                            \n\n\n\n
                            42. When Gitflow is a good choice<\/h1>\n\n\n\n
                            Use Gitflow when you have:<\/p>\n\n\n\n
                              \n
                            • scheduled releases<\/li>\n\n\n\n
                            • formal QA cycle<\/li>\n\n\n\n
                            • versioned products<\/li>\n\n\n\n
                            • mobile apps<\/li>\n\n\n\n
                            • desktop apps<\/li>\n\n\n\n
                            • firmware<\/li>\n\n\n\n
                            • SDKs\/libraries<\/li>\n\n\n\n
                            • enterprise release approval<\/li>\n\n\n\n
                            • multiple supported versions<\/li>\n\n\n\n
                            • customer-specific release windows<\/li>\n\n\n\n
                            • production hotfix requirements<\/li>\n<\/ul>\n\n\n\n
                              AWS also positions Gitflow as suitable for teams with scheduled release cycles and a need to define a collection of features as a release.<\/p>\n\n\n\n
                              \n\n\n\n
                              43. When Gitflow is the wrong choice<\/h1>\n\n\n\n
                              Avoid Gitflow when:<\/p>\n\n\n\n
                                \n
                              • you deploy many times per day<\/li>\n\n\n\n
                              • main<\/code> is always deployable<\/li>\n\n\n\n
                              • feature flags are mature<\/li>\n\n\n\n
                              • CI\/CD is fast and reliable<\/li>\n\n\n\n
                              • releases are continuous<\/li>\n\n\n\n
                              • you do not support old versions<\/li>\n\n\n\n
                              • release branches create bureaucracy<\/li>\n\n\n\n
                              • develop<\/code> becomes unstable<\/li>\n\n\n\n
                              • PRs sit for too long<\/li>\n<\/ul>\n\n\n\n
                                For many web apps, Gitflow is like wearing a three-piece suit to eat instant noodles. Technically possible. Weird energy.<\/p>\n\n\n\n
                                \n\n\n\n
                                44. Gitflow anti-patterns<\/h1>\n\n\n\n
                                Anti-pattern 1: develop<\/code> is always broken<\/h2>\n\n\n\n
                                Problem:<\/p>\n\n\n
                                All features merge into develop, but CI is ignored.\n<\/code><\/span><\/pre>\n\n\n
                                Fix:<\/p>\n\n\n
                                Protect develop.\nRequire<\/span> CI.\nRequire<\/span> review.\nKeep develop releasable enough for<\/span> integration.\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
                                \n\n\n\n
                                Anti-pattern 2: release branch accepts new features<\/h2>\n\n\n\n
                                Problem:<\/p>\n\n\n
                                release\/2.4.0 becomes feature playground\n<\/code><\/span><\/pre>\n\n\n
                                Fix:<\/p>\n\n\n
                                Only fixes, version bump, release notes, and stabilization changes.\n<\/code><\/span><\/pre>\n\n\n
                                \n\n\n\n
                                Anti-pattern 3: hotfix not merged back<\/h2>\n\n\n\n
                                Problem:<\/p>\n\n\n
                                Production fixed in main.\nDevelop never receives fix.\nBug returns in next release.\n<\/code><\/span><\/pre>\n\n\n
                                Fix:<\/p>\n\n\n
                                Every hotfix must merge into main and develop.\nAlso merge into active release branch if one exists.\n<\/code><\/span><\/pre>\n\n\n
                                \n\n\n\n
                                Anti-pattern 4: feature branches live for months<\/h2>\n\n\n\n
                                Problem:<\/p>\n\n\n
                                feature\/new<\/span>-platform lives forever\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/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> smaller<\/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 5: too many release branches<\/h2>\n\n\n\n
                                Problem:<\/p>\n\n\n
                                release\/2.1\nrelease\/2.2\nrelease\/2.3\nrelease\/2.4\nall active, all drifting\n<\/code><\/span><\/pre>\n\n\n
                                Fix:<\/p>\n\n\n
                                Keep only necessary active release\/support branches.\nArchive\/delete<\/span> old release branches after tagging unless needed.\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                                \n\n\n\n
                                45. Gitflow metrics<\/h1>\n\n\n\n
                                Measure Gitflow health.<\/p>\n\n\n\n
                                Metric<\/th>Healthy signal<\/th><\/tr><\/thead>
                                Feature branch age<\/td>usually under one week<\/td><\/tr>
                                Release branch age<\/td>predictable and limited<\/td><\/tr>
                                Hotfix frequency<\/td>decreasing over time<\/td><\/tr>
                                Merge conflict frequency<\/td>low<\/td><\/tr>
                                CI pass rate on develop<\/code><\/td>high<\/td><\/tr>
                                Release branch bug count<\/td>manageable<\/td><\/tr>
                                Time from release branch to production<\/td>predictable<\/td><\/tr>
                                Back-merge failures<\/td>near zero<\/td><\/tr>
                                Stale branch count<\/td>low<\/td><\/tr>
                                Production rollback frequency<\/td>low<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                                \n\n\n\n
                                46. Gitflow governance policy<\/h1>\n\n\n\n
                                Use this as a company standard.<\/p>\n\n\n
                                Gitflow Policy\n\n1.<\/span> main represents production-ready code.\n2.<\/span> develop represents the next release integration branch.\n3.<\/span> feature branches start from<\/span> develop and merge back into develop.\n4.<\/span> release branches start from<\/span> develop and merge into main and develop.\n5.<\/span> hotfix branches start from<\/span> main and merge into main and develop.\n6.<\/span> support branches exist only for<\/span> maintained older versions.\n7.<\/span> main, develop, release\/*, and support\/* must be protected.\n8. CI must pass before merge.\n9. At least one review is required before merge.\n10. Release branches accept only stabilization changes.\n11. Hotfix branches accept only production emergency fixes.\n12. Every production release must be tagged.\n13. Hotfixes must be merged back to develop and active release branches.\n14. Merged branches must be deleted unless they are support branches.\n15. Release notes and changelog must be updated for releases.\n<\/span><\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                                \n\n\n\n
                                47. Gitflow branch protection policy<\/h1>\n\n\n\n
                                Branch<\/th>Protection<\/th><\/tr><\/thead>
                                main<\/code><\/td>strongest protection<\/td><\/tr>
                                develop<\/code><\/td>strong protection<\/td><\/tr>
                                release\/*<\/code><\/td>strong protection<\/td><\/tr>
                                hotfix\/*<\/code><\/td>fast-track but protected<\/td><\/tr>
                                support\/*<\/code><\/td>strong protection<\/td><\/tr>
                                feature\/*<\/code><\/td>normal branch rules<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                                Recommended:<\/p>\n\n\n
                                main:\n  - no direct push\n  - PR required\n  - CI required\n  - approval required\n  - no force push\n  - no deletion\n\ndevelop:\n  - no direct push\n  - PR required\n  - CI required\n  - approval required\n\nrelease\/*:\n  - PR required\n  - release manager approval\n  - full CI\/regression required\n\nhotfix\/*:\n  - emergency PR required\n  - critical CI required\n  - service owner approval\n\nsupport\/*:\n  - PR required\n  - compatibility tests required\n  - maintainer approval\n<\/code><\/span><\/pre>\n\n\n
                                \n\n\n\n
                                48. Gitflow release manager responsibilities<\/h1>\n\n\n\n
                                A release manager owns the release branch.<\/p>\n\n\n\n
                                Responsibilities:<\/p>\n\n\n\n
                                  \n
                                • decide release scope<\/li>\n\n\n\n
                                • create release branch<\/li>\n\n\n\n
                                • freeze new features<\/li>\n\n\n\n
                                • coordinate QA<\/li>\n\n\n\n
                                • approve release fixes<\/li>\n\n\n\n
                                • ensure version bump<\/li>\n\n\n\n
                                • ensure changelog<\/li>\n\n\n\n
                                • ensure release notes<\/li>\n\n\n\n
                                • merge release to main<\/code><\/li>\n\n\n\n
                                • tag release<\/li>\n\n\n\n
                                • merge release back to develop<\/code><\/li>\n\n\n\n
                                • delete\/archive release branch<\/li>\n\n\n\n
                                • coordinate production deployment<\/li>\n<\/ul>\n\n\n\n
                                  \n\n\n\n
                                  49. Gitflow developer responsibilities<\/h1>\n\n\n\n
                                  Developers should:<\/p>\n\n\n\n
                                    \n
                                  • branch from develop<\/code><\/li>\n\n\n\n
                                  • keep feature branches small<\/li>\n\n\n\n
                                  • rebase\/merge from develop<\/code> regularly<\/li>\n\n\n\n
                                  • write clear commits<\/li>\n\n\n\n
                                  • open PRs early<\/li>\n\n\n\n
                                  • respond to review<\/li>\n\n\n\n
                                  • add tests<\/li>\n\n\n\n
                                  • avoid mixing features<\/li>\n\n\n\n
                                  • avoid release branch changes unless fixing release bugs<\/li>\n\n\n\n
                                  • never push directly to main<\/code><\/li>\n<\/ul>\n\n\n\n
                                    \n\n\n\n
                                    50. Gitflow reviewer responsibilities<\/h1>\n\n\n\n
                                    Reviewers should check:<\/p>\n\n\n\n
                                      \n
                                    • correct target branch<\/li>\n\n\n\n
                                    • small change scope<\/li>\n\n\n\n
                                    • test coverage<\/li>\n\n\n\n
                                    • backward compatibility<\/li>\n\n\n\n
                                    • release impact<\/li>\n\n\n\n
                                    • migration safety<\/li>\n\n\n\n
                                    • security impact<\/li>\n\n\n\n
                                    • rollback path<\/li>\n\n\n\n
                                    • changelog\/version updates for release\/hotfix<\/li>\n\n\n\n
                                    • hotfix back-merge path<\/li>\n<\/ul>\n\n\n\n
                                      \n\n\n\n
                                      51. Gitflow for DevOps\/IaC repositories<\/h1>\n\n\n\n
                                      Gitflow is usually not the best default for Terraform\/IaC.<\/p>\n\n\n\n
                                      Why?<\/p>\n\n\n\n
                                      Infrastructure often benefits from:<\/p>\n\n\n
                                      main + feature branches + plan checks + environment workspaces\/folders\n<\/code><\/span><\/pre>\n\n\n
                                      Use Gitflow for IaC only when:<\/p>\n\n\n\n
                                        \n
                                      • releases of infrastructure modules are versioned<\/li>\n\n\n\n
                                      • consumers pin module versions<\/li>\n\n\n\n
                                      • release branches are genuinely needed<\/li>\n\n\n\n
                                      • old module versions are supported<\/li>\n<\/ul>\n\n\n\n
                                        For normal environment infrastructure repos, prefer:<\/p>\n\n\n
                                        main\nfeature\/*\nhotfix\/*\n<\/code><\/span><\/pre>\n\n\n
                                        with Terraform plan checks.<\/p>\n\n\n\n
                                        \n\n\n\n
                                        52. Gitflow for Kubernetes manifests<\/h1>\n\n\n\n
                                        For Kubernetes GitOps, Gitflow is often too heavy.<\/p>\n\n\n\n
                                        Better structure:<\/p>\n\n\n
                                        main\nfeature\/*\n<\/code><\/span><\/pre>\n\n\n
                                        with directories:<\/p>\n\n\n
                                        environments\/\n  dev\/\n  staging\/\n  production\/\n<\/code><\/span><\/pre>\n\n\n
                                        Use release branches only when application release packaging requires stabilization.<\/p>\n\n\n\n
                                        \n\n\n\n
                                        53. Gitflow decision tree<\/h1>\n\n\n
                                        flowchart TD\n    A[Should we use Gitflow?] --> B{Do you have scheduled\/versioned releases?}\n    B -- No --> C[Prefer GitHub Flow or trunk-based]\n    B -- Yes --> D{Do you need release stabilization branches?}\n    D -- No --> E[Use release branch lite or GitLab Flow]\n    D -- Yes --> F{Do you need hotfixes from<\/span> production?}\n    F -- Yes --> G[Gitflow is a good fit]\n    F -- No --> H{Do you support old versions?}\n    H -- Yes --> I[Gitflow + support branches]\n    H -- No --> J[Gitflow or release branch model]\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                                        \n\n\n\n
                                        54. Complete Gitflow example<\/h1>\n\n\n\n
                                        Scenario:<\/p>\n\n\n
                                        Current<\/span> production<\/span>: v1<\/span>.0<\/span>.0<\/span>\nNext<\/span> planned<\/span> release<\/span>: v1<\/span>.1<\/span>.0<\/span>\nEmergency<\/span> hotfix<\/span>: v1<\/span>.0<\/span>.1<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
                                        Initial state<\/h2>\n\n\n
                                        main<\/span>: v1<\/span>.0<\/span>.0<\/span>\ndevelop<\/span>: next<\/span> release<\/span> work<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
                                        Feature work<\/h2>\n\n\n
                                        git checkout develop\ngit checkout -b feature\/add-reporting\ngit commit -m \"feat(reporting): add export endpoint\"<\/span>\ngit push -u origin feature\/add-reporting\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                                        Merge to develop:<\/p>\n\n\n
                                        git checkout develop\ngit merge --no-ff feature\/add-reporting\ngit push origin develop\n<\/code><\/span><\/pre>\n\n\n
                                        Create release<\/h2>\n\n\n
                                        git checkout develop\ngit checkout -b release\/1.1.0\ngit push -u origin release\/1.1.0\n<\/code><\/span><\/pre>\n\n\n
                                        Fix release bug:<\/p>\n\n\n
                                        git commit -m \"fix(reporting): correct CSV header order\"<\/span>\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                                        Finish release:<\/p>\n\n\n
                                        git checkout main\ngit merge --no-ff release\/1.1<\/span>.0<\/span>\ngit tag -a v1.1<\/span>.0<\/span> -m \"Release v1.1.0\"<\/span>\ngit push origin main v1.1<\/span>.0<\/span>\n\ngit checkout develop\ngit merge --no-ff release\/1.1<\/span>.0<\/span>\ngit push origin develop\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                                        Emergency hotfix<\/h2>\n\n\n
                                        git checkout main\ngit checkout -b hotfix\/1.1<\/span>.1<\/span>-login-crash\ngit commit -m \"fix(auth): prevent crash on expired session\"<\/span>\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                                        Finish hotfix:<\/p>\n\n\n
                                        git checkout main\ngit merge --no-ff hotfix\/1.1<\/span>.1<\/span>-login-crash\ngit tag -a v1.1<\/span>.1<\/span> -m \"Hotfix v1.1.1\"<\/span>\ngit push origin main v1.1<\/span>.1<\/span>\n\ngit checkout develop\ngit merge --no-ff hotfix\/1.1<\/span>.1<\/span>-login-crash\ngit push origin develop\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                                        \n\n\n\n
                                        55. Gitflow visual summary<\/h1>\n\n\n
                                        flowchart<\/span> TD<\/span>\n    F<\/span>[feature\/*]<\/span> --<\/span>> D<\/span>[develop]<\/span>\n    D<\/span> --<\/span>> R<\/span>[release\/*]<\/span>\n    R<\/span> --<\/span>> M<\/span>[main]<\/span>\n    R<\/span> --<\/span>> D<\/span>\n    M<\/span> --<\/span>> H<\/span>[hotfix\/*]<\/span>\n    H<\/span> --<\/span>> M<\/span>\n    H<\/span> --<\/span>> D<\/span>\n    M<\/span> --<\/span>> T<\/span>[version tag]<\/span>\n    S<\/span>[support\/* optional]<\/span> --<\/span>> ST<\/span>[support tags]<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
                                        \n\n\n\n
                                        56. One-page Gitflow standard<\/h1>\n\n\n
                                        Gitflow Standard\n\nPermanent branches:\n- main\n- develop\n\nTemporary branches:\n- feature\/*\n- release\/*\n- hotfix\/*\n\nOptional long-term branches:\n- support\/*\n\nRules:\n- feature\/* starts from develop and merges into develop.\n- release\/* starts from develop and merges into main and develop.\n- hotfix\/* starts from main and merges into main and develop.\n- support\/* starts from release tag or maintained version line.\n- main contains production-ready code only.\n- develop contains next-release integration code.\n- release branches allow bug fixes, version updates, and release notes only.\n- hotfix branches allow urgent production fixes only.\n- every production release is tagged.\n- every hotfix is tagged.\n- all protected branches require PR, CI, and review.\n<\/code><\/span><\/pre>\n\n\n
                                        \n\n\n\n
                                        57. Final recommendation<\/h1>\n\n\n\n
                                        Use Gitflow when the release process itself needs structure.<\/p>\n\n\n\n
                                        Gitflow is excellent for:<\/p>\n\n\n
                                        mobile apps\ndesktop apps\nfirmware\nSDKs\nlibraries\nenterprise products\nscheduled releases\nQA-heavy releases\nmulti-version support\nregulated delivery\n<\/code><\/span><\/pre>\n\n\n
                                        Avoid Gitflow when the team is better served by:<\/p>\n\n\n
                                        main + short-lived branches\ncontinuous deployment\nfeature flags\nfast CI\/CD\ntrunk-based development\nGitHub Flow\n<\/code><\/span><\/pre>\n\n\n
                                        Final principle:<\/p>\n\n\n
                                        Gitflow is not a religion.\nGitflow is a release-management tool.\n<\/code><\/span><\/pre>\n\n\n
                                        Use it when it matches the product\u2019s release reality.<\/p>\n\n\n\n
                                        The best Gitflow implementation is not the one with the most branches.
                                        It is the one where every branch has a clear purpose, every release is traceable, every hotfix returns to future development, and production can be repaired without stopping the whole team.<\/p>\n","protected":false},"excerpt":{"rendered":"
                                        From Basic to Advanced: A Complete One-Stop Guide to Gitflow Branching, Releases, Hotfixes, CI\/CD, and Governance 1. What is Gitflow? Gitflow is a structured Git branching model… <\/p>\n","protected":false},"author":1,"featured_media":77518,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_joinchat":[],"footnotes":""},"categories":[11138],"tags":[],"class_list":["post-77517","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\/77517","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=77517"}],"version-history":[{"count":1,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/77517\/revisions"}],"predecessor-version":[{"id":77519,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/77517\/revisions\/77519"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/media\/77518"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/media?parent=77517"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/categories?post=77517"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/tags?post=77517"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}