{"id":77503,"date":"2026-07-07T01:34:12","date_gmt":"2026-07-07T01:34:12","guid":{"rendered":"https:\/\/www.devopsschool.com\/blog\/?p=77503"},"modified":"2026-07-07T01:34:14","modified_gmt":"2026-07-07T01:34:14","slug":"git-workflow-master-tutorial","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/blog\/git-workflow-master-tutorial\/","title":{"rendered":"Git Workflow Master Tutorial"},"content":{"rendered":"\n

From First Commit to Enterprise-Grade Delivery<\/h2>\n\n\n\n
\n

Best title:<\/strong>
Git Workflow Master Guide: Branching Strategies, Pull Requests, Releases, CI\/CD, and Team Governance<\/strong><\/p>\n<\/blockquote>\n\n\n\n

\n\n\n\n

1. What is a Git workflow?<\/h1>\n\n\n\n

A Git workflow<\/strong> is the agreed way a team uses Git to move code from an idea to production safely.<\/p>\n\n\n\n

It answers questions like:<\/p>\n\n\n\n

    \n
  • Where do developers create changes?<\/li>\n\n\n\n
  • Which branch is production?<\/li>\n\n\n\n
  • When do we create pull requests or merge requests?<\/li>\n\n\n\n
  • Who reviews code?<\/li>\n\n\n\n
  • How do we release?<\/li>\n\n\n\n
  • How do we hotfix production?<\/li>\n\n\n\n
  • How do we keep history clean?<\/li>\n\n\n\n
  • How do we avoid breaking main<\/code>?<\/li>\n\n\n\n
  • How does CI\/CD fit into Git?<\/li>\n<\/ul>\n\n\n\n

    Git itself provides commands such as branch<\/code>, merge<\/code>, rebase<\/code>, tag<\/code>, fetch<\/code>, pull<\/code>, push<\/code>, cherry-pick<\/code>, revert<\/code>, and bisect<\/code>; a workflow is the human and automation policy<\/strong> built around those commands. Git\u2019s official reference groups these commands under areas like branching, merging, sharing, updating, inspection, patching, and debugging.<\/p>\n\n\n\n

    \n\n\n\n

    2. The one-line mental model<\/h1>\n\n\n\n

    Git workflow is not about branches.<\/p>\n\n\n\n

    Git workflow is about controlling risk while increasing delivery speed<\/strong>.<\/p>\n\n\n\n

    Branches, pull requests, tags, reviews, CI checks, protected branches, release branches, and hotfix branches are only tools.<\/p>\n\n\n\n

    The real goal is:<\/p>\n\n\n\n

    \n

    Deliver correct code faster, with traceability, review, rollback, and confidence.<\/p>\n<\/blockquote>\n\n\n\n

    \n\n\n\n

    3. Four layers of Git workflow<\/h1>\n\n\n\n

    Most people confuse Git commands with Git workflow. A serious team separates Git into four layers.<\/p>\n\n\n

    flowchart<\/span> TD<\/span>\n    A<\/span>[Git Commands]<\/span> --<\/span>> B<\/span>[Branching Strategy]<\/span>\n    B<\/span> --<\/span>> C<\/span>[Collaboration Workflow]<\/span>\n    C<\/span> --<\/span>> D<\/span>[Release & Deployment Governance]<\/span>\n\n    A1<\/span>[commit, branch, merge, rebase, tag]<\/span> --<\/span>> A<\/span>\n    B1<\/span>[Gitflow, GitHub Flow, GitLab Flow, Trunk-Based]<\/span> --<\/span>> B<\/span>\n    C1<\/span>[PR\/MR, reviews, approvals, CI checks]<\/span> --<\/span>> C<\/span>\n    D1<\/span>[environments, releases, hotfixes, rollback, audit]<\/span> --<\/span>> D<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
    Layer<\/th>What it means<\/th>Example<\/th><\/tr><\/thead>
    Git commands<\/strong><\/td>Technical operations<\/td>git commit<\/code>, git merge<\/code>, git rebase<\/code><\/td><\/tr>
    Branching strategy<\/strong><\/td>Branch structure<\/td>Gitflow, trunk-based development<\/td><\/tr>
    Collaboration workflow<\/strong><\/td>How humans review and integrate work<\/td>Pull requests, code owners, approvals<\/td><\/tr>
    Release governance<\/strong><\/td>How code reaches users<\/td>Tags, releases, CI\/CD, rollback<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
    \n\n\n\n
    4. Core Git concepts every workflow depends on<\/h1>\n\n\n\n
    4.1 Repository<\/h2>\n\n\n\n
    A repository<\/strong> is the complete project history.<\/p>\n\n\n\n
    It contains:<\/p>\n\n\n\n
      \n
    • Files<\/li>\n\n\n\n
    • Commits<\/li>\n\n\n\n
    • Branches<\/li>\n\n\n\n
    • Tags<\/li>\n\n\n\n
    • Remote references<\/li>\n\n\n\n
    • Configuration<\/li>\n<\/ul>\n\n\n
      git init\ngit clone <repo-url<\/span>><\/span>\n<\/code><\/span>Code language:<\/span> HTML, XML<\/span> (<\/span>xml<\/span>)<\/span><\/small><\/pre>\n\n\n
      \n\n\n\n
      4.2 Commit<\/h2>\n\n\n\n
      A commit<\/strong> is a snapshot of the repository at a point in time.<\/p>\n\n\n\n
      A commit has:<\/p>\n\n\n\n
        \n
      • A unique hash<\/li>\n\n\n\n
      • Author<\/li>\n\n\n\n
      • Timestamp<\/li>\n\n\n\n
      • Message<\/li>\n\n\n\n
      • Parent commit or commits<\/li>\n\n\n\n
      • File changes<\/li>\n<\/ul>\n\n\n
        git add .\ngit commit -m \"feat: add user login\"<\/span>\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
        \n\n\n\n
        4.3 Branch<\/h2>\n\n\n\n
        A branch<\/strong> is a movable pointer to a commit.<\/p>\n\n\n\n
        This is the most important sentence in Git.<\/p>\n\n\n\n
        A branch is not a folder.
        A branch is not a copy of the full project.
        A branch is a lightweight pointer.<\/p>\n\n\n
        gitGraph\n    commit id: \"A\"<\/span>\n    commit id: \"B\"<\/span>\n    branch feature\/login\n    checkout feature\/login\n    commit id: \"C\"<\/span>\n    commit id: \"D\"<\/span>\n    checkout main\n    commit id: \"E\"<\/span>\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
        \n\n\n\n
        4.4 Main branch<\/h2>\n\n\n\n
        The primary branch is usually called:<\/p>\n\n\n\n
          \n
        • main<\/code><\/li>\n\n\n\n
        • master<\/code><\/li>\n\n\n\n
        • trunk<\/code><\/li>\n<\/ul>\n\n\n\n
          Modern repositories usually prefer main<\/code>.<\/p>\n\n\n\n
          In trunk-based development, developers collaborate around a single branch often called trunk, main, or mainline, and avoid long-lived shared development branches.<\/p>\n\n\n\n
          \n\n\n\n
          4.5 Remote<\/h2>\n\n\n\n
          A remote<\/strong> is another copy of the repository, usually hosted in GitHub, GitLab, Bitbucket, Azure DevOps, or an internal Git server.<\/p>\n\n\n
          git remote -v\ngit fetch origin\ngit push origin main\n<\/code><\/span><\/pre>\n\n\n
          \n\n\n\n
          4.6 HEAD<\/h2>\n\n\n\n
          HEAD<\/code> means:
          Where your working directory currently points.<\/strong><\/p>\n\n\n\n
          Usually, HEAD<\/code> points to the latest commit of your current branch.<\/p>\n\n\n
          git status\ngit log --oneline --decorate --graph\n<\/code><\/span><\/pre>\n\n\n
          \n\n\n\n
          4.7 Tag<\/h2>\n\n\n\n
          A tag<\/strong> marks an important commit, usually a release.<\/p>\n\n\n
          git<\/span> tag<\/span> v1<\/span>.2<\/span>.0<\/span>\ngit<\/span> push<\/span> origin<\/span> v1<\/span>.2<\/span>.0<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
          Tags are often used with release automation, changelog generation, deployment records, and rollback.<\/p>\n\n\n\n
          \n\n\n\n
          5. Git workflow vocabulary<\/h1>\n\n\n\n
          Term<\/th>Meaning<\/th><\/tr><\/thead>
          Branching strategy<\/strong><\/td>Rules for how branches are created and merged<\/td><\/tr>
          Git workflow<\/strong><\/td>Full process from coding to production<\/td><\/tr>
          Feature branch<\/strong><\/td>Temporary branch for a feature or task<\/td><\/tr>
          Pull request \/ merge request<\/strong><\/td>Review request before merging code<\/td><\/tr>
          Protected branch<\/strong><\/td>Branch with rules preventing unsafe changes<\/td><\/tr>
          Release branch<\/strong><\/td>Branch prepared for a versioned release<\/td><\/tr>
          Hotfix branch<\/strong><\/td>Emergency branch to fix production<\/td><\/tr>
          Trunk<\/strong><\/td>Main integration branch<\/td><\/tr>
          CI<\/strong><\/td>Continuous integration: automated checks on code<\/td><\/tr>
          CD<\/strong><\/td>Continuous delivery\/deployment: automated release pipeline<\/td><\/tr>
          Rebase<\/strong><\/td>Move commits onto a new base<\/td><\/tr>
          Merge<\/strong><\/td>Combine histories<\/td><\/tr>
          Squash<\/strong><\/td>Combine multiple commits into one<\/td><\/tr>
          Cherry-pick<\/strong><\/td>Copy one commit to another branch<\/td><\/tr>
          Revert<\/strong><\/td>Create a new commit that undoes another commit<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
          \n\n\n\n
          6. The Git workflow maturity ladder<\/h1>\n\n\n
          flowchart<\/span> TD<\/span>\n    L1<\/span>[Level 1: Solo Git usage]<\/span> --<\/span>> L2<\/span>[Level 2: Feature branches]<\/span>\n    L2<\/span> --<\/span>> L3<\/span>[Level 3: Pull requests]<\/span>\n    L3<\/span> --<\/span>> L4<\/span>[Level 4: Protected main branch]<\/span>\n    L4<\/span> --<\/span>> L5<\/span>[Level 5: CI required before merge]<\/span>\n    L5<\/span> --<\/span>> L6<\/span>[Level 6: Automated releases]<\/span>\n    L6<\/span> --<\/span>> L7<\/span>[Level 7: Trunk-based delivery with feature flags]<\/span>\n    L7<\/span> --<\/span>> L8<\/span>[Level 8: Progressive delivery, rollback, audit, compliance]<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
          Level<\/th>Team behavior<\/th>Risk<\/th><\/tr><\/thead>
          1<\/td>Everyone commits anywhere<\/td>Very high<\/td><\/tr>
          2<\/td>Feature branches exist<\/td>Medium-high<\/td><\/tr>
          3<\/td>PR review required<\/td>Medium<\/td><\/tr>
          4<\/td>Main branch protected<\/td>Lower<\/td><\/tr>
          5<\/td>Tests required before merge<\/td>Lower<\/td><\/tr>
          6<\/td>Releases automated<\/td>Low<\/td><\/tr>
          7<\/td>Small frequent merges<\/td>Very low when done well<\/td><\/tr>
          8<\/td>Full delivery governance<\/td>Enterprise-grade<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
          GitHub branch protection rules can require pull request reviews, passing status checks, and other constraints before code can merge into important branches.<\/p>\n\n\n\n
          \n\n\n\n
          7. The daily developer Git workflow<\/h1>\n\n\n\n
          This is the workflow every developer should master before learning advanced branching models.<\/p>\n\n\n\n
          7.1 Start clean<\/h2>\n\n\n
          git status\ngit checkout main\ngit pull --ff-only origin main\n<\/code><\/span><\/pre>\n\n\n
          Why --ff-only<\/code>?<\/p>\n\n\n\n
          Because it avoids unexpected merge commits during pull.<\/p>\n\n\n\n
          \n\n\n\n
          7.2 Create a branch<\/h2>\n\n\n
          git checkout -b feature\/login-api\n<\/code><\/span><\/pre>\n\n\n
          Recommended branch naming:<\/p>\n\n\n
          feature\/login-api\nbugfix\/payment-timeout\nhotfix\/fix-prod-crash\nchore\/update-dependencies\ndocs\/git-workflow-guide\nrefactor\/auth-service-cleanup\nexperiment\/new<\/span>-cache-strategy\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
          \n\n\n\n
          7.3 Make small commits<\/h2>\n\n\n
          git add src\/auth\/login.go\ngit commit -m \"feat(auth): add login API\"<\/span>\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
          Good commits are:<\/p>\n\n\n\n
            \n
          • Small<\/li>\n\n\n\n
          • Focused<\/li>\n\n\n\n
          • Reversible<\/li>\n\n\n\n
          • Reviewable<\/li>\n\n\n\n
          • Understandable<\/li>\n\n\n\n
          • Linked to purpose<\/li>\n<\/ul>\n\n\n\n
            Bad commit:<\/p>\n\n\n
            changes\n<\/code><\/span><\/pre>\n\n\n
            Good commit:<\/p>\n\n\n
            fix(payment): handle timeout from<\/span> gateway\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
            Conventional Commits defines a lightweight structure such as <type>[optional scope]: <description><\/code>, with optional body and footers, to make commit history easier for humans and automation to understand.<\/p>\n\n\n\n
            \n\n\n\n
            7.4 Keep your branch updated<\/h2>\n\n\n\n
            Option A: merge from main.<\/p>\n\n\n
            git fetch origin\ngit merge origin\/main\n<\/code><\/span><\/pre>\n\n\n
            Option B: rebase onto main.<\/p>\n\n\n
            git fetch origin\ngit rebase origin\/main\n<\/code><\/span><\/pre>\n\n\n
            Git rebase rewrites a series of commits onto a new base, and Git\u2019s own documentation describes commands such as git rebase --continue<\/code>, git rebase --abort<\/code>, and git rebase --skip<\/code> for conflict handling during rebase.<\/p>\n\n\n\n
            \n\n\n\n
            7.5 Push your branch<\/h2>\n\n\n
            git push -u origin feature\/login-api\n<\/code><\/span><\/pre>\n\n\n
            \n\n\n\n
            7.6 Open a pull request<\/h2>\n\n\n\n
            A pull request should answer:<\/p>\n\n\n\n
              \n
            • What changed?<\/li>\n\n\n\n
            • Why changed?<\/li>\n\n\n\n
            • How tested?<\/li>\n\n\n\n
            • What risk exists?<\/li>\n\n\n\n
            • How to rollback?<\/li>\n\n\n\n
            • Screenshots\/logs if applicable<\/li>\n\n\n\n
            • Related ticket\/issue<\/li>\n<\/ul>\n\n\n\n
              \n\n\n\n
              7.7 Pass CI<\/h2>\n\n\n\n
              Before merge, CI should run:<\/p>\n\n\n\n
                \n
              • Build<\/li>\n\n\n\n
              • Unit tests<\/li>\n\n\n\n
              • Integration tests<\/li>\n\n\n\n
              • Linting<\/li>\n\n\n\n
              • Formatting<\/li>\n\n\n\n
              • Security scan<\/li>\n\n\n\n
              • Secret scan<\/li>\n\n\n\n
              • Dependency scan<\/li>\n\n\n\n
              • Container image scan<\/li>\n\n\n\n
              • Terraform plan, if infra<\/li>\n\n\n\n
              • Kubernetes manifest validation, if platform<\/li>\n<\/ul>\n\n\n\n
                \n\n\n\n
                7.8 Merge safely<\/h2>\n\n\n\n
                Common merge options:<\/p>\n\n\n\n
                Merge type<\/th>Command \/ platform behavior<\/th>Best for<\/th><\/tr><\/thead>
                Merge commit<\/strong><\/td>Preserves branch history<\/td>Complex features, audit-heavy teams<\/td><\/tr>
                Squash merge<\/strong><\/td>Combines PR into one commit<\/td>Clean main history<\/td><\/tr>
                Rebase merge<\/strong><\/td>Replays commits linearly<\/td>Linear history with meaningful commits<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                GitHub branch protection can also enforce a linear commit history and block force pushes or deletion on protected branches.<\/p>\n\n\n\n
                \n\n\n\n
                7.9 Delete branch<\/h2>\n\n\n
                git branch -d feature\/login-api\ngit push origin --delete<\/span> feature\/login-api\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                Short-lived branches should disappear after merge. This keeps the repository clean.<\/p>\n\n\n\n
                \n\n\n\n
                8. Golden rules of Git workflow<\/h1>\n\n\n\n
                Rule 1: main<\/code> must always be healthy<\/h2>\n\n\n\n
                main<\/code> should be:<\/p>\n\n\n\n
                  \n
                • Buildable<\/li>\n\n\n\n
                • Testable<\/li>\n\n\n\n
                • Deployable<\/li>\n\n\n\n
                • Protected<\/li>\n\n\n\n
                • Recoverable<\/li>\n<\/ul>\n\n\n\n
                  A broken main<\/code> means the whole team slows down.<\/p>\n\n\n\n
                  \n\n\n\n
                  Rule 2: Branches should be short-lived<\/h2>\n\n\n\n
                  The longer a branch lives, the higher the merge risk.<\/p>\n\n\n
                  xychart-beta\n    title \"Branch Age vs Merge Risk\"<\/span>\n    x-axis [\"1 day\"<\/span>, \"3 days\"<\/span>, \"1 week\"<\/span>, \"2 weeks\"<\/span>, \"1 month\"<\/span>]\n    y-axis \"Merge Risk\"<\/span> 0<\/span> --> 100<\/span>\n    bar [10<\/span>, 20<\/span>, 40<\/span>, 70<\/span>, 95<\/span>]\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                  This is conceptual, not a measured universal law. The practical lesson is true in most teams: long-running branches drift away from the integration branch.<\/p>\n\n\n\n
                  AWS DevOps guidance recommends trunk-based development paired with a pull-request workflow and short-lived feature branches as an effective branching strategy for DevOps, with the core benefit being better continuous integration.<\/p>\n\n\n\n
                  \n\n\n\n
                  Rule 3: Pull requests should be small<\/h2>\n\n\n\n
                  A pull request should ideally be reviewable in 10\u201330 minutes.<\/p>\n\n\n\n
                  PR size<\/th>Review quality<\/th><\/tr><\/thead>
                  50 lines<\/td>Excellent<\/td><\/tr>
                  300 lines<\/td>Good<\/td><\/tr>
                  800 lines<\/td>Risky<\/td><\/tr>
                  2,000 lines<\/td>Rubber-stamp danger<\/td><\/tr>
                  10,000 lines<\/td>Archaeology, not review<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                  \n\n\n\n
                  Rule 4: Commit messages are part of engineering quality<\/h2>\n\n\n\n
                  Commit messages are not decoration.<\/p>\n\n\n\n
                  They help:<\/p>\n\n\n\n
                    \n
                  • Debug production<\/li>\n\n\n\n
                  • Generate changelogs<\/li>\n\n\n\n
                  • Review history<\/li>\n\n\n\n
                  • Understand intent<\/li>\n\n\n\n
                  • Automate releases<\/li>\n\n\n\n
                  • Track breaking changes<\/li>\n<\/ul>\n\n\n\n
                    \n\n\n\n
                    Rule 5: Never rewrite shared history casually<\/h2>\n\n\n\n
                    Safe:<\/p>\n\n\n
                    git rebase -i HEAD~3\n<\/code><\/span><\/pre>\n\n\n
                    on your local branch before pushing.<\/p>\n\n\n\n
                    Dangerous:<\/p>\n\n\n
                    git push --force origin main\n<\/code><\/span><\/pre>\n\n\n
                    Use:<\/p>\n\n\n
                    git push --force-with<\/span>-lease\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                    only when rewriting your own branch and you understand the risk.<\/p>\n\n\n\n
                    \n\n\n\n
                    Rule 6: Prefer revert over history deletion for production<\/h2>\n\n\n\n
                    Bad production fix:<\/p>\n\n\n
                    git reset --hard <old-commit<\/span>><\/span>\ngit push --force\n<\/code><\/span>Code language:<\/span> HTML, XML<\/span> (<\/span>xml<\/span>)<\/span><\/small><\/pre>\n\n\n
                    Better production fix:<\/p>\n\n\n
                    git revert <bad-commit<\/span>><\/span>\ngit push origin main\n<\/code><\/span>Code language:<\/span> HTML, XML<\/span> (<\/span>xml<\/span>)<\/span><\/small><\/pre>\n\n\n
                    git revert<\/code> creates a new commit that undoes a previous commit, preserving traceability.<\/p>\n\n\n\n
                    \n\n\n\n
                    9. The five major Git workflows<\/h1>\n\n\n\n
                    There are many variants, but most real-world teams use one of these:<\/p>\n\n\n
                    mindmap\n  root((Git Workflows))\n    Centralized Workflow\n      Simple\n      Small teams\n      Main only\n    Feature Branch Workflow\n      Branch per task\n      Pull requests\n    GitHub Flow\n      Main + short branches\n      Deploy from<\/span> main\n    GitLab Flow\n      Main + environment\/release branches\n      Issue\/MR centric\n    Gitflow\n      Main + develop + release + hotfix\n      Versioned releases\n    Trunk-Based Development\n      Single trunk\n      Very short branches\n      Feature flags\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                    \n\n\n\n
                    10. Workflow 1: Centralized workflow<\/h1>\n\n\n\n
                    What it is<\/h2>\n\n\n\n
                    Everyone commits to one main branch.<\/p>\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
                    When it works<\/h2>\n\n\n\n
                      \n
                    • Solo developer<\/li>\n\n\n\n
                    • Tiny prototype<\/li>\n\n\n\n
                    • Throwaway project<\/li>\n\n\n\n
                    • Learning Git<\/li>\n<\/ul>\n\n\n\n
                      When it fails<\/h2>\n\n\n\n
                        \n
                      • Multiple developers<\/li>\n\n\n\n
                      • Production product<\/li>\n\n\n\n
                      • Review required<\/li>\n\n\n\n
                      • CI\/CD required<\/li>\n\n\n\n
                      • Compliance required<\/li>\n<\/ul>\n\n\n\n
                        Verdict<\/h2>\n\n\n\n
                        Good for learning.
                        Bad for professional delivery.<\/p>\n\n\n\n
                        \n\n\n\n
                        11. Workflow 2: Feature branch workflow<\/h1>\n\n\n\n
                        What it is<\/h2>\n\n\n\n
                        Each task gets its own branch.<\/p>\n\n\n
                        gitGraph\n    commit id: \"main-1\"<\/span>\n    branch feature\/login\n    checkout feature\/login\n    commit id: \"login-1\"<\/span>\n    commit id: \"login-2\"<\/span>\n    checkout main\n    branch feature\/payment\n    checkout feature\/payment\n    commit id: \"payment-1\"<\/span>\n    checkout main\n    merge feature\/login\n    merge feature\/payment\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                        Process<\/h2>\n\n\n
                        git checkout main\ngit pull --ff-only\ngit checkout -b feature\/user-profile\n\n# work<\/span>\ngit add .\ngit commit -m \"feat(profile): add user profile page\"<\/span>\n\ngit push -u origin feature\/user-profile\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
                        Then:<\/p>\n\n\n\n
                          \n
                        1. Open PR\/MR<\/li>\n\n\n\n
                        2. Review<\/li>\n\n\n\n
                        3. CI runs<\/li>\n\n\n\n
                        4. Merge<\/li>\n\n\n\n
                        5. Delete branch<\/li>\n<\/ol>\n\n\n\n
                          Best for<\/h2>\n\n\n\n
                            \n
                          • Most modern teams<\/li>\n\n\n\n
                          • Product teams<\/li>\n\n\n\n
                          • Web apps<\/li>\n\n\n\n
                          • Backend services<\/li>\n\n\n\n
                          • DevOps\/IaC repos<\/li>\n<\/ul>\n\n\n\n
                            Main risk<\/h2>\n\n\n\n
                            Feature branches become long-lived.<\/p>\n\n\n\n
                            Best practice<\/h2>\n\n\n\n
                            Keep feature branches under a few days. For larger work, split into smaller PRs.<\/p>\n\n\n\n
                            \n\n\n\n
                            12. Workflow 3: GitHub Flow<\/h1>\n\n\n\n
                            What it is<\/h2>\n\n\n\n
                            GitHub Flow is a lightweight branch-based workflow where work branches from main<\/code>, changes are proposed through pull requests, reviewed, tested, and merged back to main<\/code>. GitHub\u2019s own documentation describes it as a lightweight branch-based workflow.<\/p>\n\n\n
                            flowchart<\/span> LR<\/span>\n    A<\/span>[Create branch from main]<\/span> --<\/span>> B<\/span>[Make commits]<\/span>\n    B<\/span> --<\/span>> C<\/span>[Open pull request]<\/span>\n    C<\/span> --<\/span>> D<\/span>[Discuss and review]<\/span>\n    D<\/span> --<\/span>> E<\/span>[Run CI checks]<\/span>\n    E<\/span> --<\/span>> F<\/span>[Merge to main]<\/span>\n    F<\/span> --<\/span>> G<\/span>[Deploy]<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
                            Branch structure<\/h2>\n\n\n
                            main\nfeature\/*\nbugfix\/*\nchore\/*\ndocs\/*\n<\/code><\/span><\/pre>\n\n\n
                            Example<\/h2>\n\n\n
                            git checkout main\ngit pull --ff-only origin main\n\ngit checkout -b feature\/add-search\ngit commit -am \"feat(search): add basic search endpoint\"<\/span>\ngit push -u origin feature\/add-search\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                            When to use GitHub Flow<\/h2>\n\n\n\n
                            Use it when:<\/p>\n\n\n\n
                              \n
                            • main<\/code> can be deployed frequently<\/li>\n\n\n\n
                            • CI is reliable<\/li>\n\n\n\n
                            • You do not need complex release branches<\/li>\n\n\n\n
                            • The team can review quickly<\/li>\n\n\n\n
                            • You operate web services, SaaS, APIs, internal platforms<\/li>\n<\/ul>\n\n\n\n
                              When not to use it<\/h2>\n\n\n\n
                              Avoid pure GitHub Flow when:<\/p>\n\n\n\n
                                \n
                              • You support many old versions<\/li>\n\n\n\n
                              • You release desktop\/mobile apps with long approval cycles<\/li>\n\n\n\n
                              • You need parallel release trains<\/li>\n\n\n\n
                              • Production cannot receive every merged change<\/li>\n<\/ul>\n\n\n\n
                                \n\n\n\n
                                13. Workflow 4: GitLab Flow<\/h1>\n\n\n\n
                                What it is<\/h2>\n\n\n\n
                                GitLab Flow combines feature branches and merge requests with additional guidance for production, environment branches, or release branches. GitLab\u2019s documentation positions GitLab Flow as adding structure around deployments, environments, releases, and issue tracking beyond simple GitHub Flow.<\/p>\n\n\n
                                flowchart<\/span> TD<\/span>\n    F<\/span>[Feature Branch]<\/span> --<\/span>> MR<\/span>[Merge Request]<\/span>\n    MR<\/span> --<\/span>> MAIN<\/span>[main]<\/span>\n    MAIN<\/span> --<\/span>> STAGING<\/span>[staging]<\/span>\n    STAGING<\/span> --<\/span>> PROD<\/span>[production]<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
                                Common GitLab Flow models<\/h2>\n\n\n\n
                                Model A: Production branch<\/h3>\n\n\n
                                main\nproduction\n<\/code><\/span><\/pre>\n\n\n
                                main<\/code> is where developers integrate.
                                production<\/code> is what is deployed.<\/p>\n\n\n\n
                                Model B: Environment branches<\/h3>\n\n\n
                                main\nstaging\nproduction\n<\/code><\/span><\/pre>\n\n
                                gitGraph\n    commit id: \"A\"<\/span>\n    commit id: \"B\"<\/span>\n    branch staging\n    checkout staging\n    commit id: \"Deploy staging\"<\/span>\n    branch production\n    checkout production\n    commit id: \"Deploy prod\"<\/span>\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                                Model C: Release branches<\/h3>\n\n\n
                                main\nrelease\/1.0\nrelease\/1.1\nrelease\/2.0\n<\/code><\/span><\/pre>\n\n\n
                                GitLab describes options such as production branches, environment branches, and release branches as part of GitLab Flow-style branching strategies.<\/p>\n\n\n\n
                                When to use GitLab Flow<\/h2>\n\n\n\n
                                Use it when:<\/p>\n\n\n\n
                                  \n
                                • You need environment branches<\/li>\n\n\n\n
                                • You deploy through staging before production<\/li>\n\n\n\n
                                • You want issue\/MR-driven process<\/li>\n\n\n\n
                                • You need more release control than GitHub Flow<\/li>\n\n\n\n
                                • You want less complexity than Gitflow<\/li>\n<\/ul>\n\n\n\n
                                  Practical example<\/h2>\n\n\n
                                  git checkout main\ngit checkout -b feature\/payment-retry\ngit commit -m \"feat(payment): retry failed gateway calls\"<\/span>\ngit push -u origin feature\/payment-retry\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                                  After MR approval:<\/p>\n\n\n
                                  git checkout main\ngit pull --ff-only\ngit checkout staging\ngit merge main\ngit push origin staging\n<\/code><\/span><\/pre>\n\n\n
                                  After validation:<\/p>\n\n\n
                                  git checkout production\ngit merge staging\ngit push origin production\n<\/code><\/span><\/pre>\n\n\n
                                  \n\n\n\n
                                  14. Workflow 5: Gitflow<\/h1>\n\n\n\n
                                  What it is<\/h2>\n\n\n\n
                                  Gitflow is a structured branching model with multiple long-lived branches, commonly including main<\/code>, develop<\/code>, feature\/*<\/code>, release\/*<\/code>, and hotfix\/*<\/code>. Atlassian describes Gitflow as an alternative branching model using feature branches and multiple primary branches, originally popularized by Vincent Driessen.<\/p>\n\n\n
                                  gitGraph\n    commit id: \"prod-1\"<\/span>\n    branch develop\n    checkout develop\n    commit id: \"dev-1\"<\/span>\n    branch feature\/login\n    checkout feature\/login\n    commit id: \"login\"<\/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: \"stabilize\"<\/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
                                  Branch roles<\/h2>\n\n\n\n
                                  Branch<\/th>Purpose<\/th><\/tr><\/thead>
                                  main<\/code><\/td>Production-ready code<\/td><\/tr>
                                  develop<\/code><\/td>Integration branch for next release<\/td><\/tr>
                                  feature\/*<\/code><\/td>New feature work<\/td><\/tr>
                                  release\/*<\/code><\/td>Stabilization before release<\/td><\/tr>
                                  hotfix\/*<\/code><\/td>Emergency production fix<\/td><\/tr>
                                  support\/*<\/code><\/td>Optional long-term support branch<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                                  The original Gitflow model was presented by Vincent Driessen as a branching strategy for developing and releasing version-based software.<\/p>\n\n\n\n
                                  \n\n\n\n
                                  Gitflow process<\/h2>\n\n\n\n
                                  Start feature<\/h3>\n\n\n
                                  git checkout develop\ngit pull --ff-only origin develop\ngit checkout -b feature\/invoice-export<\/span>\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                                  Finish feature<\/h3>\n\n\n
                                  git checkout develop\ngit merge --no-ff feature\/invoice-export<\/span>\ngit branch -d feature\/invoice-export<\/span>\ngit push origin develop\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                                  Start release<\/h3>\n\n\n
                                  git checkout develop\ngit checkout -b release\/1.4.0\n<\/code><\/span><\/pre>\n\n\n
                                  Finish release<\/h3>\n\n\n
                                  git checkout main\ngit merge --no-ff release\/1.4.0\ngit tag v1.4.0\n\ngit checkout develop\ngit merge --no-ff release\/1.4.0\n\ngit branch -d release\/1.4.0\ngit push origin main develop --tags\n<\/code><\/span><\/pre>\n\n\n
                                  Hotfix<\/h3>\n\n\n
                                  git checkout main\ngit checkout -b hotfix\/1.4<\/span>.1<\/span>\n\n# fix production issue<\/span>\ngit commit -am \"fix: prevent crash on empty invoice\"<\/span>\n\ngit checkout main\ngit merge --no-ff hotfix\/1.4<\/span>.1<\/span>\ngit tag v1.4<\/span>.1<\/span>\n\ngit checkout develop\ngit merge --no-ff hotfix\/1.4<\/span>.1<\/span>\n\ngit branch -d hotfix\/1.4<\/span>.1<\/span>\ngit push origin main develop --tags\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
                                  When Gitflow is good<\/h2>\n\n\n\n
                                  Use Gitflow when:<\/p>\n\n\n\n
                                    \n
                                  • You release versioned software<\/li>\n\n\n\n
                                  • You support multiple release versions<\/li>\n\n\n\n
                                  • You have scheduled release windows<\/li>\n\n\n\n
                                  • You need stabilization branches<\/li>\n\n\n\n
                                  • You ship mobile apps, desktop apps, firmware, SDKs, or on-prem products<\/li>\n\n\n\n
                                  • Production releases are not continuous<\/li>\n<\/ul>\n\n\n\n
                                    When Gitflow hurts<\/h2>\n\n\n\n
                                    Gitflow can slow teams when:<\/p>\n\n\n\n
                                      \n
                                    • You deploy multiple times per day<\/li>\n\n\n\n
                                    • CI\/CD is mature<\/li>\n\n\n\n
                                    • Features can be hidden with flags<\/li>\n\n\n\n
                                    • Releases are small and frequent<\/li>\n\n\n\n
                                    • Long-lived branches cause merge pain<\/li>\n<\/ul>\n\n\n\n
                                      Atlassian notes that compared with trunk-based development, Gitflow has more long-lived branches and larger commits.<\/p>\n\n\n\n
                                      \n\n\n\n
                                      15. Workflow 6: Trunk-based development<\/h1>\n\n\n\n
                                      What it is<\/h2>\n\n\n\n
                                      Trunk-based development means developers integrate small changes into a single shared branch frequently. The trunk-based development reference site defines it as a 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
                                      gitGraph\n    commit id: \"A\"<\/span>\n    commit id: \"B\"<\/span>\n    branch small-change-1<\/span>\n    checkout small-change-1<\/span>\n    commit id: \"C\"<\/span>\n    checkout main\n    merge small-change-1<\/span>\n    branch small-change-2<\/span>\n    checkout small-change-2<\/span>\n    commit id: \"D\"<\/span>\n    checkout main\n    merge small-change-2<\/span>\n    commit id: \"E\"<\/span>\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                                      Core idea<\/h2>\n\n\n\n
                                      Instead of:<\/p>\n\n\n
                                      Big feature branch for 3 weeks\n<\/code><\/span><\/pre>\n\n\n
                                      Do:<\/p>\n\n\n
                                      Tiny branch \u2192 PR \u2192 tests \u2192 merge \u2192 hidden behind feature flag\nTiny branch \u2192 PR \u2192 tests \u2192 merge \u2192 hidden behind feature flag\nTiny branch \u2192 PR \u2192 tests \u2192 merge \u2192 hidden behind feature flag\n<\/code><\/span><\/pre>\n\n\n
                                      Trunk-based rules<\/h2>\n\n\n\n
                                      Rule<\/th>Meaning<\/th><\/tr><\/thead>
                                      One main integration branch<\/td>Usually main<\/code> or trunk<\/code><\/td><\/tr>
                                      Very short-lived branches<\/td>Hours or days, not weeks<\/td><\/tr>
                                      Small PRs<\/td>Easy to review<\/td><\/tr>
                                      Strong CI<\/td>Main must stay green<\/td><\/tr>
                                      Feature flags<\/td>Incomplete features hidden<\/td><\/tr>
                                      Fast rollback<\/td>Revert or disable flag<\/td><\/tr>
                                      Continuous integration<\/td>Merge frequently<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                                      The trunk-based development reference explicitly discusses short-lived feature branches that are deleted after merge\/integration.<\/p>\n\n\n\n
                                      When trunk-based development is excellent<\/h2>\n\n\n\n
                                      Use it when:<\/p>\n\n\n\n
                                        \n
                                      • You have strong automated tests<\/li>\n\n\n\n
                                      • CI is fast and trusted<\/li>\n\n\n\n
                                      • Developers are comfortable with small changes<\/li>\n\n\n\n
                                      • You use feature flags<\/li>\n\n\n\n
                                      • You deploy frequently<\/li>\n\n\n\n
                                      • You want continuous delivery<\/li>\n<\/ul>\n\n\n\n
                                        When it is risky<\/h2>\n\n\n\n
                                        Avoid jumping directly to trunk-based development when:<\/p>\n\n\n\n
                                          \n
                                        • Tests are weak<\/li>\n\n\n\n
                                        • Reviews are slow<\/li>\n\n\n\n
                                        • Developers create huge PRs<\/li>\n\n\n\n
                                        • Main often breaks<\/li>\n\n\n\n
                                        • No feature flag system exists<\/li>\n\n\n\n
                                        • Release and deployment are manual<\/li>\n<\/ul>\n\n\n\n
                                          Trunk-based development with pull requests<\/h2>\n\n\n\n
                                          This is the practical modern version:<\/p>\n\n\n
                                          flowchart<\/span> LR<\/span>\n    A<\/span>[Small local change]<\/span> --<\/span>> B<\/span>[Short-lived branch]<\/span>\n    B<\/span> --<\/span>> C<\/span>[Pull request]<\/span>\n    C<\/span> --<\/span>> D<\/span>[CI + review]<\/span>\n    D<\/span> --<\/span>> E<\/span>[Merge to main]<\/span>\n    E<\/span> --<\/span>> F<\/span>[Deploy or release]<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
                                          This is usually better than allowing everyone to push directly to main<\/code>.<\/p>\n\n\n\n
                                          \n\n\n\n
                                          16. Gitflow vs trunk-based development<\/h1>\n\n\n\n
                                          Area<\/th>Gitflow<\/th>Trunk-based development<\/th><\/tr><\/thead>
                                          Main idea<\/td>Controlled release branches<\/td>Continuous integration into trunk<\/td><\/tr>
                                          Primary branches<\/td>main<\/code>, develop<\/code>, release, hotfix<\/td>Mostly main<\/code> \/ trunk<\/code><\/td><\/tr>
                                          Branch lifetime<\/td>Longer<\/td>Very short<\/td><\/tr>
                                          Release style<\/td>Scheduled\/versioned<\/td>Frequent\/continuous<\/td><\/tr>
                                          CI requirement<\/td>Important<\/td>Critical<\/td><\/tr>
                                          Feature flags<\/td>Useful<\/td>Almost required<\/td><\/tr>
                                          Merge pain<\/td>Higher if branches live long<\/td>Lower if changes are tiny<\/td><\/tr>
                                          Best for<\/td>Versioned products, slower release cadence<\/td>Web services, SaaS, fast teams<\/td><\/tr>
                                          Team maturity needed<\/td>Medium<\/td>High<\/td><\/tr>
                                          Operational speed<\/td>Medium<\/td>High<\/td><\/tr>
                                          Governance clarity<\/td>High<\/td>Depends on automation<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                                          Simple decision<\/h2>\n\n\n
                                          flowchart TD\n    A[Choose Git Workflow] --> B{Can main be deployed frequently?}\n    B -- Yes --> C{Strong CI and tests?}\n    C -- Yes --> D[Trunk-Based Development]\n    C -- No --> E[GitHub Flow \/ Feature Branch Workflow]\n    B -- No --> F{Need release stabilization?}\n    F -- Yes --> G[Gitflow or GitLab Flow with<\/span> release branches]\n    F -- No --> H[GitLab Flow with<\/span> environment branches]\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                                          \n\n\n\n
                                          17. GitHub Flow vs GitLab Flow vs Gitflow vs Trunk-Based<\/h1>\n\n\n\n
                                          Workflow<\/th>Best summary<\/th>Best team type<\/th><\/tr><\/thead>
                                          GitHub Flow<\/strong><\/td>Simple PR-based flow from main<\/code><\/td>Web\/service teams<\/td><\/tr>
                                          GitLab Flow<\/strong><\/td>GitHub Flow plus environment\/release structure<\/td>Teams with staging\/prod promotion<\/td><\/tr>
                                          Gitflow<\/strong><\/td>Heavy release management model<\/td>Versioned products<\/td><\/tr>
                                          Trunk-based<\/strong><\/td>Small frequent integration into trunk<\/td>High-performing CI\/CD teams<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                                          GitLab describes GitLab Flow as a simpler alternative to Gitflow that combines feature-driven development and feature branches with issue tracking, while allowing production and stable branches.<\/p>\n\n\n\n
                                          \n\n\n\n
                                          18. Recommended workflow by project type<\/h1>\n\n\n\n
                                          Project type<\/th>Recommended workflow<\/th><\/tr><\/thead>
                                          Solo learning project<\/td>Centralized or simple feature branch<\/td><\/tr>
                                          Startup web app<\/td>GitHub Flow<\/td><\/tr>
                                          SaaS backend<\/td>Trunk-based with PRs<\/td><\/tr>
                                          Kubernetes manifests<\/td>GitOps-style trunk or environment branches<\/td><\/tr>
                                          Terraform IaC<\/td>Feature branch + PR + plan checks<\/td><\/tr>
                                          Mobile app<\/td>Gitflow or GitLab Flow with release branches<\/td><\/tr>
                                          Desktop app<\/td>Gitflow<\/td><\/tr>
                                          SDK\/library<\/td>Gitflow or release-branch model<\/td><\/tr>
                                          Firmware<\/td>Gitflow with support branches<\/td><\/tr>
                                          Enterprise platform<\/td>GitLab Flow or trunk-based with strong governance<\/td><\/tr>
                                          Monorepo<\/td>Trunk-based with CODEOWNERS and selective CI<\/td><\/tr>
                                          Open source<\/td>Feature branch\/fork PR workflow<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                                          \n\n\n\n
                                          19. The best modern default workflow<\/h1>\n\n\n\n
                                          For most modern engineering teams, use this:<\/p>\n\n\n
                                          main\nfeature\/*\nbugfix\/*\nhotfix\/*\nrelease\/* only when needed\n<\/code><\/span><\/pre>\n\n\n
                                          With rules:<\/p>\n\n\n\n
                                            \n
                                          1. main<\/code> is always deployable.<\/li>\n\n\n\n
                                          2. No direct push to main<\/code>.<\/li>\n\n\n\n
                                          3. Every change goes through PR\/MR.<\/li>\n\n\n\n
                                          4. CI must pass before merge.<\/li>\n\n\n\n
                                          5. At least one approval required.<\/li>\n\n\n\n
                                          6. Use squash merge or rebase merge for clean history.<\/li>\n\n\n\n
                                          7. Use tags for releases.<\/li>\n\n\n\n
                                          8. Use feature flags for incomplete features.<\/li>\n\n\n\n
                                          9. Hotfixes branch from production commit.<\/li>\n\n\n\n
                                          10. Delete branches after merge.<\/li>\n<\/ol>\n\n\n
                                            flowchart TD\n    A[Issue \/ Task] --> B[Create short-lived branch]\n    B --> C[Small commits]\n    C --> D[Open PR]\n    D --> E[CI checks]\n    D --> F[Code review]\n    E --> G{Pass?}\n    F --> H{Approved?}\n    G -- No --> C\n    H -- No --> C\n    G -- Yes --> I[Merge to main]\n    H -- Yes --> I\n    I --> J[Deploy to staging]\n    J --> K[Promote to production]\n    K --> L[Tag release]\n<\/code><\/span><\/pre>\n\n\n
                                            \n\n\n\n
                                            20. Branch naming standard<\/h1>\n\n\n\n
                                            Recommended format<\/h2>\n\n\n
                                            <type<\/span>><\/span>\/<ticket-id<\/span>><\/span>-<short-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<\/span>-add-device-search\nbugfix\/EVP-221<\/span>-fix-login-timeout\nhotfix\/EVP-911<\/span>-fix-prod-crash\nchore\/EVP-301<\/span>-upgrade-node\ndocs\/EVP-404<\/span>-update-runbook\nrefactor\/EVP-510<\/span>-clean-auth-module<\/span>\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                                            Branch type guide<\/h2>\n\n\n\n
                                            Prefix<\/th>Use for<\/th><\/tr><\/thead>
                                            feature\/<\/code><\/td>New user-visible or system capability<\/td><\/tr>
                                            bugfix\/<\/code><\/td>Non-production bug fix<\/td><\/tr>
                                            hotfix\/<\/code><\/td>Emergency production fix<\/td><\/tr>
                                            chore\/<\/code><\/td>Maintenance<\/td><\/tr>
                                            docs\/<\/code><\/td>Documentation<\/td><\/tr>
                                            test\/<\/code><\/td>Test-only change<\/td><\/tr>
                                            refactor\/<\/code><\/td>Internal code restructure<\/td><\/tr>
                                            perf\/<\/code><\/td>Performance improvement<\/td><\/tr>
                                            security\/<\/code><\/td>Security fix<\/td><\/tr>
                                            experiment\/<\/code><\/td>Temporary exploration<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                                            \n\n\n\n
                                            21. Commit message standard<\/h1>\n\n\n\n
                                            Recommended format<\/h2>\n\n\n
                                            <type<\/span>><\/span>(optional-scope): <short<\/span> summary<\/span>><\/span>\n\nOptional body explaining why.\n\nOptional footer:\nBREAKING CHANGE: description\nRefs: TICKET-123\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 Okta login callback\n<\/code><\/span>Code language:<\/span> HTTP<\/span> (<\/span>http<\/span>)<\/span><\/small><\/pre>\n\n
                                            fix(kafka)<\/span>: retry transient producer failures\n<\/code><\/span>Code language:<\/span> HTTP<\/span> (<\/span>http<\/span>)<\/span><\/small><\/pre>\n\n
                                            chore(terraform)<\/span>: upgrade AWS provider to v6\n<\/code><\/span>Code language:<\/span> HTTP<\/span> (<\/span>http<\/span>)<\/span><\/small><\/pre>\n\n
                                            docs(runbook)<\/span>: add EKS incident rollback steps\n<\/code><\/span>Code language:<\/span> HTTP<\/span> (<\/span>http<\/span>)<\/span><\/small><\/pre>\n\n\n
                                            Conventional Commits aligns well with SemVer because commit types such as features, fixes, and breaking changes can drive automated changelog and version decisions.<\/p>\n\n\n\n
                                            \n\n\n\n
                                            22. Commit types<\/h1>\n\n\n\n
                                            Type<\/th>Meaning<\/th>Version impact<\/th><\/tr><\/thead>
                                            feat<\/code><\/td>New feature<\/td>Minor<\/td><\/tr>
                                            fix<\/code><\/td>Bug fix<\/td>Patch<\/td><\/tr>
                                            perf<\/code><\/td>Performance improvement<\/td>Patch or minor<\/td><\/tr>
                                            refactor<\/code><\/td>Code change without behavior change<\/td>Usually none<\/td><\/tr>
                                            docs<\/code><\/td>Documentation<\/td>None<\/td><\/tr>
                                            test<\/code><\/td>Tests only<\/td>None<\/td><\/tr>
                                            build<\/code><\/td>Build system or dependencies<\/td>Depends<\/td><\/tr>
                                            ci<\/code><\/td>CI\/CD pipeline<\/td>None<\/td><\/tr>
                                            chore<\/code><\/td>Maintenance<\/td>None<\/td><\/tr>
                                            revert<\/code><\/td>Revert previous commit<\/td>Depends<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                                            Semantic Versioning uses MAJOR.MINOR.PATCH<\/code>, where major versions indicate incompatible API changes, minor versions add backward-compatible functionality, and patch versions add backward-compatible bug fixes.<\/p>\n\n\n\n
                                            \n\n\n\n
                                            23. Pull request template<\/h1>\n\n\n\n
                                            Use this as a high-quality PR template.<\/p>\n\n\n
                                            ## Summary<\/span>\n\nExplain what changed in 2<\/span>\u20135<\/span> lines.\n\n## Why<\/span>\n\nExplain the reason, ticket, incident, or<\/span> user problem.\n\n## Changes<\/span>\n\n- Added:\n- Changed:\n- Removed:\n- Fixed:\n\n## Testing<\/span>\n\n- [ ] Unit tests\n- [ ] Integration tests\n- [ ] Manual test\n- [ ] Local run\n- [ ] Staging validation\n\n## Risk<\/span>\n\nLow \/ Medium \/ High\n\nExplain risk.\n\n## Rollback Plan<\/span>\n\nHow can this be reverted or<\/span> disabled?\n\n## Screenshots \/ Logs<\/span>\n\nAdd screenshots, logs, traces, or<\/span> curl output if<\/span> useful.\n\n## Checklist<\/span>\n\n- [ ] Small enough to review\n- [ ] CI passed\n- [ ] No secrets committed\n- [ ] Docs updated\n- [ ] Monitoring\/alerts considered\n- [ ] Backward compatibility considered\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
                                            \n\n\n\n
                                            24. Pull request size policy<\/h1>\n\n\n\n
                                            PR size<\/th>Policy<\/th><\/tr><\/thead>
                                            1\u2013200 lines<\/td>Ideal<\/td><\/tr>
                                            200\u2013500 lines<\/td>Acceptable<\/td><\/tr>
                                            500\u20131,000 lines<\/td>Needs explanation<\/td><\/tr>
                                            1,000+ lines<\/td>Split unless generated code<\/td><\/tr>
                                            5,000+ lines<\/td>Should almost never be reviewed manually<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                                            Generated files should be clearly marked.<\/p>\n\n\n\n
                                            Example:<\/p>\n\n\n
                                            Note<\/span>: 3,200 lines<\/span> are<\/span> generated<\/span> OpenAPI<\/span> client<\/span> files<\/span>.\nHuman<\/span> review<\/span> should<\/span> focus<\/span> on<\/span>:\n-<\/span> api<\/span>.yaml<\/span>\n-<\/span> client<\/span> config<\/span>\n-<\/span> usage<\/span> changes<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
                                            \n\n\n\n
                                            25. Code review rules<\/h1>\n\n\n\n
                                            Reviewer should check<\/h2>\n\n\n\n
                                              \n
                                            • Correctness<\/li>\n\n\n\n
                                            • Simplicity<\/li>\n\n\n\n
                                            • Security<\/li>\n\n\n\n
                                            • Tests<\/li>\n\n\n\n
                                            • Observability<\/li>\n\n\n\n
                                            • Backward compatibility<\/li>\n\n\n\n
                                            • Failure handling<\/li>\n\n\n\n
                                            • Performance impact<\/li>\n\n\n\n
                                            • Migration safety<\/li>\n\n\n\n
                                            • Rollback path<\/li>\n<\/ul>\n\n\n\n
                                              Reviewer should not focus only on<\/h2>\n\n\n\n
                                                \n
                                              • Personal style<\/li>\n\n\n\n
                                              • Tiny naming preferences<\/li>\n\n\n\n
                                              • Formatting already handled by tools<\/li>\n\n\n\n
                                              • \u201cI would have written it differently\u201d<\/li>\n<\/ul>\n\n\n\n
                                                Review comment levels<\/h2>\n\n\n\n
                                                Level<\/th>Meaning<\/th><\/tr><\/thead>
                                                blocking<\/code><\/td>Must fix before merge<\/td><\/tr>
                                                suggestion<\/code><\/td>Better but not required<\/td><\/tr>
                                                question<\/code><\/td>Clarification needed<\/td><\/tr>
                                                nit<\/code><\/td>Tiny non-blocking comment<\/td><\/tr>
                                                praise<\/code><\/td>Good pattern worth reinforcing<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                                                \n\n\n\n
                                                26. Protected branch rules<\/h1>\n\n\n\n
                                                For main<\/code>, enable:<\/p>\n\n\n\n
                                                Rule<\/th>Recommendation<\/th><\/tr><\/thead>
                                                Direct push<\/td>Disabled<\/td><\/tr>
                                                PR\/MR required<\/td>Yes<\/td><\/tr>
                                                Required approvals<\/td>1\u20132<\/td><\/tr>
                                                CODEOWNERS<\/td>Yes for critical areas<\/td><\/tr>
                                                Status checks<\/td>Required<\/td><\/tr>
                                                Conversation resolution<\/td>Required<\/td><\/tr>
                                                Force push<\/td>Disabled<\/td><\/tr>
                                                Branch deletion<\/td>Disabled<\/td><\/tr>
                                                Signed commits<\/td>Optional\/required for regulated teams<\/td><\/tr>
                                                Linear history<\/td>Optional<\/td><\/tr>
                                                Admin bypass<\/td>Avoid or audit<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                                                GitHub protected branch rules can require approving reviews and passing status checks before merge, and can restrict force pushes or branch deletion.<\/p>\n\n\n\n
                                                \n\n\n\n
                                                27. Merge strategies explained<\/h1>\n\n\n\n
                                                27.1 Merge commit<\/h2>\n\n\n
                                                git merge --no-ff feature\/login\n<\/code><\/span><\/pre>\n\n
                                                gitGraph\n    commit id: \"A\"<\/span>\n    branch feature\n    checkout feature\n    commit id: \"B\"<\/span>\n    commit id: \"C\"<\/span>\n    checkout main\n    commit id: \"D\"<\/span>\n    merge feature id: \"Merge\"<\/span>\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                                                Pros<\/h3>\n\n\n\n
                                                  \n
                                                • Preserves full branch context<\/li>\n\n\n\n
                                                • Good audit trail<\/li>\n\n\n\n
                                                • Easy to see feature grouping<\/li>\n<\/ul>\n\n\n\n
                                                  Cons<\/h3>\n\n\n\n
                                                    \n
                                                  • Noisy history<\/li>\n\n\n\n
                                                  • Many merge commits<\/li>\n<\/ul>\n\n\n\n
                                                    Use when<\/h3>\n\n\n\n
                                                      \n
                                                    • You need traceability<\/li>\n\n\n\n
                                                    • Feature branch history matters<\/li>\n\n\n\n
                                                    • Enterprise audit is important<\/li>\n<\/ul>\n\n\n\n
                                                      \n\n\n\n
                                                      27.2 Squash merge<\/h2>\n\n\n
                                                      git merge --squash feature\/login\ngit commit -m \"feat(auth): add login flow\"<\/span>\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n
                                                      gitGraph\n    commit id: \"A\"<\/span>\n    commit id: \"B\"<\/span>\n    commit id: \"Squashed feature\"<\/span>\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                                                      Pros<\/h3>\n\n\n\n
                                                        \n
                                                      • Very clean main<\/code><\/li>\n\n\n\n
                                                      • One PR equals one commit<\/li>\n\n\n\n
                                                      • Easy revert<\/li>\n<\/ul>\n\n\n\n
                                                        Cons<\/h3>\n\n\n\n
                                                          \n
                                                        • Loses individual commit details from branch<\/li>\n\n\n\n
                                                        • Harder to preserve granular history<\/li>\n<\/ul>\n\n\n\n
                                                          Use when<\/h3>\n\n\n\n
                                                            \n
                                                          • Team writes messy local commits<\/li>\n\n\n\n
                                                          • You want readable main history<\/li>\n\n\n\n
                                                          • PR is the unit of change<\/li>\n<\/ul>\n\n\n\n
                                                            \n\n\n\n
                                                            27.3 Rebase merge<\/h2>\n\n\n
                                                            git checkout feature\/login\ngit rebase main\ngit checkout main\ngit merge --ff-only feature\/login\n<\/code><\/span><\/pre>\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
                                                            Pros<\/h3>\n\n\n\n
                                                              \n
                                                            • Linear history<\/li>\n\n\n\n
                                                            • Clean bisecting<\/li>\n\n\n\n
                                                            • No merge commits<\/li>\n<\/ul>\n\n\n\n
                                                              Cons<\/h3>\n\n\n\n
                                                                \n
                                                              • Rewrites commit history<\/li>\n\n\n\n
                                                              • Dangerous if used carelessly on shared branches<\/li>\n<\/ul>\n\n\n\n
                                                                GitHub describes rebase as a command that can change a series of commits, including reordering, editing, or squashing them.<\/p>\n\n\n\n
                                                                \n\n\n\n
                                                                28. Which merge strategy should your team choose?<\/h1>\n\n\n\n
                                                                Team style<\/th>Recommended merge<\/th><\/tr><\/thead>
                                                                Small web team<\/td>Squash merge<\/td><\/tr>
                                                                DevOps\/IaC team<\/td>Squash or merge commit<\/td><\/tr>
                                                                Regulated enterprise<\/td>Merge commit<\/td><\/tr>
                                                                Open-source library<\/td>Rebase or merge commit<\/td><\/tr>
                                                                Monorepo<\/td>Squash merge<\/td><\/tr>
                                                                High-quality commit culture<\/td>Rebase merge<\/td><\/tr>
                                                                New team<\/td>Squash merge<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                                                                My practical recommendation:<\/p>\n\n\n
                                                                Use squash merge by default<\/span>.\nUse merge commits for<\/span> release branches or complex multi-commit features.\nUse rebase locally to clean your branch before PR.\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                                                                \n\n\n\n
                                                                29. Rebase vs merge<\/h1>\n\n\n\n
                                                                Question<\/th>Merge<\/th>Rebase<\/th><\/tr><\/thead>
                                                                Preserves original history?<\/td>Yes<\/td>No, rewrites branch commits<\/td><\/tr>
                                                                Creates merge commit?<\/td>Usually yes<\/td>No<\/td><\/tr>
                                                                Good for shared branches?<\/td>Yes<\/td>Risky<\/td><\/tr>
                                                                Good for local cleanup?<\/td>Less useful<\/td>Excellent<\/td><\/tr>
                                                                Easier for beginners?<\/td>Yes<\/td>No<\/td><\/tr>
                                                                Cleaner history?<\/td>Sometimes noisy<\/td>Yes<\/td><\/tr>
                                                                Conflict resolution repeated?<\/td>Usually once<\/td>Can be multiple times<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                                                                Safe rebase rule<\/h2>\n\n\n
                                                                Rebase your own local branch.\nDo<\/span> not rebase shared branches unless the team explicitly agrees.\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
                                                                \n\n\n\n
                                                                30. Conflict resolution<\/h1>\n\n\n\n
                                                                What is a conflict?<\/h2>\n\n\n\n
                                                                A conflict happens when Git cannot automatically combine changes.<\/p>\n\n\n\n
                                                                Example:<\/p>\n\n\n
                                                                <<<<<<< HEAD\ntimeout = 30\n=======\ntimeout = 60\n>>>>>>> feature\/increase-timeout\n<\/code><\/span><\/pre>\n\n\n
                                                                You must decide final content:<\/p>\n\n\n
                                                                timeout = 60\n<\/code><\/span><\/pre>\n\n\n
                                                                Then:<\/p>\n\n\n
                                                                git add config.yml\ngit rebase --continue<\/span>\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                                                                or:<\/p>\n\n\n
                                                                git<\/span> add<\/span> config<\/span>.yml<\/span>\ngit<\/span> commit<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
                                                                depending on whether you are rebasing or merging.<\/p>\n\n\n\n
                                                                Conflict survival workflow<\/h2>\n\n\n
                                                                flowchart TD\n    A[Conflict appears] --> B[Read both sides]\n    B --> C[Understand intent]\n    C --> D[Edit final<\/span> version]\n    D --> E[Run tests]\n    E --> F[git add file]\n    F --> G{Merge or<\/span> rebase?}\n    G -- Merge --> H[git commit]\n    G -- Rebase --> I[git rebase --continue<\/span>]\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
                                                                Never resolve conflicts blindly<\/h2>\n\n\n\n
                                                                Bad:<\/p>\n\n\n
                                                                Accept current change\nAccept incoming change\n<\/code><\/span><\/pre>\n\n\n
                                                                Good:<\/p>\n\n\n
                                                                Understand both changes, then produce correct final<\/span> code.\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
                                                                \n\n\n\n
                                                                31. Stash workflow<\/h1>\n\n\n\n
                                                                Use stash when you need to temporarily save unfinished work.<\/p>\n\n\n
                                                                git stash push -m \"WIP login refactor\"<\/span>\ngit checkout main\ngit pull --ff-only\ngit checkout feature\/login\ngit stash pop\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                                                                List stashes:<\/p>\n\n\n
                                                                git stash list<\/span>\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
                                                                Apply without deleting stash:<\/p>\n\n\n
                                                                git<\/span> stash<\/span> apply<\/span> stash<\/span>@{0}\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
                                                                Drop stash:<\/p>\n\n\n
                                                                git<\/span> stash<\/span> drop<\/span> stash<\/span>@{0}\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
                                                                \n\n\n\n
                                                                32. Cherry-pick workflow<\/h1>\n\n\n\n
                                                                Use cherry-pick when one specific commit must move to another branch.<\/p>\n\n\n
                                                                git checkout release\/1.2\ngit cherry-pick abc1234\n<\/code><\/span><\/pre>\n\n\n
                                                                Good use cases:<\/p>\n\n\n\n
                                                                  \n
                                                                • Move a hotfix to release branch<\/li>\n\n\n\n
                                                                • Backport a bug fix<\/li>\n\n\n\n
                                                                • Apply one safe commit without merging a whole branch<\/li>\n<\/ul>\n\n\n\n
                                                                  Bad use cases:<\/p>\n\n\n\n
                                                                    \n
                                                                  • Replacing proper release process<\/li>\n\n\n\n
                                                                  • Randomly copying many commits<\/li>\n\n\n\n
                                                                  • Avoiding integration discipline<\/li>\n<\/ul>\n\n\n\n
                                                                    \n\n\n\n
                                                                    33. Revert workflow<\/h1>\n\n\n\n
                                                                    Use revert to undo safely.<\/p>\n\n\n
                                                                    git revert abc1234\ngit push origin main\n<\/code><\/span><\/pre>\n\n\n
                                                                    For merge commits:<\/p>\n\n\n
                                                                    git revert -m 1 <merge-commit-sha<\/span>><\/span>\n<\/code><\/span>Code language:<\/span> HTML, XML<\/span> (<\/span>xml<\/span>)<\/span><\/small><\/pre>\n\n\n
                                                                    Use revert when:<\/p>\n\n\n\n
                                                                      \n
                                                                    • Bad commit reached shared branch<\/li>\n\n\n\n
                                                                    • Production rollback needs traceability<\/li>\n\n\n\n
                                                                    • You want an audit-safe undo<\/li>\n<\/ul>\n\n\n\n
                                                                      \n\n\n\n
                                                                      34. Reset workflow<\/h1>\n\n\n\n
                                                                      reset<\/code> moves branch pointers.<\/p>\n\n\n\n
                                                                      Soft reset:<\/p>\n\n\n
                                                                      git reset --soft HEAD~1\n<\/code><\/span><\/pre>\n\n\n
                                                                      Keeps changes staged.<\/p>\n\n\n\n
                                                                      Mixed reset:<\/p>\n\n\n
                                                                      git reset HEAD~1\n<\/code><\/span><\/pre>\n\n\n
                                                                      Keeps changes unstaged.<\/p>\n\n\n\n
                                                                      Hard reset:<\/p>\n\n\n
                                                                      git reset --hard HEAD~1\n<\/code><\/span><\/pre>\n\n\n
                                                                      Deletes local changes.<\/p>\n\n\n\n
                                                                      Warning<\/h2>\n\n\n\n
                                                                      Never use reset --hard<\/code> casually.<\/p>\n\n\n\n
                                                                      Never force-push reset history to shared branches unless you fully understand the impact.<\/p>\n\n\n\n
                                                                      \n\n\n\n
                                                                      35. Tagging and release workflow<\/h1>\n\n\n\n
                                                                      Lightweight tag<\/h2>\n\n\n
                                                                      git<\/span> tag<\/span> v1<\/span>.2<\/span>.0<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
                                                                      Annotated tag<\/h2>\n\n\n
                                                                      git<\/span> tag<\/span> -a<\/span> v1<\/span>.2<\/span>.0<\/span> -m<\/span> \"Release<\/span> v1<\/span>.2<\/span>.0<\/span>\"\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
                                                                      Push tags<\/h2>\n\n\n
                                                                      git<\/span> push<\/span> origin<\/span> v1<\/span>.2<\/span>.0<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
                                                                      Recommended release tag format<\/h2>\n\n\n
                                                                      vMAJOR<\/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 version numbers in a way that communicates meaning about the underlying code and compatibility.<\/p>\n\n\n\n
                                                                      \n\n\n\n
                                                                      36. Release models<\/h1>\n\n\n\n
                                                                      Model A: Deploy every merge to main<\/h2>\n\n\n
                                                                      flowchart<\/span> LR<\/span>\n    A<\/span>[Merge to main]<\/span> --<\/span>> B<\/span>[CI]<\/span>\n    B<\/span> --<\/span>> C<\/span>[Deploy staging]<\/span>\n    C<\/span> --<\/span>> D<\/span>[Deploy production]<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
                                                                      Best for:<\/p>\n\n\n\n
                                                                        \n
                                                                      • SaaS<\/li>\n\n\n\n
                                                                      • APIs<\/li>\n\n\n\n
                                                                      • Internal tools<\/li>\n\n\n\n
                                                                      • Mature CI\/CD teams<\/li>\n<\/ul>\n\n\n\n
                                                                        \n\n\n\n
                                                                        Model B: Manual promotion<\/h2>\n\n\n
                                                                        flowchart<\/span> LR<\/span>\n    A<\/span>[Merge to main]<\/span> --<\/span>> B<\/span>[Deploy dev]<\/span>\n    B<\/span> --<\/span>> C<\/span>[Deploy staging]<\/span>\n    C<\/span> --<\/span>> D<\/span>[Manual approval]<\/span>\n    D<\/span> --<\/span>> E<\/span>[Deploy production]<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
                                                                        Best for:<\/p>\n\n\n\n
                                                                          \n
                                                                        • Enterprise services<\/li>\n\n\n\n
                                                                        • Moderate risk systems<\/li>\n\n\n\n
                                                                        • Teams needing approval gates<\/li>\n<\/ul>\n\n\n\n
                                                                          \n\n\n\n
                                                                          Model C: Release branch<\/h2>\n\n\n
                                                                          flowchart<\/span> LR<\/span>\n    A<\/span>[main\/develop]<\/span> --<\/span>> B<\/span>[release\/1.5.0]<\/span>\n    B<\/span> --<\/span>> C<\/span>[Bug fixes only]<\/span>\n    C<\/span> --<\/span>> D<\/span>[Tag v1.5.0]<\/span>\n    D<\/span> --<\/span>> E<\/span>[Production]<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
                                                                          Best for:<\/p>\n\n\n\n
                                                                            \n
                                                                          • Mobile apps<\/li>\n\n\n\n
                                                                          • Versioned software<\/li>\n\n\n\n
                                                                          • Slow release cycles<\/li>\n\n\n\n
                                                                          • Compliance-heavy products<\/li>\n<\/ul>\n\n\n\n
                                                                            \n\n\n\n
                                                                            Model D: GitOps environment branches<\/h2>\n\n\n
                                                                            main\nenv\/dev\nenv\/staging\nenv\/prod\n<\/code><\/span><\/pre>\n\n
                                                                            flowchart<\/span> TD<\/span>\n    A<\/span>[Application source repo]<\/span> --<\/span>> B<\/span>[Build image]<\/span>\n    B<\/span> --<\/span>> C<\/span>[Update GitOps repo]<\/span>\n    C<\/span> --<\/span>> D<\/span>[env\/dev]<\/span>\n    D<\/span> --<\/span>> E<\/span>[env\/staging]<\/span>\n    E<\/span> --<\/span>> F<\/span>[env\/prod]<\/span>\n    F<\/span> --<\/span>> G<\/span>[Argo CD \/ Flux deploys]<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
                                                                            Best for:<\/p>\n\n\n\n
                                                                              \n
                                                                            • Kubernetes<\/li>\n\n\n\n
                                                                            • Argo CD<\/li>\n\n\n\n
                                                                            • Flux<\/li>\n\n\n\n
                                                                            • Platform teams<\/li>\n\n\n\n
                                                                            • Environment-specific promotion<\/li>\n<\/ul>\n\n\n\n
                                                                              \n\n\n\n
                                                                              37. CI\/CD integration<\/h1>\n\n\n\n
                                                                              A Git workflow is incomplete without CI\/CD.<\/p>\n\n\n\n
                                                                              Minimum CI checks<\/h2>\n\n\n
                                                                              flowchart<\/span> TD<\/span>\n    A<\/span>[Pull Request]<\/span> --<\/span>> B<\/span>[Checkout code]<\/span>\n    B<\/span> --<\/span>> C<\/span>[Install dependencies]<\/span>\n    C<\/span> --<\/span>> D<\/span>[Lint]<\/span>\n    D<\/span> --<\/span>> E<\/span>[Unit tests]<\/span>\n    E<\/span> --<\/span>> F<\/span>[Build]<\/span>\n    F<\/span> --<\/span>> G<\/span>[Security scan]<\/span>\n    G<\/span> --<\/span>> H<\/span>[Integration tests]<\/span>\n    H<\/span> --<\/span>> I<\/span>[Result: pass\/fail]<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
                                                                              For application repos<\/h2>\n\n\n\n
                                                                              Check<\/th>Purpose<\/th><\/tr><\/thead>
                                                                              Format<\/td>Consistent style<\/td><\/tr>
                                                                              Lint<\/td>Static mistakes<\/td><\/tr>
                                                                              Unit test<\/td>Code correctness<\/td><\/tr>
                                                                              Integration test<\/td>Component behavior<\/td><\/tr>
                                                                              Build<\/td>Package validity<\/td><\/tr>
                                                                              Secret scan<\/td>Prevent leaked keys<\/td><\/tr>
                                                                              SAST<\/td>Static security<\/td><\/tr>
                                                                              Dependency scan<\/td>Vulnerable libraries<\/td><\/tr>
                                                                              Container scan<\/td>Image vulnerabilities<\/td><\/tr>
                                                                              License scan<\/td>Compliance<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                                                                              For Terraform\/IaC repos<\/h2>\n\n\n\n
                                                                              Check<\/th>Purpose<\/th><\/tr><\/thead>
                                                                              terraform fmt<\/code><\/td>Formatting<\/td><\/tr>
                                                                              terraform validate<\/code><\/td>Syntax\/provider validation<\/td><\/tr>
                                                                              terraform plan<\/code><\/td>Review infra change<\/td><\/tr>
                                                                              TFLint<\/td>Best practices<\/td><\/tr>
                                                                              Checkov\/tfsec<\/td>Security<\/td><\/tr>
                                                                              Infracost<\/td>Cost visibility<\/td><\/tr>
                                                                              OPA\/Conftest<\/td>Policy checks<\/td><\/tr>
                                                                              Manual approval<\/td>Production safety<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                                                                              For Kubernetes repos<\/h2>\n\n\n\n
                                                                              Check<\/th>Purpose<\/th><\/tr><\/thead>
                                                                              YAML lint<\/td>Syntax<\/td><\/tr>
                                                                              kubeconform\/kubeval<\/td>Schema validation<\/td><\/tr>
                                                                              Helm lint<\/td>Chart validity<\/td><\/tr>
                                                                              Kustomize build<\/td>Render validation<\/td><\/tr>
                                                                              Conftest\/OPA<\/td>Policy<\/td><\/tr>
                                                                              Polaris\/Kyverno<\/td>Best practices<\/td><\/tr>
                                                                              Image scan<\/td>Supply chain security<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                                                                              \n\n\n\n
                                                                              38. Git workflow for infrastructure teams<\/h1>\n\n\n\n
                                                                              Infrastructure Git workflow must be stricter than application workflow because mistakes can delete production resources.<\/p>\n\n\n\n
                                                                              Recommended IaC workflow<\/h2>\n\n\n
                                                                              flowchart<\/span> TD<\/span>\n    A<\/span>[Create branch]<\/span> --<\/span>> B<\/span>[Edit Terraform]<\/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>[Open PR]<\/span>\n    E<\/span> --<\/span>> F<\/span>[CI plan]<\/span>\n    F<\/span> --<\/span>> G<\/span>[Security\/cost checks]<\/span>\n    G<\/span> --<\/span>> H<\/span>[Review plan output]<\/span>\n    H<\/span> --<\/span>> I<\/span>[Approve]<\/span>\n    I<\/span> --<\/span>> J<\/span>[Merge]<\/span>\n    J<\/span> --<\/span>> K<\/span>[Apply via pipeline]<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
                                                                              IaC branch policy<\/h2>\n\n\n\n
                                                                              Branch<\/th>Purpose<\/th><\/tr><\/thead>
                                                                              main<\/code><\/td>Source of truth<\/td><\/tr>
                                                                              feature\/*<\/code><\/td>Infra change<\/td><\/tr>
                                                                              hotfix\/*<\/code><\/td>Emergency infra fix<\/td><\/tr>
                                                                              env\/*<\/code><\/td>Optional environment branch model<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                                                                              IaC PR must include<\/h2>\n\n\n\n
                                                                                \n
                                                                              • Terraform plan<\/li>\n\n\n\n
                                                                              • Risk summary<\/li>\n\n\n\n
                                                                              • Blast radius<\/li>\n\n\n\n
                                                                              • Rollback plan<\/li>\n\n\n\n
                                                                              • State impact<\/li>\n\n\n\n
                                                                              • Resource replacement warning<\/li>\n\n\n\n
                                                                              • Cost impact<\/li>\n\n\n\n
                                                                              • Security impact<\/li>\n<\/ul>\n\n\n\n
                                                                                Dangerous Terraform PR signs<\/h2>\n\n\n
                                                                                -\/+ resource replacement\ndestroy\nforces replacement\npublic<\/span> access\n0.0<\/span>.0<\/span>.0<\/span>\/0<\/span>\ndelete database\nrecreate cluster\nchange encryption key\nremove backup\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
                                                                                \n\n\n\n
                                                                                39. Git workflow for Kubernetes teams<\/h1>\n\n\n\n
                                                                                Kubernetes workflow should separate:<\/p>\n\n\n\n
                                                                                  \n
                                                                                1. Application source<\/li>\n\n\n\n
                                                                                2. Container image<\/li>\n\n\n\n
                                                                                3. Deployment manifests<\/li>\n\n\n\n
                                                                                4. GitOps promotion<\/li>\n<\/ol>\n\n\n
                                                                                  flowchart<\/span> LR<\/span>\n    A<\/span>[App repo]<\/span> --<\/span>> B<\/span>[Build image]<\/span>\n    B<\/span> --<\/span>> C<\/span>[Push image tag]<\/span>\n    C<\/span> --<\/span>> D<\/span>[GitOps repo PR]<\/span>\n    D<\/span> --<\/span>> E<\/span>[Merge env\/dev]<\/span>\n    E<\/span> --<\/span>> F<\/span>[Promote staging]<\/span>\n    F<\/span> --<\/span>> G<\/span>[Promote prod]<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
                                                                                  Recommended image tag strategy<\/h2>\n\n\n\n
                                                                                  Use immutable tags:<\/p>\n\n\n
                                                                                  app<\/span>:v1.4.2<\/span>\napp<\/span>:git-sha-abc1234<\/span>\napp<\/span>:2026-07-07-abc1234<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
                                                                                  Avoid relying only on:<\/p>\n\n\n
                                                                                  latest\n<\/code><\/span><\/pre>\n\n\n
                                                                                  Kubernetes GitOps branch models<\/h2>\n\n\n\n
                                                                                  Option A: Folder per environment<\/h3>\n\n\n
                                                                                  clusters\/\n  dev\/\n  staging\/\n  prod\/\n<\/code><\/span><\/pre>\n\n\n
                                                                                  Option B: Branch per environment<\/h3>\n\n\n
                                                                                  env\/dev\nenv\/staging\nenv\/prod\n<\/code><\/span><\/pre>\n\n\n
                                                                                  Option C: Directory per cluster<\/h3>\n\n\n
                                                                                  clusters\/\n  ap-northeast-1\/dev\/\n  ap-northeast-1\/prod\/\n<\/code><\/span><\/pre>\n\n\n
                                                                                  For most teams, folder per environment<\/strong> is simpler than branch per environment.<\/p>\n\n\n\n
                                                                                  \n\n\n\n
                                                                                  40. Monorepo Git workflow<\/h1>\n\n\n\n
                                                                                  A monorepo has many services in one repository.<\/p>\n\n\n
                                                                                  repo\/\n  services\/\n    auth\/\n    payment\/\n    telematics\/\n  libs\/\n    common\/\n  infra\/\n  docs\/\n<\/code><\/span><\/pre>\n\n\n
                                                                                  Monorepo workflow rules<\/h2>\n\n\n\n
                                                                                  Problem<\/th>Solution<\/th><\/tr><\/thead>
                                                                                  Too many CI jobs<\/td>Path-based CI<\/td><\/tr>
                                                                                  Too many reviewers<\/td>CODEOWNERS<\/td><\/tr>
                                                                                  Slow builds<\/td>Build affected projects only<\/td><\/tr>
                                                                                  Risky shared libraries<\/td>Strong tests<\/td><\/tr>
                                                                                  Large PRs<\/td>Smaller changes<\/td><\/tr>
                                                                                  Ownership confusion<\/td>Directory ownership<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                                                                                  CODEOWNERS example<\/h2>\n\n\n
                                                                                  \/services\/auth\/ @auth-team\n\/services\/payment\/ @payment-team\n\/infra\/ @platform-team\n\/.github\/workflows\/ @devops-team\n<\/code><\/span><\/pre>\n\n\n
                                                                                  Monorepo PR checklist<\/h2>\n\n\n\n
                                                                                    \n
                                                                                  • Which service changed?<\/li>\n\n\n\n
                                                                                  • Which shared libraries changed?<\/li>\n\n\n\n
                                                                                  • Which downstream services may break?<\/li>\n\n\n\n
                                                                                  • Which CI jobs are required?<\/li>\n\n\n\n
                                                                                  • Which owners must review?<\/li>\n<\/ul>\n\n\n\n
                                                                                    \n\n\n\n
                                                                                    41. Branch by abstraction<\/h1>\n\n\n\n
                                                                                    Branch by abstraction is an advanced trunk-based technique.<\/p>\n\n\n\n
                                                                                    Instead of creating a long branch for a big rewrite, create an abstraction layer and migrate gradually.<\/p>\n\n\n
                                                                                    flowchart<\/span> TD<\/span>\n    A<\/span>[Old implementation]<\/span> --<\/span>> B<\/span>[Introduce interface\/abstraction]<\/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
                                                                                    PaymentGateway interface<\/span>\n \u251c\u2500\u2500 OldStripeGateway<\/span>\n \u2514\u2500\u2500 NewAdyenGateway<\/span>\n<\/span><\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
                                                                                    Feature flag:<\/p>\n\n\n
                                                                                    payment.provider = stripe | adyen\n<\/code><\/span><\/pre>\n\n\n
                                                                                    This allows incomplete work to merge safely into main<\/code>.<\/p>\n\n\n\n
                                                                                    The trunk-based development reference lists branch by abstraction as one of the techniques used to avoid long-lived development branches.<\/p>\n\n\n\n
                                                                                    \n\n\n\n
                                                                                    42. Feature flags and Git workflow<\/h1>\n\n\n\n
                                                                                    Feature flags separate merge<\/strong> from release<\/strong>.<\/p>\n\n\n\n
                                                                                    Without feature flags:<\/p>\n\n\n
                                                                                    Merge = users get<\/span> feature\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                                                                                    With feature flags:<\/p>\n\n\n
                                                                                    Merge = code integrated\nRelease = flag enabled\n<\/code><\/span><\/pre>\n\n
                                                                                    flowchart<\/span> LR<\/span>\n    A<\/span>[Code merged to main]<\/span> --<\/span>> B<\/span>[Feature flag OFF]<\/span>\n    B<\/span> --<\/span>> C<\/span>[Deploy safely]<\/span>\n    C<\/span> --<\/span>> D<\/span>[Enable for internal users]<\/span>\n    D<\/span> --<\/span>> E<\/span>[Enable for 10%]<\/span>\n    E<\/span> --<\/span>> F<\/span>[Enable for 100%]<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
                                                                                    Feature flag types<\/h2>\n\n\n\n
                                                                                    Type<\/th>Purpose<\/th><\/tr><\/thead>
                                                                                    Release flag<\/td>Hide incomplete feature<\/td><\/tr>
                                                                                    Experiment flag<\/td>A\/B testing<\/td><\/tr>
                                                                                    Ops flag<\/td>Kill switch<\/td><\/tr>
                                                                                    Permission flag<\/td>Customer\/role access<\/td><\/tr>
                                                                                    Migration flag<\/td>Gradual backend switch<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                                                                                    Feature flag rules<\/h2>\n\n\n\n
                                                                                      \n
                                                                                    • Every flag must have an owner.<\/li>\n\n\n\n
                                                                                    • Every flag must have an expiry date.<\/li>\n\n\n\n
                                                                                    • Old flags must be removed.<\/li>\n\n\n\n
                                                                                    • Flags must be observable.<\/li>\n\n\n\n
                                                                                    • Critical flags need audit logs.<\/li>\n<\/ul>\n\n\n\n
                                                                                      \n\n\n\n
                                                                                      43. Hotfix workflow<\/h1>\n\n\n\n
                                                                                      Hotfix in simple main-based workflow<\/h2>\n\n\n
                                                                                      flowchart<\/span> TD<\/span>\n    A<\/span>[Production incident]<\/span> --<\/span>> B<\/span>[Create hotfix branch from main or prod tag]<\/span>\n    B<\/span> --<\/span>> C<\/span>[Fix]<\/span>\n    C<\/span> --<\/span>> D<\/span>[Emergency PR]<\/span>\n    D<\/span> --<\/span>> E<\/span>[CI critical tests]<\/span>\n    E<\/span> --<\/span>> F<\/span>[Merge]<\/span>\n    F<\/span> --<\/span>> G<\/span>[Deploy]<\/span>\n    G<\/span> --<\/span>> H<\/span>[Tag patch release]<\/span>\n    H<\/span> --<\/span>> I<\/span>[Postmortem]<\/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 main\ngit pull --ff-only origin main\ngit checkout -b hotfix\/fix-payment-crash\n\n# fix<\/span>\ngit commit -am \"fix(payment): prevent crash on missing token\"<\/span>\n\ngit push -u origin hotfix\/fix-payment-crash\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<\/span> checkout<\/span> main<\/span>\ngit<\/span> pull<\/span> --ff-only<\/span>\ngit<\/span> tag<\/span> -a<\/span> v1<\/span>.4<\/span>.1<\/span> -m<\/span> \"Hotfix<\/span> v1<\/span>.4<\/span>.1<\/span>\"\ngit<\/span> push<\/span> origin<\/span> v1<\/span>.4<\/span>.1<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
                                                                                      Hotfix in Gitflow<\/h2>\n\n\n\n
                                                                                      Hotfix branches start from main<\/code>, then merge back to both main<\/code> and develop<\/code>.<\/p>\n\n\n
                                                                                      flowchart<\/span> TD<\/span>\n    A<\/span>[main production]<\/span> --<\/span>> B<\/span>[hotfix\/1.4.1]<\/span>\n    B<\/span> --<\/span>> C<\/span>[Fix + test]<\/span>\n    C<\/span> --<\/span>> D<\/span>[Merge to main]<\/span>\n    D<\/span> --<\/span>> E<\/span>[Tag v1.4.1]<\/span>\n    C<\/span> --<\/span>> F<\/span>[Merge to develop]<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
                                                                                      \n\n\n\n
                                                                                      44. Release branch workflow<\/h1>\n\n\n\n
                                                                                      Use release branches when production needs stabilization before release.<\/p>\n\n\n
                                                                                      gitGraph\n    commit id: \"dev-1\"<\/span>\n    commit id: \"dev-2\"<\/span>\n    branch release\/2.0<\/span>.0<\/span>\n    checkout release\/2.0<\/span>.0<\/span>\n    commit id: \"fix-rc1\"<\/span>\n    commit id: \"fix-rc2\"<\/span>\n    checkout main\n    merge release\/2.0<\/span>.0<\/span> tag: \"v2.0.0\"<\/span>\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                                                                                      Release branch rules<\/h2>\n\n\n\n
                                                                                      Allowed:<\/p>\n\n\n\n
                                                                                        \n
                                                                                      • Bug fixes<\/li>\n\n\n\n
                                                                                      • Version bumps<\/li>\n\n\n\n
                                                                                      • Release notes<\/li>\n\n\n\n
                                                                                      • Stabilization<\/li>\n\n\n\n
                                                                                      • Documentation updates<\/li>\n<\/ul>\n\n\n\n
                                                                                        Not allowed:<\/p>\n\n\n\n
                                                                                          \n
                                                                                        • New features<\/li>\n\n\n\n
                                                                                        • Big refactors<\/li>\n\n\n\n
                                                                                        • Risky dependency upgrades<\/li>\n\n\n\n
                                                                                        • Experimental changes<\/li>\n<\/ul>\n\n\n\n
                                                                                          \n\n\n\n
                                                                                          45. Backport workflow<\/h1>\n\n\n\n
                                                                                          Backport means applying a fix from newer code to an older supported release.<\/p>\n\n\n
                                                                                          flowchart<\/span> LR<\/span>\n    A<\/span>[Fix in main]<\/span> --<\/span>> B<\/span>[Cherry-pick to release\/1.5]<\/span>\n    A<\/span> --<\/span>> C<\/span>[Cherry-pick to release\/1.4]<\/span>\n    B<\/span> --<\/span>> D<\/span>[Tag v1.5.3]<\/span>\n    C<\/span> --<\/span>> E<\/span>[Tag v1.4.9]<\/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\/1.5\ngit cherry-pick <fix-commit-sha<\/span>><\/span>\ngit push origin release\/1.5\n<\/code><\/span>Code language:<\/span> HTML, XML<\/span> (<\/span>xml<\/span>)<\/span><\/small><\/pre>\n\n\n
                                                                                          Backport PR title:<\/p>\n\n\n
                                                                                          [Backport release\/1.5]<\/span> fix<\/span>(auth<\/span>): handle<\/span> expired<\/span> token<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
                                                                                          \n\n\n\n
                                                                                          46. Rollback strategy<\/h1>\n\n\n\n
                                                                                          There are four common rollback methods.<\/p>\n\n\n\n
                                                                                          Rollback type<\/th>How<\/th>Best for<\/th><\/tr><\/thead>
                                                                                          Git revert<\/td>git revert<\/code><\/td>Bad code commit<\/td><\/tr>
                                                                                          Redeploy previous artifact<\/td>Deploy old image\/package<\/td>Bad deployment<\/td><\/tr>
                                                                                          Disable feature flag<\/td>Turn flag off<\/td>Bad feature<\/td><\/tr>
                                                                                          Database rollback\/fix-forward<\/td>Migration strategy<\/td>Data issues<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                                                                                          Best production rollback model<\/h2>\n\n\n
                                                                                          flowchart TD\n    A[Incident detected] --> B{Feature flag?}\n    B -- Yes --> C[Disable flag]\n    B -- No --> D{Bad deploy artifact?}\n    D -- Yes --> E[Redeploy previous artifact]\n    D -- No --> F{Bad commit?}\n    F -- Yes --> G[Revert commit]\n    F -- No --> H[Fix forward]\n<\/code><\/span><\/pre>\n\n\n
                                                                                          \n\n\n\n
                                                                                          47. Database migration workflow<\/h1>\n\n\n\n
                                                                                          Database changes are where Git workflow often becomes dangerous.<\/p>\n\n\n\n
                                                                                          Safe migration pattern<\/h2>\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 app compatible with old and new]<\/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>[Remove old schema]<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
                                                                                          Example<\/h2>\n\n\n\n
                                                                                          Bad:<\/p>\n\n\n
                                                                                          ALTER TABLE users DROP COLUMN name;\n<\/code><\/span><\/pre>\n\n\n
                                                                                          Good:<\/p>\n\n\n\n
                                                                                            \n
                                                                                          1. Add new column.<\/li>\n\n\n\n
                                                                                          2. Deploy code that writes both old and new.<\/li>\n\n\n\n
                                                                                          3. Backfill.<\/li>\n\n\n\n
                                                                                          4. Switch reads to new column.<\/li>\n\n\n\n
                                                                                          5. Wait.<\/li>\n\n\n\n
                                                                                          6. Drop old column later.<\/li>\n<\/ol>\n\n\n\n
                                                                                            Database PR must include<\/h2>\n\n\n\n
                                                                                              \n
                                                                                            • Migration direction<\/li>\n\n\n\n
                                                                                            • Rollback safety<\/li>\n\n\n\n
                                                                                            • Backfill plan<\/li>\n\n\n\n
                                                                                            • Locking risk<\/li>\n\n\n\n
                                                                                            • Data volume estimate<\/li>\n\n\n\n
                                                                                            • Production execution plan<\/li>\n<\/ul>\n\n\n\n
                                                                                              \n\n\n\n
                                                                                              48. Security workflow<\/h1>\n\n\n\n
                                                                                              Git workflow must prevent secrets and unsafe code from reaching the repository.<\/p>\n\n\n\n
                                                                                              Security checks before merge<\/h2>\n\n\n\n
                                                                                              Check<\/th>Why<\/th><\/tr><\/thead>
                                                                                              Secret scanning<\/td>Prevent leaked credentials<\/td><\/tr>
                                                                                              Dependency scanning<\/td>Detect vulnerable libraries<\/td><\/tr>
                                                                                              SAST<\/td>Detect code-level security issues<\/td><\/tr>
                                                                                              IaC scanning<\/td>Detect cloud misconfigurations<\/td><\/tr>
                                                                                              Container scanning<\/td>Detect vulnerable images<\/td><\/tr>
                                                                                              License scanning<\/td>Avoid legal risk<\/td><\/tr>
                                                                                              CODEOWNERS<\/td>Require expert review<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                                                                                              Never commit<\/h2>\n\n\n
                                                                                              .env\nprivate<\/span> keys\nAWS credentials\nGCP service account keys\nSSH private<\/span> keys\ndatabase dumps\ncustomer data\nproduction kubeconfig\nTerraform state files\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
                                                                                              Add protection<\/h2>\n\n\n
                                                                                              git-secrets\npre-commit\ndetect-secrets\ngitleaks\ntrufflehog\n<\/code><\/span><\/pre>\n\n\n
                                                                                              \n\n\n\n
                                                                                              49. Pre-commit hooks<\/h1>\n\n\n\n
                                                                                              Pre-commit hooks catch issues before code leaves the laptop.<\/p>\n\n\n\n
                                                                                              Example .pre-commit-config.yaml<\/code>:<\/p>\n\n\n
                                                                                              repos:\n  - repo: https:\/\/github.com\/pre-commit\/pre-commit-hooks<\/span>\n    rev: v5.0<\/span>.0<\/span>\n    hooks:\n      - id: trailing-whitespace\n      - id: end-of-file-fixer\n      - id: check-yaml\n      - id: check-json\n      - id: detect-private<\/span>-key\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
                                                                                              Install:<\/p>\n\n\n
                                                                                              pip install pre-commit\npre-commit install\npre-commit run --all-files\n<\/code><\/span><\/pre>\n\n\n
                                                                                              \n\n\n\n
                                                                                              50. Git workflow for open source<\/h1>\n\n\n\n
                                                                                              Open-source projects often use fork-based workflow.<\/p>\n\n\n
                                                                                              flowchart<\/span> LR<\/span>\n    A<\/span>[Upstream repo]<\/span> --<\/span>> B<\/span>[User fork]<\/span>\n    B<\/span> --<\/span>> C<\/span>[Feature branch in fork]<\/span>\n    C<\/span> --<\/span>> D<\/span>[Pull request to upstream]<\/span>\n    D<\/span> --<\/span>> E<\/span>[Maintainer review]<\/span>\n    E<\/span> --<\/span>> F<\/span>[Merge]<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
                                                                                              Contributor commands:<\/p>\n\n\n
                                                                                              git clone <your-fork-url<\/span>><\/span>\ncd project\ngit remote add upstream <original-project-url<\/span>><\/span>\ngit fetch upstream\ngit checkout -b fix\/readme-typo upstream\/main\n<\/code><\/span>Code language:<\/span> HTML, XML<\/span> (<\/span>xml<\/span>)<\/span><\/small><\/pre>\n\n\n
                                                                                              Sync fork:<\/p>\n\n\n
                                                                                              git fetch upstream\ngit checkout main\ngit merge upstream\/main\ngit push origin main\n<\/code><\/span><\/pre>\n\n\n
                                                                                              \n\n\n\n
                                                                                              51. Git workflow for emergency production incidents<\/h1>\n\n\n\n
                                                                                              During an incident, optimize for:<\/p>\n\n\n\n
                                                                                                \n
                                                                                              1. Safety<\/li>\n\n\n\n
                                                                                              2. Speed<\/li>\n\n\n\n
                                                                                              3. Traceability<\/li>\n\n\n\n
                                                                                              4. Rollback<\/li>\n\n\n\n
                                                                                              5. Communication<\/li>\n<\/ol>\n\n\n\n
                                                                                                Incident hotfix flow<\/h2>\n\n\n
                                                                                                sequenceDiagram\n    participant Dev as<\/span> Developer\n    participant Git as<\/span> Git Repo\n    participant CI as<\/span> CI Pipeline\n    participant Prod as<\/span> Production\n\n    Dev->>Git: Create hotfix branch\n    Dev->>Git: Commit minimal fix\n    Dev->>Git: Open emergency PR\n    CI->>Git: Run critical checks\n    Git->>Prod: Deploy after approval\n    Prod->>Dev: Validate metrics\/logs\n    Dev->>Git: Tag release\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                                                                                                Emergency PR template<\/h2>\n\n\n
                                                                                                ## Incident<\/span>\n\nProduction issue:\n\n## Root cause<\/span>\n\nKnown \/ suspected:\n\n## Fix<\/span>\n\nMinimal change:\n\n## Validation<\/span>\n\n- [ ] Critical tests passed\n- [ ] Staging validated\n- [ ] Production smoke test ready\n\n## Rollback<\/span>\n\nExact rollback command or<\/span> plan:\n\n## Follow-up<\/span>\n\nPost-incident cleanup ticket:\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
                                                                                                \n\n\n\n
                                                                                                52. Git workflow anti-patterns<\/h1>\n\n\n\n
                                                                                                Anti-pattern 1: Long-lived feature branches<\/h2>\n\n\n
                                                                                                feature\/big-rewrite lives for 2 months\n<\/code><\/span><\/pre>\n\n\n
                                                                                                Result:<\/p>\n\n\n\n
                                                                                                  \n
                                                                                                • Huge merge conflicts<\/li>\n\n\n\n
                                                                                                • Delayed feedback<\/li>\n\n\n\n
                                                                                                • Broken assumptions<\/li>\n\n\n\n
                                                                                                • Big-bang release risk<\/li>\n<\/ul>\n\n\n\n
                                                                                                  Fix:<\/p>\n\n\n\n
                                                                                                    \n
                                                                                                  • Split work<\/li>\n\n\n\n
                                                                                                  • Use feature flags<\/li>\n\n\n\n
                                                                                                  • Use branch by abstraction<\/li>\n\n\n\n
                                                                                                  • Merge smaller PRs<\/li>\n<\/ul>\n\n\n\n
                                                                                                    \n\n\n\n
                                                                                                    Anti-pattern 2: Shared develop branch without discipline<\/h2>\n\n\n\n
                                                                                                    develop<\/code> can become a dumping ground.<\/p>\n\n\n\n
                                                                                                    Symptoms:<\/p>\n\n\n\n
                                                                                                      \n
                                                                                                    • Always unstable<\/li>\n\n\n\n
                                                                                                    • Nobody owns it<\/li>\n\n\n\n
                                                                                                    • Hard to release<\/li>\n\n\n\n
                                                                                                    • Test failures ignored<\/li>\n<\/ul>\n\n\n\n
                                                                                                      Fix:<\/p>\n\n\n\n
                                                                                                        \n
                                                                                                      • Protect develop<\/code><\/li>\n\n\n\n
                                                                                                      • Require PRs<\/li>\n\n\n\n
                                                                                                      • Require CI<\/li>\n\n\n\n
                                                                                                      • Consider removing it if not needed<\/li>\n<\/ul>\n\n\n\n
                                                                                                        \n\n\n\n
                                                                                                        Anti-pattern 3: \u201cFix directly on server\u201d<\/h2>\n\n\n\n
                                                                                                        Never hotfix production manually without Git.<\/p>\n\n\n\n
                                                                                                        Bad:<\/p>\n\n\n
                                                                                                        SSH to server\nvim file\nrestart service\n<\/code><\/span><\/pre>\n\n\n
                                                                                                        Good:<\/p>\n\n\n
                                                                                                        hotfix branch \u2192 PR \u2192 CI \u2192 deploy \u2192 tag\n<\/code><\/span><\/pre>\n\n\n
                                                                                                        \n\n\n\n
                                                                                                        Anti-pattern 4: Giant PR<\/h2>\n\n\n\n
                                                                                                        Symptoms:<\/p>\n\n\n\n
                                                                                                          \n
                                                                                                        • Reviewers approve without understanding<\/li>\n\n\n\n
                                                                                                        • Bugs hidden in noise<\/li>\n\n\n\n
                                                                                                        • Rollback is hard<\/li>\n<\/ul>\n\n\n\n
                                                                                                          Fix:<\/p>\n\n\n\n
                                                                                                            \n
                                                                                                          • Split by behavior<\/li>\n\n\n\n
                                                                                                          • Split by layer<\/li>\n\n\n\n
                                                                                                          • Split by risk<\/li>\n\n\n\n
                                                                                                          • Use stacked PRs<\/li>\n<\/ul>\n\n\n\n
                                                                                                            \n\n\n\n
                                                                                                            Anti-pattern 5: Merge without green CI<\/h2>\n\n\n\n
                                                                                                            This destroys trust.<\/p>\n\n\n\n
                                                                                                            Rule:<\/p>\n\n\n
                                                                                                            Red CI means stop.\nGreen CI means continue<\/span>.\nFlaky CI means fix CI.\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                                                                                                            \n\n\n\n
                                                                                                            Anti-pattern 6: Feature branches used as environments<\/h2>\n\n\n\n
                                                                                                            Bad:<\/p>\n\n\n
                                                                                                            branch dev\nbranch qa\nbranch staging\nbranch prod\n<\/code><\/span><\/pre>\n\n\n
                                                                                                            This can work in some GitLab Flow or GitOps models, but it becomes dangerous when teams randomly merge between branches without clear promotion rules.<\/p>\n\n\n\n
                                                                                                            Fix:<\/p>\n\n\n\n
                                                                                                              \n
                                                                                                            • Use environment folders<\/li>\n\n\n\n
                                                                                                            • Use deployment pipeline promotions<\/li>\n\n\n\n
                                                                                                            • Use tags\/artifacts<\/li>\n\n\n\n
                                                                                                            • Keep source branch strategy simple<\/li>\n<\/ul>\n\n\n\n
                                                                                                              \n\n\n\n
                                                                                                              53. Advanced PR splitting<\/h1>\n\n\n\n
                                                                                                              Large feature?<\/p>\n\n\n\n
                                                                                                              Do not create one huge PR.<\/p>\n\n\n\n
                                                                                                              Use this sequence:<\/p>\n\n\n
                                                                                                              flowchart<\/span> TD<\/span>\n    A<\/span>[PR 1: Add database column, unused]<\/span> --<\/span>> B<\/span>[PR 2: Add backend support behind flag]<\/span>\n    B<\/span> --<\/span>> C<\/span>[PR 3: Add API response field]<\/span>\n    C<\/span> --<\/span>> D<\/span>[PR 4: Add frontend hidden UI]<\/span>\n    D<\/span> --<\/span>> E<\/span>[PR 5: Enable for internal users]<\/span>\n    E<\/span> --<\/span>> F<\/span>[PR 6: Enable for all users]<\/span>\n    F<\/span> --<\/span>> G<\/span>[PR 7: Remove old path]<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
                                                                                                              Splitting strategies<\/h2>\n\n\n\n
                                                                                                              Strategy<\/th>Example<\/th><\/tr><\/thead>
                                                                                                              By layer<\/td>DB \u2192 backend \u2192 frontend<\/td><\/tr>
                                                                                                              By risk<\/td>Safe refactor \u2192 behavior change<\/td><\/tr>
                                                                                                              By flag<\/td>Hidden code \u2192 enabled code<\/td><\/tr>
                                                                                                              By endpoint<\/td>One endpoint per PR<\/td><\/tr>
                                                                                                              By module<\/td>One service\/package per PR<\/td><\/tr>
                                                                                                              By migration phase<\/td>Expand \u2192 migrate \u2192 contract<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                                                                                                              \n\n\n\n
                                                                                                              54. Stacked PR workflow<\/h1>\n\n\n\n
                                                                                                              Stacked PRs are useful when changes depend on each other.<\/p>\n\n\n
                                                                                                              gitGraph\n    commit id: \"main\"<\/span>\n    branch pr-1<\/span>-base-refactor\n    checkout pr-1<\/span>-base-refactor\n    commit id: \"refactor\"<\/span>\n    branch pr-2<\/span>-new<\/span>-api\n    checkout pr-2<\/span>-new<\/span>-api\n    commit id: \"api\"<\/span>\n    branch pr-3<\/span>-ui\n    checkout pr-3<\/span>-ui\n    commit id: \"ui\"<\/span>\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                                                                                                              Use stacked PRs when<\/h2>\n\n\n\n
                                                                                                                \n
                                                                                                              • A feature needs multiple dependent steps<\/li>\n\n\n\n
                                                                                                              • Each step can be reviewed separately<\/li>\n\n\n\n
                                                                                                              • You do not want one huge PR<\/li>\n<\/ul>\n\n\n\n
                                                                                                                Be careful<\/h2>\n\n\n\n
                                                                                                                Stacked PRs require discipline. Rebase carefully and keep reviewers informed.<\/p>\n\n\n\n
                                                                                                                \n\n\n\n
                                                                                                                55. Repository hygiene<\/h1>\n\n\n\n
                                                                                                                Delete merged branches<\/h2>\n\n\n
                                                                                                                git branch --merged\ngit branch -d feature\/old-branch\ngit push origin --delete<\/span> feature\/old-branch\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                                                                                                                Prune deleted remote branches<\/h2>\n\n\n
                                                                                                                git fetch --prune\n<\/code><\/span><\/pre>\n\n\n
                                                                                                                Find stale branches<\/h2>\n\n\n
                                                                                                                git branch -r --sort=committerdate\n<\/code><\/span><\/pre>\n\n\n
                                                                                                                Clean local untracked files<\/h2>\n\n\n\n
                                                                                                                Preview:<\/p>\n\n\n
                                                                                                                git clean -nd\n<\/code><\/span><\/pre>\n\n\n
                                                                                                                Delete:<\/p>\n\n\n
                                                                                                                git clean -fd\n<\/code><\/span><\/pre>\n\n\n
                                                                                                                \n\n\n\n
                                                                                                                56. Useful Git aliases<\/h1>\n\n\n
                                                                                                                git config --global<\/span> alias.st status\ngit config --global<\/span> alias.co checkout\ngit config --global<\/span> alias.br branch\ngit config --global<\/span> alias.cm commit\ngit config --global<\/span> alias.lg \"log --oneline --decorate --graph --all\"<\/span>\ngit config --global<\/span> alias.last \"log -1 HEAD --stat\"<\/span>\ngit config --global<\/span> alias.unstage \"restore --staged\"<\/span>\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
                                                                                                                Now:<\/p>\n\n\n
                                                                                                                git lg\ngit st\n<\/code><\/span><\/pre>\n\n\n
                                                                                                                \n\n\n\n
                                                                                                                57. Debugging with Git<\/h1>\n\n\n\n
                                                                                                                Find who changed a line<\/h2>\n\n\n
                                                                                                                git blame path\/to\/file\n<\/code><\/span><\/pre>\n\n\n
                                                                                                                Search history<\/h2>\n\n\n
                                                                                                                git log --grep=\"timeout\"<\/span>\ngit log -S \"functionName\"<\/span>\ngit log -- path\/to\/file\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                                                                                                                Find bad commit with bisect<\/h2>\n\n\n
                                                                                                                git<\/span> bisect<\/span> start<\/span>\ngit<\/span> bisect<\/span> bad<\/span>\ngit<\/span> bisect<\/span> good<\/span> v1<\/span>.2<\/span>.0<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
                                                                                                                Then Git walks you through commits.<\/p>\n\n\n\n
                                                                                                                Mark each:<\/p>\n\n\n
                                                                                                                git bisect good\ngit bisect bad\n<\/code><\/span><\/pre>\n\n\n
                                                                                                                Finish:<\/p>\n\n\n
                                                                                                                git bisect reset\n<\/code><\/span><\/pre>\n\n\n
                                                                                                                \n\n\n\n
                                                                                                                58. Clean history before PR<\/h1>\n\n\n\n
                                                                                                                Before opening PR:<\/p>\n\n\n
                                                                                                                git fetch origin\ngit rebase origin\/main\ngit log --oneline origin\/main..HEAD\n<\/code><\/span><\/pre>\n\n\n
                                                                                                                Interactive rebase:<\/p>\n\n\n
                                                                                                                git rebase -i origin\/main\n<\/code><\/span><\/pre>\n\n\n
                                                                                                                You can:<\/p>\n\n\n
                                                                                                                pick\nreword\nedit\nsquash\nfixup\ndrop\n<\/code><\/span><\/pre>\n\n\n
                                                                                                                Use it to clean local commits.<\/p>\n\n\n\n
                                                                                                                \n\n\n\n
                                                                                                                59. Example complete workflow: application team<\/h1>\n\n\n
                                                                                                                sequenceDiagram\n    participant Dev as<\/span> Developer\n    participant Git as<\/span> GitHub\/GitLab\n    participant CI as<\/span> CI\n    participant Staging as<\/span> Staging\n    participant Prod as<\/span> Production\n\n    Dev->>Git: Create feature branch\n    Dev->>Git: Push commits\n    Dev->>Git: Open PR\n    CI->>Git: Run tests and scans\n    Git->>Dev: Review comments\n    Dev->>Git: Push fixes\n    CI->>Git: Pass\n    Git->>Git: Merge to main\n    CI->>Staging: Deploy\n    Staging->>Prod: Promote after approval\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\ngit checkout -b feature\/EVP-123<\/span>-add-alerts\n\n# edit files<\/span>\ngit add .\ngit commit -m \"feat(alerts): add threshold alert config\"<\/span>\n\ngit push -u origin feature\/EVP-123<\/span>-add-alerts\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
                                                                                                                After review and merge:<\/p>\n\n\n
                                                                                                                git checkout main\ngit pull --ff-only origin main\ngit branch -d feature\/EVP-123-add-alerts\ngit fetch --prune\n<\/code><\/span><\/pre>\n\n\n
                                                                                                                \n\n\n\n
                                                                                                                60. Example complete workflow: Terraform team<\/h1>\n\n\n
                                                                                                                flowchart<\/span> TD<\/span>\n    A<\/span>[Ticket: add NAT Gateway]<\/span> --<\/span>> B<\/span>[Create branch]<\/span>\n    B<\/span> --<\/span>> C<\/span>[Edit Terraform]<\/span>\n    C<\/span> --<\/span>> D<\/span>[terraform fmt]<\/span>\n    D<\/span> --<\/span>> E<\/span>[terraform validate]<\/span>\n    E<\/span> --<\/span>> F<\/span>[Open PR]<\/span>\n    F<\/span> --<\/span>> G<\/span>[CI generates plan]<\/span>\n    G<\/span> --<\/span>> H<\/span>[Review resource changes]<\/span>\n    H<\/span> --<\/span>> I<\/span>[Security\/cost review]<\/span>\n    I<\/span> --<\/span>> J<\/span>[Approval]<\/span>\n    J<\/span> --<\/span>> K<\/span>[Merge]<\/span>\n    K<\/span> --<\/span>> L<\/span>[Apply through controlled pipeline]<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
                                                                                                                PR title<\/h2>\n\n\n
                                                                                                                feat(network)<\/span>: add NAT gateway per AZ for staging\n<\/code><\/span>Code language:<\/span> HTTP<\/span> (<\/span>http<\/span>)<\/span><\/small><\/pre>\n\n\n
                                                                                                                PR body<\/h2>\n\n\n
                                                                                                                ## Summary<\/span>\n\nAdds one NAT Gateway per AZ for<\/span> staging private<\/span> subnets.\n\n## Terraform plan summary<\/span>\n\n- Creates:\n  - 2<\/span> NAT Gateways\n  - 2<\/span> Elastic IP associations\n  - Route updates for<\/span> private<\/span> subnets\n\n## Risk<\/span>\n\nMedium. Route table changes affect outbound traffic from private<\/span> subnets.\n\n## Rollback<\/span>\n\nRevert PR and<\/span> re-apply previous Terraform configuration.\n\n## Validation<\/span>\n\n- terraform fmt\n- terraform validate\n- terraform plan\n- connectivity test from private<\/span> subnet\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
                                                                                                                \n\n\n\n
                                                                                                                61. Example complete workflow: Kubernetes GitOps team<\/h1>\n\n\n
                                                                                                                flowchart<\/span> LR<\/span>\n    A<\/span>[Code PR merged]<\/span> --<\/span>> B<\/span>[Build image sha-abc123]<\/span>\n    B<\/span> --<\/span>> C<\/span>[Open GitOps PR]<\/span>\n    C<\/span> --<\/span>> D<\/span>[Update dev manifest]<\/span>\n    D<\/span> --<\/span>> E<\/span>[Argo CD sync dev]<\/span>\n    E<\/span> --<\/span>> F<\/span>[Promote same image to staging]<\/span>\n    F<\/span> --<\/span>> G<\/span>[Promote same image to prod]<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
                                                                                                                Important rule<\/h2>\n\n\n\n
                                                                                                                Build once, promote the same artifact.<\/p>\n\n\n\n
                                                                                                                Bad:<\/p>\n\n\n
                                                                                                                Build separate image for dev, staging, prod\n<\/code><\/span><\/pre>\n\n\n
                                                                                                                Good:<\/p>\n\n\n
                                                                                                                Build one immutable image and promote it\n<\/code><\/span><\/pre>\n\n\n
                                                                                                                \n\n\n\n
                                                                                                                62. Team policy: recommended default<\/h1>\n\n\n\n
                                                                                                                Use this as an internal engineering standard.<\/p>\n\n\n\n
                                                                                                                Branches<\/h2>\n\n\n
                                                                                                                main\nfeature\/*\nbugfix\/*\nhotfix\/*\nrelease\/*\n<\/code><\/span><\/pre>\n\n\n
                                                                                                                Rules<\/h2>\n\n\n\n
                                                                                                                Rule<\/th>Policy<\/th><\/tr><\/thead>
                                                                                                                Direct push to main<\/code><\/td>Not allowed<\/td><\/tr>
                                                                                                                PR required<\/td>Yes<\/td><\/tr>
                                                                                                                CI required<\/td>Yes<\/td><\/tr>
                                                                                                                Review required<\/td>At least 1<\/td><\/tr>
                                                                                                                CODEOWNERS<\/td>Required for critical directories<\/td><\/tr>
                                                                                                                Squash merge<\/td>Default<\/td><\/tr>
                                                                                                                Release tags<\/td>Required for production<\/td><\/tr>
                                                                                                                Hotfix branch<\/td>Required for emergency fixes<\/td><\/tr>
                                                                                                                Branch deletion<\/td>Delete after merge<\/td><\/tr>
                                                                                                                Secrets scan<\/td>Required<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                                                                                                                Main branch definition<\/h2>\n\n\n
                                                                                                                main is always production-ready.\n<\/code><\/span><\/pre>\n\n\n
                                                                                                                Pull request definition<\/h2>\n\n\n
                                                                                                                A PR is not a storage place for unfinished work.\nA PR is a reviewable unit of change.\n<\/code><\/span><\/pre>\n\n\n
                                                                                                                Release definition<\/h2>\n\n\n
                                                                                                                A release is a tagged, traceable, deployable artifact.\n<\/code><\/span><\/pre>\n\n\n
                                                                                                                \n\n\n\n
                                                                                                                63. Choosing a workflow: final decision matrix<\/h1>\n\n\n\n
                                                                                                                Condition<\/th>Choose<\/th><\/tr><\/thead>
                                                                                                                New team, simple app<\/td>GitHub Flow<\/td><\/tr>
                                                                                                                Strong CI\/CD, frequent deploys<\/td>Trunk-based<\/td><\/tr>
                                                                                                                Need staging \u2192 prod promotion<\/td>GitLab Flow<\/td><\/tr>
                                                                                                                Versioned software with release windows<\/td>Gitflow<\/td><\/tr>
                                                                                                                Mobile app approval cycle<\/td>Gitflow or release branches<\/td><\/tr>
                                                                                                                Kubernetes GitOps<\/td>Main + environment folders<\/td><\/tr>
                                                                                                                Terraform infrastructure<\/td>Feature branch + protected main<\/td><\/tr>
                                                                                                                Highly regulated system<\/td>Gitflow or GitLab Flow with strict controls<\/td><\/tr>
                                                                                                                Monorepo<\/td>Trunk-based with CODEOWNERS<\/td><\/tr>
                                                                                                                Open source<\/td>Fork + PR workflow<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                                                                                                                \n\n\n\n
                                                                                                                64. The \u201cworld-class\u201d Git workflow blueprint<\/h1>\n\n\n\n
                                                                                                                This is the final architecture I recommend for serious teams.<\/p>\n\n\n
                                                                                                                flowchart TD\n    A[Work item created] --> B[Create short-lived branch]\n    B --> C[Local commits with<\/span> Conventional Commit style]\n    C --> D[Pre-commit checks]\n    D --> E[Push branch]\n    E --> F[Open PR\/MR]\n    F --> G[Automated CI]\n    F --> H[Code review]\n    G --> I{Checks pass?}\n    H --> J{Approved?}\n    I -- No --> C\n    J -- No --> C\n    I -- Yes --> K[Merge to protected main]\n    J -- Yes --> K\n    K --> L[Build immutable artifact]\n    L --> M[Deploy to dev\/staging]\n    M --> N{Production approval or auto-deploy?}\n    N -- Approval --> O[Deploy production]\n    N -- Auto --> O\n    O --> P[Tag release]\n    P --> Q[Monitor]\n    Q --> R{Issue?}\n    R -- Yes --> S[Rollback\/revert\/hotfix]\n    R -- No --> T[Done]\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                                                                                                                Blueprint policies<\/h2>\n\n\n\n
                                                                                                                Branching<\/h3>\n\n\n
                                                                                                                main\nfeature\/<ticket<\/span>><\/span>-<description<\/span>><\/span>\nbugfix\/<ticket<\/span>><\/span>-<description<\/span>><\/span>\nhotfix\/<ticket<\/span>><\/span>-<description<\/span>><\/span>\nrelease\/<version<\/span>><\/span>\n<\/code><\/span>Code language:<\/span> HTML, XML<\/span> (<\/span>xml<\/span>)<\/span><\/small><\/pre>\n\n\n
                                                                                                                Commit format<\/h3>\n\n\n
                                                                                                                feat(scope)<\/span>: summary\nfix(scope)<\/span>: summary\nchore(scope)<\/span>: summary\ndocs(scope)<\/span>: summary\n<\/code><\/span>Code language:<\/span> HTTP<\/span> (<\/span>http<\/span>)<\/span><\/small><\/pre>\n\n\n
                                                                                                                Merge strategy<\/h3>\n\n\n
                                                                                                                Default<\/span>: squash merge\nExceptions: release branches and<\/span> complex audited features may use<\/span> merge<\/span> commits<\/span>\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
                                                                                                                Release strategy<\/h3>\n\n\n
                                                                                                                Every production deployment maps to:\n- Git commit SHA\n- Build artifact\n- Container image digest\n- Git tag or release record\n- CI\/CD run\n- Approver, if manual approval exists\n<\/code><\/span><\/pre>\n\n\n
                                                                                                                CI\/CD gates<\/h3>\n\n\n
                                                                                                                No green CI, no merge.\nNo review, no merge.\nNo rollback plan, no production release.\n<\/code><\/span><\/pre>\n\n\n
                                                                                                                \n\n\n\n
                                                                                                                65. Git command cheat sheet<\/h1>\n\n\n\n
                                                                                                                Daily commands<\/h2>\n\n\n
                                                                                                                git status\ngit fetch origin\ngit pull --ff-only\ngit checkout -b feature\/name\ngit add .\ngit commit -m \"feat: message\"<\/span>\ngit push -u origin feature\/name\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                                                                                                                History<\/h2>\n\n\n
                                                                                                                git log --oneline --decorate --graph --all\ngit show <sha<\/span>><\/span>\ngit diff\ngit diff main...HEAD\n<\/code><\/span>Code language:<\/span> HTML, XML<\/span> (<\/span>xml<\/span>)<\/span><\/small><\/pre>\n\n\n
                                                                                                                Branches<\/h2>\n\n\n
                                                                                                                git branch\ngit branch -a\ngit checkout main\ngit switch<\/span> main\ngit checkout -b feature\/name\ngit branch -d feature\/name\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                                                                                                                Merge\/rebase<\/h2>\n\n\n
                                                                                                                git merge main\ngit rebase main\ngit rebase --continue<\/span>\ngit rebase --abort\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                                                                                                                Undo<\/h2>\n\n\n
                                                                                                                git<\/span> restore<\/span> file<\/span>.txt<\/span>\ngit<\/span> restore<\/span> --staged<\/span> file<\/span>.txt<\/span>\ngit<\/span> reset<\/span> --soft<\/span> HEAD<\/span>~1\ngit<\/span> revert<\/span> <sha<\/span>>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
                                                                                                                Tags<\/h2>\n\n\n
                                                                                                                git<\/span> tag<\/span>\ngit<\/span> tag<\/span> -a<\/span> v1<\/span>.0<\/span>.0<\/span> -m<\/span> \"Release<\/span> v1<\/span>.0<\/span>.0<\/span>\"\ngit<\/span> push<\/span> origin<\/span> v1<\/span>.0<\/span>.0<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
                                                                                                                Cleanup<\/h2>\n\n\n
                                                                                                                git fetch --prune\ngit branch --merged\ngit clean -nd\n<\/code><\/span><\/pre>\n\n\n
                                                                                                                \n\n\n\n
                                                                                                                66. The final advice<\/h1>\n\n\n\n
                                                                                                                A beginner thinks:<\/p>\n\n\n\n
                                                                                                                \n
                                                                                                                Git workflow means which branch name to use.<\/p>\n<\/blockquote>\n\n\n\n
                                                                                                                A senior engineer thinks:<\/p>\n\n\n\n
                                                                                                                \n
                                                                                                                Git workflow means how we protect production while helping developers move fast.<\/p>\n<\/blockquote>\n\n\n\n
                                                                                                                An architect thinks:<\/p>\n\n\n\n
                                                                                                                \n
                                                                                                                Git workflow is a delivery control system: source control, review, testing, release, rollback, audit, and learning.<\/p>\n<\/blockquote>\n\n\n\n
                                                                                                                The best workflow is not the most complex one.<\/p>\n\n\n\n
                                                                                                                The best workflow is the one where:<\/p>\n\n\n\n
                                                                                                                  \n
                                                                                                                • Developers understand it.<\/li>\n\n\n\n
                                                                                                                • CI enforces it.<\/li>\n\n\n\n
                                                                                                                • Releases are traceable.<\/li>\n\n\n\n
                                                                                                                • Rollbacks are simple.<\/li>\n\n\n\n
                                                                                                                • Branches are short-lived.<\/li>\n\n\n\n
                                                                                                                • Production is protected.<\/li>\n\n\n\n
                                                                                                                • Teams can move fast without fear.<\/li>\n<\/ul>\n\n\n\n
                                                                                                                  For most modern teams, start with:<\/p>\n\n\n
                                                                                                                  Protected<\/span> main\nShort-lived feature branches\nPull requests\nRequired CI\nSquash merge\nTags for<\/span> releases\nFeature flags for<\/span> incomplete work\nHotfix branches for<\/span> emergencies\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
                                                                                                                  Then evolve toward trunk-based development when your tests, CI, reviews, and release automation are strong enough.<\/p>\n","protected":false},"excerpt":{"rendered":"
                                                                                                                  From First Commit to Enterprise-Grade Delivery Best title:Git Workflow Master Guide: Branching Strategies, Pull Requests, Releases, CI\/CD, and Team Governance 1. What is a Git workflow? A… <\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_joinchat":[],"footnotes":""},"categories":[11138],"tags":[],"class_list":["post-77503","post","type-post","status-publish","format-standard","hentry","category-best-tools"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/77503","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=77503"}],"version-history":[{"count":1,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/77503\/revisions"}],"predecessor-version":[{"id":77504,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/77503\/revisions\/77504"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/media?parent=77503"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/categories?post=77503"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/tags?post=77503"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}