{"id":1195,"date":"2026-09-26T05:59:26","date_gmt":"2026-09-26T05:59:26","guid":{"rendered":"https:\/\/www.devopsschool.com\/tutorials\/?p=1195"},"modified":"2026-09-26T05:59:29","modified_gmt":"2026-09-26T05:59:29","slug":"github-repository-settings-complete-reference-guide-tutorial","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/tutorials\/github-repository-settings-complete-reference-guide-tutorial\/","title":{"rendered":"GitHub Repository Settings \u2014 Complete Reference Guide & Tutorial"},"content":{"rendered":"\n
\n

Last Verified:<\/strong> September 2026
Platform:<\/strong> GitHub.com \/ GitHub Enterprise Cloud unless stated otherwise
Audience:<\/strong> Developers, DevOps engineers, repository administrators, security engineers, platform engineers, team leads, and trainers<\/p>\n<\/blockquote>\n\n\n\n

GitHub repository settings are the control plane for an individual repository. They define who can access the repository, how contributors are allowed to change code, which automation can run, how deployments are protected, which security controls are enabled, and how the repository behaves throughout its lifecycle.<\/p>\n\n\n\n

This guide follows a practical progression:<\/p>\n\n\n\n

Concept \u2192 Why \u2192 How \u2192 Example \u2192 Practice \u2192 Real-world use case \u2192 Best practices \u2192 Troubleshooting<\/strong><\/p>\n\n\n\n

The exact settings visible in GitHub vary by repository ownership, visibility, plan, organization policy, enterprise policy, enabled products, and preview features. When a higher-level policy is enforced, a repository administrator may be able to see a setting but not change it.<\/p>\n\n\n\n

\n\n\n\n

1. What Repository Settings Control<\/h2>\n\n\n\n

Repository settings cover five broad concerns:<\/p>\n\n\n\n

Area<\/th>What it controls<\/th>Typical owner<\/th><\/tr><\/thead>
General<\/td>Identity, default branch, merge behavior, features, lifecycle<\/td>Repository admin<\/td><\/tr>
Access<\/td>People, teams, roles, moderation<\/td>Repo admin \/ org owner<\/td><\/tr>
Code and automation<\/td>Rulesets, branches, Actions, webhooks, environments, Pages<\/td>Platform \/ DevOps \/ repo admin<\/td><\/tr>
Security and quality<\/td>Dependabot, code scanning, secret scanning, Code Quality, deploy keys<\/td>Security \/ platform \/ repo admin<\/td><\/tr>
Integrations<\/td>GitHub Apps, email notifications, external systems<\/td>Platform \/ repo admin<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

A useful mental model is:<\/p>\n\n\n\n

flowchart TD\n    E[Enterprise Policy] --> O[Organization Policy]\n    O --> R[Repository Settings]\n    R --> B[Branch and Tag Rules]\n    R --> A[Actions and Automation]\n    R --> S[Security and Quality]\n    R --> D[Deployment Environments]\n    B --> C[Developer Contribution]\n    A --> C\n    S --> C\n    D --> C\n<\/code><\/pre>\n\n\n\n
How to read the diagram:<\/strong> repository settings operate inside the boundaries created by enterprise and organization policies. Repository administrators can usually make a setting more restrictive, but they cannot bypass a higher-level restriction unless the higher-level policy explicitly permits it.<\/p>\n\n\n\n
1.1 Repository configuration hierarchy<\/h3>\n\n\n\n
A practical precedence model is:<\/p>\n\n\n\n
Enterprise policy\n        \u2193\nOrganization policy\n        \u2193\nRepository configuration\n        \u2193\nEnvironment protection\n        \u2193\nWorkflow \/ job permissions\n<\/code><\/pre>\n\n\n\n
The lower layer cannot reliably be treated as more authoritative than the higher layer. For example, a repository cannot allow an Action that the organization has blocked.<\/p>\n\n\n\n
1.2 Repository ownership models<\/h3>\n\n\n\n
GitHub repositories can be owned by:<\/p>\n\n\n\n
    \n
  • A personal account<\/li>\n\n\n\n
  • An organization<\/li>\n<\/ul>\n\n\n\n
    Organization repositories support richer access governance, including teams, outside collaborators, organization rulesets, custom repository roles, security managers, and enterprise policy inheritance.<\/p>\n\n\n\n
    1.3 Repository visibility<\/h3>\n\n\n\n
    Visibility<\/th>Who can normally see it<\/th>Important note<\/th><\/tr><\/thead>
    Public<\/td>Anyone<\/td>Code, Actions history\/logs, and public contribution surface are visible<\/td><\/tr>
    Private<\/td>Explicitly authorized users and permitted organization members<\/td>Feature availability depends on plan<\/td><\/tr>
    Internal<\/td>Enterprise members<\/td>Available for eligible enterprise-owned organizations<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
    Internal repositories are not simply \u201cprivate repositories with more users.\u201d They are designed for enterprise-wide discoverability and may grant read access broadly inside the enterprise.<\/p>\n\n\n\n
    \n\n\n\n
    2. Prerequisites and Permissions<\/h2>\n\n\n\n
    Before changing repository settings, identify your role and the policy layer that owns the control.<\/p>\n\n\n\n
    2.1 Common repository roles<\/h3>\n\n\n\n
    For organization repositories, the standard repository roles are:<\/p>\n\n\n\n
    Role<\/th>Typical use<\/th>Can push code?<\/th>Administrative capability<\/th><\/tr><\/thead>
    Read<\/td>Viewers, auditors, non-code contributors<\/td>No<\/td>Minimal<\/td><\/tr>
    Triage<\/td>Issue and PR coordinators<\/td>No<\/td>Manage issues\/PRs without code write access<\/td><\/tr>
    Write<\/td>Developers<\/td>Yes<\/td>Normal development operations<\/td><\/tr>
    Maintain<\/td>Project\/repository maintainers<\/td>Yes<\/td>Many management actions without destructive admin powers<\/td><\/tr>
    Admin<\/td>Repository administrators<\/td>Yes<\/td>Full repository administration, subject to org\/enterprise policy<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
    Organizations can also define custom repository roles on eligible plans.<\/p>\n\n\n\n
    2.2 What you need for this tutorial<\/h3>\n\n\n\n
    Recommended:<\/p>\n\n\n\n
      \n
    • A GitHub organization test repository<\/li>\n\n\n\n
    • Admin access to that repository<\/li>\n\n\n\n
    • GitHub CLI installed and authenticated<\/li>\n\n\n\n
    • Git installed locally<\/li>\n\n\n\n
    • Optional: Terraform for GitHub provider examples<\/li>\n\n\n\n
    • Optional: a webhook test endpoint you control<\/li>\n\n\n\n
    • Optional: GitHub Actions enabled<\/li>\n\n\n\n
    • Optional: GitHub Advanced Security \/ Code Security \/ Secret Protection \/ Code Quality entitlements where exercises require them<\/li>\n<\/ul>\n\n\n\n
      Authenticate GitHub CLI:<\/p>\n\n\n\n
      gh auth login\n<\/code><\/pre>\n\n\n\n
      Confirm authentication:<\/p>\n\n\n\n
      gh auth status\n<\/code><\/pre>\n\n\n\n
      Set reusable shell variables for later examples:<\/p>\n\n\n\n
      export OWNER=\"your-org\"\nexport REPO=\"your-repo\"\n<\/code><\/pre>\n\n\n\n
      Verify repository access:<\/p>\n\n\n\n
      gh repo view \"$OWNER\/$REPO\"\n<\/code><\/pre>\n\n\n\n
      \n\n\n\n
      3. Repository Settings Navigation<\/h2>\n\n\n\n
      Open a repository and select Settings<\/strong>. Depending on your plan and enabled products, common areas include:<\/p>\n\n\n\n
      Settings area<\/th>What you manage<\/th><\/tr><\/thead>
      General<\/td>Name, default branch, releases, merge behavior, features, archives, pushes, issues, danger zone<\/td><\/tr>
      Collaborators and teams<\/td>Direct and team access<\/td><\/tr>
      Moderation<\/td>Interaction and review restrictions<\/td><\/tr>
      Rulesets<\/td>Branch, tag, push, security, quality rules<\/td><\/tr>
      Custom properties<\/td>Organization-defined repository metadata<\/td><\/tr>
      Branches<\/td>Default branch and legacy branch protection rules<\/td><\/tr>
      Tags<\/td>Tag-related controls where exposed<\/td><\/tr>
      Actions<\/td>Actions permissions, workflow permissions, retention, cache, runners<\/td><\/tr>
      Webhooks<\/td>Event delivery to external systems<\/td><\/tr>
      Copilot<\/td>Repository Copilot controls, code review, MCP configuration<\/td><\/tr>
      Planning<\/td>Issue templates and planning-related behavior<\/td><\/tr>
      Environments<\/td>Deployment approvals, branches\/tags, secrets, variables<\/td><\/tr>
      Pages<\/td>Static-site publishing<\/td><\/tr>
      Advanced Security<\/td>Dependency, code, and secret security features<\/td><\/tr>
      Code quality<\/td>GitHub Code Quality controls<\/td><\/tr>
      Deploy keys<\/td>Repository-scoped SSH keys<\/td><\/tr>
      Secrets and variables<\/td>Actions, Dependabot, Codespaces, agents where available<\/td><\/tr>
      GitHub Apps<\/td>Apps with repository access<\/td><\/tr>
      Email notifications<\/td>Push notification recipients<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
      \n
      Important:<\/strong> GitHub periodically reorganizes settings navigation. Learn the underlying capability, not only the exact sidebar label.<\/p>\n<\/blockquote>\n\n\n\n
      \n\n\n\n
      Part I \u2014 General Repository Administration<\/h1>\n\n\n\n
      4. Repository Identity<\/h2>\n\n\n\n
      What is it?<\/h3>\n\n\n\n
      Repository identity includes the repository name, owner, URL, description, website, topics, and social preview.<\/p>\n\n\n\n
      Why does it matter?<\/h3>\n\n\n\n
      Repository identity affects:<\/p>\n\n\n\n
        \n
      • Clone URLs<\/li>\n\n\n\n
      • Documentation links<\/li>\n\n\n\n
      • CI\/CD references<\/li>\n\n\n\n
      • Package and deployment references<\/li>\n\n\n\n
      • Discovery and search<\/li>\n\n\n\n
      • External documentation<\/li>\n\n\n\n
      • Automation that hard-codes\u00a0OWNER\/REPO<\/code><\/li>\n<\/ul>\n\n\n\n
        4.1 Rename a repository<\/h3>\n\n\n\n
        Typical UI flow:<\/p>\n\n\n\n
          \n
        1. Open the repository.<\/li>\n\n\n\n
        2. Select\u00a0Settings<\/strong>.<\/li>\n\n\n\n
        3. Under\u00a0General<\/strong>, locate the repository name.<\/li>\n\n\n\n
        4. Enter the new name.<\/li>\n\n\n\n
        5. Confirm the rename.<\/li>\n\n\n\n
        6. Update integrations that depend on the old path.<\/li>\n<\/ol>\n\n\n\n
          GitHub generally redirects old repository web URLs and Git operations, but do not use redirects as a permanent dependency strategy.<\/p>\n\n\n\n
          Update a local remote after a rename:<\/p>\n\n\n\n
          git remote set-url origin git@github.com:OWNER\/NEW_REPO.git\n<\/code><\/pre>\n\n\n\n
          Verify:<\/p>\n\n\n\n
          git remote -v\n<\/code><\/pre>\n\n\n\n
          Best practices<\/h3>\n\n\n\n
          Recommended<\/strong><\/p>\n\n\n\n
            \n
          • Use stable, descriptive repository names.<\/li>\n\n\n\n
          • Keep naming conventions consistent across an organization.<\/li>\n\n\n\n
          • Search CI\/CD, IaC, docs, badges, deployment systems, and package metadata before renaming.<\/li>\n\n\n\n
          • Update external consumers even when GitHub redirects continue to work.<\/li>\n<\/ul>\n\n\n\n
            Avoid<\/strong><\/p>\n\n\n\n
              \n
            • Renaming repositories as a routine cosmetic operation.<\/li>\n\n\n\n
            • Depending indefinitely on old URLs.<\/li>\n\n\n\n
            • Embedding owner\/repository names in many unrelated scripts when a variable can be used.<\/li>\n<\/ul>\n\n\n\n
              \n\n\n\n
              5. Description, Website, Topics, and Social Preview<\/h2>\n\n\n\n
              Repository metadata improves discoverability and gives users immediate context.<\/p>\n\n\n\n
              Example metadata standard<\/h3>\n\n\n\n
              Field<\/th>Example<\/th><\/tr><\/thead>
              Repository<\/td>payment-api<\/code><\/td><\/tr>
              Description<\/td>Payments API for checkout and settlement services<\/code><\/td><\/tr>
              Website<\/td>https:\/\/docs.example.com\/payments<\/code><\/td><\/tr>
              Topics<\/td>payments<\/code>, golang<\/code>, api<\/code>, production<\/code><\/td><\/tr>
              Custom property<\/td>service-tier=1<\/code><\/td><\/tr>
              Custom property<\/td>owner=payments-platform<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
              Use the social preview image when repository links are frequently shared in chat, documentation, or social networks.<\/p>\n\n\n\n
              \n\n\n\n
              6. Template Repository<\/h2>\n\n\n\n
              A template repository provides a reusable starting point for creating new repositories.<\/p>\n\n\n\n
              When to use it<\/h3>\n\n\n\n
              Use a template when many repositories should start with the same structure:<\/p>\n\n\n\n
              .github\/\n  workflows\/\n  ISSUE_TEMPLATE\/\nCODEOWNERS\nCONTRIBUTING.md\nLICENSE\nREADME.md\nSECURITY.md\nsrc\/\ntests\/\n<\/code><\/pre>\n\n\n\n
              Typical platform-engineering use cases:<\/p>\n\n\n\n
                \n
              • Microservice bootstrap<\/li>\n\n\n\n
              • Terraform module repository<\/li>\n\n\n\n
              • Internal library<\/li>\n\n\n\n
              • Documentation repository<\/li>\n\n\n\n
              • Standardized application repository<\/li>\n<\/ul>\n\n\n\n
                Template vs fork<\/h3>\n\n\n\n
                Template<\/th>Fork<\/th><\/tr><\/thead>
                Creates an independent repository<\/td>Preserves fork relationship<\/td><\/tr>
                No shared commit history required<\/td>Shares history\/network with upstream<\/td><\/tr>
                Best for standardized starting structure<\/td>Best for contributing or maintaining a derivative<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                \n\n\n\n
                7. Default Branch<\/h2>\n\n\n\n
                The default branch is GitHub’s primary branch for operations such as pull request targets and repository browsing.<\/p>\n\n\n\n
                Commonly:<\/p>\n\n\n\n
                main\n<\/code><\/pre>\n\n\n\n
                Change the default branch<\/h3>\n\n\n\n
                  \n
                1. Create the target branch if it does not exist.<\/li>\n\n\n\n
                2. Open\u00a0Settings \u2192 Branches<\/strong>\u00a0or the current default-branch control.<\/li>\n\n\n\n
                3. Change the default branch.<\/li>\n\n\n\n
                4. Review branch protection\/rulesets.<\/li>\n\n\n\n
                5. Update CI\/CD triggers, deployment rules, and external integrations.<\/li>\n\n\n\n
                6. Update local clones if the branch was renamed.<\/li>\n<\/ol>\n\n\n\n
                  After renaming master<\/code> to main<\/code> locally:<\/p>\n\n\n\n
                  git branch -m master main\ngit fetch origin\ngit branch -u origin\/main main\ngit remote set-head origin -a\n<\/code><\/pre>\n\n\n\n
                  What can break?<\/h3>\n\n\n\n
                    \n
                  • Workflows triggered only on the old branch<\/li>\n\n\n\n
                  • Branch rules targeting the old name<\/li>\n\n\n\n
                  • Pages publishing source<\/li>\n\n\n\n
                  • Build\/deploy systems<\/li>\n\n\n\n
                  • Documentation links<\/li>\n\n\n\n
                  • Default comparison\/base behavior in external systems<\/li>\n<\/ul>\n\n\n\n
                    \n\n\n\n
                    8. Releases and Release Immutability<\/h2>\n\n\n\n
                    GitHub Releases combine a Git tag, release metadata, notes, and optional binary assets.<\/p>\n\n\n\n
                    8.1 Mutable release risk<\/h3>\n\n\n\n
                    Without immutability, changing a release tag or replacing release assets can undermine assumptions about provenance and artifact integrity.<\/p>\n\n\n\n
                    8.2 Release immutability<\/h3>\n\n\n\n
                    GitHub now supports release immutability<\/strong>. When enabled, it applies to future releases and is intended to prevent changes to published release tags\/assets that would make a release no longer represent a fixed artifact set.<\/p>\n\n\n\n
                    Typical flow:<\/p>\n\n\n\n
                      \n
                    1. Open\u00a0Settings \u2192 General<\/strong>.<\/li>\n\n\n\n
                    2. Locate\u00a0Releases<\/strong>.<\/li>\n\n\n\n
                    3. Enable release immutability.<\/li>\n\n\n\n
                    4. Publish releases only after validation is complete.<\/li>\n<\/ol>\n\n\n\n
                      Recommended release flow<\/h3>\n\n\n\n
                      flowchart LR\n    C[Commit] --> T[Create Tag]\n    T --> B[Build Artifact]\n    B --> S[Sign and Attest]\n    S --> R[Publish Release]\n    R --> I[Immutable Release]\n<\/code><\/pre>\n\n\n\n
                      Best practice<\/h3>\n\n\n\n
                      For production software, combine:<\/p>\n\n\n\n
                        \n
                      • Protected release tags or tag rulesets<\/li>\n\n\n\n
                      • Release immutability<\/li>\n\n\n\n
                      • Artifact attestations where applicable<\/li>\n\n\n\n
                      • Pinned dependencies<\/li>\n\n\n\n
                      • Reproducible build practices<\/li>\n<\/ul>\n\n\n\n
                        \n\n\n\n
                        9. Repository Features<\/h2>\n\n\n\n
                        Repositories can expose optional collaboration features such as:<\/p>\n\n\n\n
                          \n
                        • Issues<\/li>\n\n\n\n
                        • Wikis<\/li>\n\n\n\n
                        • Discussions<\/li>\n\n\n\n
                        • Projects integration<\/li>\n\n\n\n
                        • Actions<\/li>\n<\/ul>\n\n\n\n
                          Feature availability can depend on plan and policy.<\/p>\n\n\n\n
                          9.1 Wikis<\/h3>\n\n\n\n
                          Use a repository Wiki for repository-specific documentation when you want Git-backed pages managed separately from the primary code tree.<\/p>\n\n\n\n
                          Prefer \/docs<\/code> or a dedicated documentation site when documentation must be versioned with application code, reviewed through pull requests, or published through a docs pipeline.<\/p>\n\n\n\n
                          9.2 Issues<\/h3>\n\n\n\n
                          Issues support:<\/p>\n\n\n\n
                            \n
                          • Bugs<\/li>\n\n\n\n
                          • Feature requests<\/li>\n\n\n\n
                          • Operational work<\/li>\n\n\n\n
                          • Tasks<\/li>\n\n\n\n
                          • Labels<\/li>\n\n\n\n
                          • Assignees<\/li>\n\n\n\n
                          • Milestones<\/li>\n\n\n\n
                          • Parent\/sub-issue relationships where available<\/li>\n\n\n\n
                          • Project integration<\/li>\n<\/ul>\n\n\n\n
                            9.3 Discussions<\/h3>\n\n\n\n
                            Use Discussions for conversations that should not immediately become tracked work:<\/p>\n\n\n\n
                              \n
                            • Q&A<\/li>\n\n\n\n
                            • Design discussion<\/li>\n\n\n\n
                            • Community support<\/li>\n\n\n\n
                            • Announcements<\/li>\n\n\n\n
                            • Ideas<\/li>\n<\/ul>\n\n\n\n
                              9.4 Projects<\/h3>\n\n\n\n
                              GitHub Projects can organize issues, pull requests, and draft items into views and workflows. Repository settings can expose or connect planning surfaces, while most Project configuration itself belongs to the Project rather than the repository.<\/p>\n\n\n\n
                              \n\n\n\n
                              10. Pull Request Merge Methods<\/h2>\n\n\n\n
                              GitHub commonly supports three merge strategies:<\/p>\n\n\n\n
                              Method<\/th>Result<\/th>Best fit<\/th><\/tr><\/thead>
                              Merge commit<\/td>Preserves branch commits plus merge commit<\/td>Teams that value branch history<\/td><\/tr>
                              Squash merge<\/td>Combines PR into one commit<\/td>Clean main-branch history<\/td><\/tr>
                              Rebase merge<\/td>Replays commits linearly<\/td>Teams that want individual commits without merge commits<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                              10.1 Merge commit configuration<\/h3>\n\n\n\n
                              Repositories can control default merge commit title\/message behavior.<\/p>\n\n\n\n
                              10.2 Squash configuration<\/h3>\n\n\n\n
                              Repositories can choose how the squash commit title\/message is generated from PR title, description, or commits.<\/p>\n\n\n\n
                              10.3 Which should you choose?<\/h3>\n\n\n\n
                              A common service repository policy is:<\/p>\n\n\n\n
                              Squash merge: enabled\nMerge commit: disabled\nRebase merge: optional\n<\/code><\/pre>\n\n\n\n
                              This is not universally best. Libraries or repositories where individual commits carry meaningful history may prefer rebase or merge commits.<\/p>\n\n\n\n
                              \n\n\n\n
                              11. Pull Request Update Behavior<\/h2>\n\n\n\n
                              The repository can allow GitHub to suggest updating a pull request branch when the base branch advances.<\/p>\n\n\n\n
                              This is useful when:<\/p>\n\n\n\n
                                \n
                              • Required status checks must run against recent base changes<\/li>\n\n\n\n
                              • Merge requirements require the branch to be current<\/li>\n\n\n\n
                              • Teams want fewer manual\u00a0git merge main<\/code>\u00a0operations<\/li>\n<\/ul>\n\n\n\n
                                Do not confuse \u201csuggest update branch\u201d with a protection rule that requires branches to be up to date before merge.<\/p>\n\n\n\n
                                \n\n\n\n
                                12. Auto-Merge<\/h2>\n\n\n\n
                                Auto-merge lets a pull request merge automatically after all required conditions are satisfied.<\/p>\n\n\n\n
                                Typical requirements:<\/p>\n\n\n\n
                                  \n
                                • Required reviews complete<\/li>\n\n\n\n
                                • Required status checks pass<\/li>\n\n\n\n
                                • Required deployments pass<\/li>\n\n\n\n
                                • Ruleset\/branch-protection conditions satisfied<\/li>\n\n\n\n
                                • No unresolved blocking conditions<\/li>\n<\/ul>\n\n\n\n
                                  Use it to reduce waiting after a PR is already approved but still waiting for CI.<\/p>\n\n\n\n
                                  \n\n\n\n
                                  13. Automatic Head-Branch Deletion<\/h2>\n\n\n\n
                                  Automatically deleting head branches after merge reduces stale branch clutter.<\/p>\n\n\n\n
                                  Recommended for most short-lived feature-branch workflows.<\/p>\n\n\n\n
                                  A deleted branch can often be restored from the merged pull request when GitHub still retains the relationship.<\/p>\n\n\n\n
                                  \n\n\n\n
                                  14. Source Archives and Git LFS<\/h2>\n\n\n\n
                                  GitHub can generate source archives such as ZIP and tarball downloads.<\/p>\n\n\n\n
                                  Repositories that use Git LFS can control whether LFS objects are included in generated archives.<\/p>\n\n\n\n
                                  Decision<\/h3>\n\n\n\n
                                  Requirement<\/th>Recommendation<\/th><\/tr><\/thead>
                                  Users expect a self-contained archive<\/td>Include required LFS objects<\/td><\/tr>
                                  LFS assets are large and unnecessary for source review<\/td>Exclude them<\/td><\/tr>
                                  Release requires deterministic binaries<\/td>Prefer explicit release artifacts rather than source archive behavior<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                                  \n\n\n\n
                                  15. Push Policy<\/h2>\n\n\n\n
                                  Repository push policy can limit how many branches and tags are updated in a single push.<\/p>\n\n\n\n
                                  This is useful for reducing accidental large-scale ref updates and making unusually broad pushes more visible.<\/p>\n\n\n\n
                                  It is not a replacement for rulesets or branch protection.<\/p>\n\n\n\n
                                  \n\n\n\n
                                  16. Web Commit Signoff<\/h2>\n\n\n\n
                                  GitHub can require users making commits through the web interface to sign off commits.<\/p>\n\n\n\n
                                  A signoff commonly adds a trailer similar to:<\/p>\n\n\n\n
                                  Signed-off-by: Developer Name <developer@example.com>\n<\/code><\/pre>\n\n\n\n
                                  This is commonly used with Developer Certificate of Origin style contribution policies.<\/p>\n\n\n\n
                                  \n
                                  A signoff is not the same as cryptographic commit signing. A Signed-off-by<\/code> trailer records an attestation statement; a signed commit uses GPG, SSH, or S\/MIME verification.<\/p>\n<\/blockquote>\n\n\n\n
                                  \n\n\n\n
                                  17. Automatic Issue Closing<\/h2>\n\n\n\n
                                  GitHub can automatically close issues when a linked pull request is merged and closing syntax\/relationships are satisfied.<\/p>\n\n\n\n
                                  Common closing keywords include forms such as:<\/p>\n\n\n\n
                                  Fixes #123\nCloses #123\nResolves #123\n<\/code><\/pre>\n\n\n\n
                                  Repository settings can control whether linked issues are automatically closed when merged PRs complete.<\/p>\n\n\n\n
                                  Use explicit references in PR descriptions so issue lifecycle remains easy to audit.<\/p>\n\n\n\n
                                  \n\n\n\n
                                  18. Autolink References<\/h2>\n\n\n\n
                                  Autolinks turn external identifiers into clickable links.<\/p>\n\n\n\n
                                  Example:<\/p>\n\n\n\n
                                  JIRA-142\n<\/code><\/pre>\n\n\n\n
                                  can become a link to:<\/p>\n\n\n\n
                                  https://jira.example.com\/browse\/JIRA-142\n<\/code><\/pre>\n\n\n\n
                                  Use cases<\/h3>\n\n\n\n
                                    \n
                                  • Jira<\/li>\n\n\n\n
                                  • Zendesk<\/li>\n\n\n\n
                                  • Internal change-management tickets<\/li>\n\n\n\n
                                  • Incident IDs<\/li>\n\n\n\n
                                  • Customer support references<\/li>\n<\/ul>\n\n\n\n
                                    Best practice<\/h3>\n\n\n\n
                                    Use a distinctive prefix that does not collide with normal text.<\/p>\n\n\n\n
                                    \n\n\n\n
                                    Part II \u2014 Danger Zone and Repository Lifecycle Actions<\/h1>\n\n\n\n
                                    19. Change Repository Visibility<\/h2>\n\n\n\n
                                    Visibility changes can have major side effects.<\/p>\n\n\n\n
                                    Important consequences<\/h3>\n\n\n\n
                                    Depending on the direction of the change, GitHub may change or remove:<\/p>\n\n\n\n
                                      \n
                                    • Stars and watchers<\/li>\n\n\n\n
                                    • Fork network relationships<\/li>\n\n\n\n
                                    • Push rulesets<\/li>\n\n\n\n
                                    • Pages behavior<\/li>\n\n\n\n
                                    • Code scanning availability<\/li>\n\n\n\n
                                    • Dependabot custom rules<\/li>\n\n\n\n
                                    • Actions log visibility<\/li>\n<\/ul>\n\n\n\n
                                      For example, changing a private or internal repository to public exposes the code and Actions history\/logs publicly and disables push rulesets that are limited to private\/internal fork networks.<\/p>\n\n\n\n
                                      Safe change procedure<\/h3>\n\n\n\n
                                        \n
                                      1. Inventory forks.<\/li>\n\n\n\n
                                      2. Inventory Pages\/custom domains.<\/li>\n\n\n\n
                                      3. Review Actions logs for sensitive information.<\/li>\n\n\n\n
                                      4. Review security feature licensing impact.<\/li>\n\n\n\n
                                      5. Review organization\/enterprise policy.<\/li>\n\n\n\n
                                      6. Communicate the change.<\/li>\n\n\n\n
                                      7. Change visibility.<\/li>\n\n\n\n
                                      8. Re-validate security controls.<\/li>\n<\/ol>\n\n\n\n
                                        \n\n\n\n
                                        20. Transfer a Repository<\/h2>\n\n\n\n
                                        A repository can be transferred to another eligible user or organization.<\/p>\n\n\n\n
                                        Transferred content generally includes important repository resources such as:<\/p>\n\n\n\n
                                          \n
                                        • Git history<\/li>\n\n\n\n
                                        • Issues<\/li>\n\n\n\n
                                        • Pull requests<\/li>\n\n\n\n
                                        • Wiki<\/li>\n\n\n\n
                                        • Releases<\/li>\n\n\n\n
                                        • Stars\/watchers<\/li>\n\n\n\n
                                        • Webhooks<\/li>\n\n\n\n
                                        • Secrets<\/li>\n\n\n\n
                                        • Deploy keys<\/li>\n<\/ul>\n\n\n\n
                                          Package behavior can vary by package registry and permission model, so validate package ownership separately.<\/p>\n\n\n\n
                                          Transfer checklist<\/h3>\n\n\n\n
                                          [ ] Destination allows repository creation\/transfer\n[ ] No destination name conflict\n[ ] Teams\/access model reviewed\n[ ] Organization default permissions reviewed\n[ ] Apps\/integrations reviewed\n[ ] Packages reviewed\n[ ] Actions\/reusable workflow access reviewed\n[ ] Secrets and environment policies reviewed\n[ ] External webhooks and allowlists reviewed\n<\/code><\/pre>\n\n\n\n
                                          \n\n\n\n
                                          21. Archive a Repository<\/h2>\n\n\n\n
                                          Archiving makes a repository read-only and signals that active maintenance has ended.<\/p>\n\n\n\n
                                          Before archiving:<\/p>\n\n\n\n
                                            \n
                                          1. Close or document open issues and pull requests.<\/li>\n\n\n\n
                                          2. Add a deprecation or successor notice to the README.<\/li>\n\n\n\n
                                          3. Disable or retire external automation where appropriate.<\/li>\n\n\n\n
                                          4. Document ownership.<\/li>\n\n\n\n
                                          5. Confirm downstream consumers have migrated.<\/li>\n\n\n\n
                                          6. Archive the repository.<\/li>\n<\/ol>\n\n\n\n
                                            Archived content becomes read-only. Secret scanning availability for archived repositories depends on enabled security products.<\/p>\n\n\n\n
                                            \n\n\n\n
                                            22. Delete and Restore a Repository<\/h2>\n\n\n\n
                                            Deletion is destructive. Organization\/enterprise policy can restrict who may delete repositories.<\/p>\n\n\n\n
                                            Key behavior<\/h3>\n\n\n\n
                                              \n
                                            • Deleting a private\/internal repository deletes its forks.<\/li>\n\n\n\n
                                            • Deleting a public repository does not necessarily delete public forks.<\/li>\n\n\n\n
                                            • Team permissions are permanently deleted with the repository.<\/li>\n\n\n\n
                                            • Some deleted repositories can be restored within\u00a090 days<\/strong>.<\/li>\n\n\n\n
                                            • Restoration has limitations for non-empty fork networks.<\/li>\n<\/ul>\n\n\n\n
                                              Production deletion checklist<\/h3>\n\n\n\n
                                              [ ] Business owner approval\n[ ] Repository archived\/exported if required\n[ ] Packages checked\n[ ] Releases\/artifacts backed up if required\n[ ] Secrets revoked\n[ ] Deploy keys revoked\n[ ] Webhooks disabled\n[ ] CI\/CD dependencies mapped\n[ ] Downstream code dependencies mapped\n[ ] Fork impact reviewed\n[ ] Retention\/compliance requirement reviewed\n<\/code><\/pre>\n\n\n\n
                                              \n\n\n\n
                                              Part III \u2014 Access Management and Moderation<\/h1>\n\n\n\n
                                              23. Repository Access Model<\/h2>\n\n\n\n
                                              Organization repositories may receive access from several paths:<\/p>\n\n\n\n
                                              flowchart TD\n    U[User] --> D[Direct Repository Access]\n    U --> T[Team Membership]\n    T --> R[Repository Role]\n    U --> O[Organization Base Permission]\n    O --> R\n    D --> R\n<\/code><\/pre>\n\n\n\n
                                              A user can therefore have multiple routes to the same repository. Always troubleshoot effective access<\/strong>, not just direct access.<\/p>\n\n\n\n
                                              23.1 Direct access<\/h3>\n\n\n\n
                                              Direct access is useful for exceptional cases but becomes hard to govern at scale.<\/p>\n\n\n\n
                                              23.2 Team access<\/h3>\n\n\n\n
                                              Preferred for stable organizational access:<\/p>\n\n\n\n
                                              Team: payments-developers \u2192 Write\nTeam: payments-maintainers \u2192 Maintain\nTeam: security-reviewers \u2192 Read\nTeam: platform-admins \u2192 Admin\n<\/code><\/pre>\n\n\n\n
                                              23.3 Outside collaborators<\/h3>\n\n\n\n
                                              Outside collaborators can be granted repository access without organization membership. Treat them as a distinct lifecycle:<\/p>\n\n\n\n
                                                \n
                                              • Sponsor required<\/li>\n\n\n\n
                                              • Explicit expiration\/review<\/li>\n\n\n\n
                                              • Least privilege<\/li>\n\n\n\n
                                              • 2FA\/identity requirements according to organization policy<\/li>\n<\/ul>\n\n\n\n
                                                \n\n\n\n
                                                24. Access Review Procedure<\/h2>\n\n\n\n
                                                At least periodically:<\/p>\n\n\n\n
                                                  \n
                                                1. Open\u00a0Settings \u2192 Collaborators and teams<\/strong>.<\/li>\n\n\n\n
                                                2. Export or record people and teams with access where supported.<\/li>\n\n\n\n
                                                3. Identify direct collaborators.<\/li>\n\n\n\n
                                                4. Identify outside collaborators.<\/li>\n\n\n\n
                                                5. Check inherited\/base access.<\/li>\n\n\n\n
                                                6. Validate team ownership.<\/li>\n\n\n\n
                                                7. Reduce over-privileged roles.<\/li>\n\n\n\n
                                                8. Remove stale access.<\/li>\n<\/ol>\n\n\n\n
                                                  Access review table<\/h3>\n\n\n\n
                                                  Actor<\/th>Access source<\/th>Current role<\/th>Needed role<\/th>Action<\/th><\/tr><\/thead>
                                                  payments-dev<\/code><\/td>Team<\/td>Write<\/td>Write<\/td>Keep<\/td><\/tr>
                                                  alice<\/code><\/td>Direct<\/td>Admin<\/td>Maintain<\/td>Reduce<\/td><\/tr>
                                                  vendor-user<\/code><\/td>Outside collaborator<\/td>Write<\/td>Read<\/td>Reduce<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                                                  \n\n\n\n
                                                  25. Moderation and Interaction Limits<\/h2>\n\n\n\n
                                                  Public repositories may need controls against spam or contribution floods.<\/p>\n\n\n\n
                                                  GitHub interaction limits can temporarily restrict users based on categories such as:<\/p>\n\n\n\n
                                                    \n
                                                  • Newer\/existing-user status<\/li>\n\n\n\n
                                                  • Prior contribution history<\/li>\n\n\n\n
                                                  • Collaborator status<\/li>\n<\/ul>\n\n\n\n
                                                    Common durations include temporary windows from one day through several months.<\/p>\n\n\n\n
                                                    Current GitHub also supports controls that can limit the number of concurrent open pull requests from users without write access, with bypasses for trusted contributors.<\/p>\n\n\n\n
                                                    When to use moderation controls<\/h3>\n\n\n\n
                                                      \n
                                                    • Spam wave<\/li>\n\n\n\n
                                                    • Coordinated abuse<\/li>\n\n\n\n
                                                    • Event-driven contribution spike<\/li>\n\n\n\n
                                                    • CI exhaustion caused by excessive PR creation<\/li>\n<\/ul>\n\n\n\n
                                                      Avoid<\/h3>\n\n\n\n
                                                      Do not keep emergency interaction limits enabled forever without review. Long-lived governance should be handled with contribution policy, access controls, automation, and moderation processes.<\/p>\n\n\n\n
                                                      \n\n\n\n
                                                      26. Pull Request Review Restrictions<\/h2>\n\n\n\n
                                                      For applicable public-repository workflows, GitHub can restrict who may approve or request changes on pull requests.<\/p>\n\n\n\n
                                                      Use this when review actions must come from trusted collaborators rather than any external participant.<\/p>\n\n\n\n
                                                      \n\n\n\n
                                                      Part IV \u2014 Rulesets, Branches, and Tags<\/h1>\n\n\n\n
                                                      27. Rulesets Fundamentals<\/h2>\n\n\n\n
                                                      Rulesets are GitHub’s modern policy mechanism for branches, tags, and pushes.<\/p>\n\n\n\n
                                                      Rulesets improve on legacy branch protection in several ways:<\/p>\n\n\n\n
                                                        \n
                                                      • Multiple rulesets can apply simultaneously.<\/li>\n\n\n\n
                                                      • Rules are aggregated.<\/li>\n\n\n\n
                                                      • Read users can inspect applicable active rules.<\/li>\n\n\n\n
                                                      • Organization-level rulesets can target multiple repositories.<\/li>\n\n\n\n
                                                      • Push rulesets can protect an entire private\/internal fork network.<\/li>\n\n\n\n
                                                      • Rule insights can show pass, fail, and bypass activity.<\/li>\n\n\n\n
                                                      • Evaluate mode can test rules without blocking contributors where supported.<\/li>\n<\/ul>\n\n\n\n
                                                        27.1 Ruleset targets<\/h3>\n\n\n\n
                                                        Ruleset type<\/th>Protects<\/th><\/tr><\/thead>
                                                        Branch ruleset<\/td>Selected branches<\/td><\/tr>
                                                        Tag ruleset<\/td>Selected tags<\/td><\/tr>
                                                        Push ruleset<\/td>Push content across a private\/internal repository fork network<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                                                        27.2 Enforcement states<\/h3>\n\n\n\n
                                                        Common states are:<\/p>\n\n\n\n
                                                          \n
                                                        • Active<\/strong>\u00a0\u2014 enforce now<\/li>\n\n\n\n
                                                        • Evaluate<\/strong>\u00a0\u2014 observe would-pass\/would-fail behavior where available<\/li>\n\n\n\n
                                                        • Disabled<\/strong>\u00a0\u2014 neither enforce nor evaluate<\/li>\n<\/ul>\n\n\n\n
                                                          Availability of Evaluate can depend on ownership\/plan.<\/p>\n\n\n\n
                                                          \n\n\n\n
                                                          28. Ruleset Targeting<\/h2>\n\n\n\n
                                                          Branch and tag rulesets support include\/exclude targeting and pattern matching.<\/p>\n\n\n\n
                                                          Examples:<\/p>\n\n\n\n
                                                          main\nrelease\/*\nreleases\/**\/*\nv*\n<\/code><\/pre>\n\n\n\n
                                                          GitHub uses fnmatch<\/code> semantics for relevant branch\/tag targeting controls.<\/p>\n\n\n\n
                                                          Example policy<\/h3>\n\n\n\n
                                                          Include: default branch\nInclude: release\/*\nExclude: release\/sandbox\/*\n<\/code><\/pre>\n\n\n\n
                                                          Keep patterns understandable. A policy nobody can reason about is difficult to audit.<\/p>\n\n\n\n
                                                          \n\n\n\n
                                                          29. Ruleset Bypass<\/h2>\n\n\n\n
                                                          A ruleset can grant bypass capability to eligible actors such as:<\/p>\n\n\n\n
                                                            \n
                                                          • Repository admins \/ organization or enterprise owners where eligible<\/li>\n\n\n\n
                                                          • Selected repository roles<\/li>\n\n\n\n
                                                          • Teams<\/li>\n\n\n\n
                                                          • GitHub Apps<\/li>\n\n\n\n
                                                          • Dependabot in supported cases<\/li>\n<\/ul>\n\n\n\n
                                                            GitHub can also support a pull-request-only<\/strong> bypass mode, which permits a trusted actor to bypass certain rules through PR flow without granting unrestricted direct push behavior.<\/p>\n\n\n\n
                                                            Best practice<\/h3>\n\n\n\n
                                                            Treat bypass as break-glass access:<\/p>\n\n\n\n
                                                            Small bypass group\n        +\nAuditable reason\n        +\nRule Insights review\n        +\nPeriodic access review\n<\/code><\/pre>\n\n\n\n
                                                            \n\n\n\n
                                                            30. Branch and Tag Rules<\/h2>\n\n\n\n
                                                            Available rules vary, but important controls include:<\/p>\n\n\n\n
                                                              \n
                                                            • Restrict creations<\/li>\n\n\n\n
                                                            • Restrict updates<\/li>\n\n\n\n
                                                            • Restrict deletions<\/li>\n\n\n\n
                                                            • Require pull requests before merging<\/li>\n\n\n\n
                                                            • Require approvals<\/li>\n\n\n\n
                                                            • Require code-owner review<\/li>\n\n\n\n
                                                            • Require status checks<\/li>\n\n\n\n
                                                            • Require deployments<\/li>\n\n\n\n
                                                            • Require conversation resolution as part of applicable PR rules<\/li>\n\n\n\n
                                                            • Require signed commits<\/li>\n\n\n\n
                                                            • Require linear history<\/li>\n\n\n\n
                                                            • Block force pushes<\/li>\n\n\n\n
                                                            • Require code scanning results<\/li>\n\n\n\n
                                                            • Require secret scanning resolution<\/li>\n\n\n\n
                                                            • Require Code Quality results<\/li>\n\n\n\n
                                                            • Restrict code coverage<\/li>\n<\/ul>\n\n\n\n
                                                              Production default-branch baseline<\/h3>\n\n\n\n
                                                              A reasonable starting baseline for many teams is:<\/p>\n\n\n\n
                                                              Target: default branch\nRequire pull request: yes\nRequired approvals: 1 or 2 based on risk\nRequire code owners: for sensitive paths\nDismiss stale approvals: based on risk\nRequire status checks: build + test + security\nRequire conversation resolution: yes\nBlock force push: yes\nRestrict deletion: yes\nRequire signed commits: optional based on identity model\nRequire deployments: only when merge policy depends on staged validation\n<\/code><\/pre>\n\n\n\n
                                                              Do not blindly apply every control. Every requirement adds friction and should map to a real risk.<\/p>\n\n\n\n
                                                              \n\n\n\n
                                                              31. Push Rules<\/h2>\n\n\n\n
                                                              Push rulesets can block pushes based on content such as:<\/p>\n\n\n\n
                                                                \n
                                                              • File paths<\/li>\n\n\n\n
                                                              • File path length<\/li>\n\n\n\n
                                                              • File extensions<\/li>\n\n\n\n
                                                              • File size<\/li>\n<\/ul>\n\n\n\n
                                                                They apply to private\/internal repositories and their fork networks where the feature is available.<\/p>\n\n\n\n
                                                                Example uses<\/h3>\n\n\n\n
                                                                Block accidental binaries:<\/p>\n\n\n\n
                                                                *.exe\n*.dll\n*.iso\n<\/code><\/pre>\n\n\n\n
                                                                Block sensitive local configuration:<\/p>\n\n\n\n
                                                                .env\nsecrets\/**\n<\/code><\/pre>\n\n\n\n
                                                                Protect CI definitions from broad unreviewed changes by combining path rules with branch\/PR governance rather than relying on a single control.<\/p>\n\n\n\n
                                                                \n\n\n\n
                                                                32. Security and Quality Rules<\/h2>\n\n\n\n
                                                                Rulesets can make security\/quality analysis part of merge governance.<\/p>\n\n\n\n
                                                                32.1 Require code scanning results<\/h3>\n\n\n\n
                                                                Use when a required scanner such as CodeQL must complete and stay below a configured severity threshold.<\/p>\n\n\n\n
                                                                32.2 Require secret scanning alerts resolved<\/h3>\n\n\n\n
                                                                Use to stop merging when relevant newly introduced secrets remain unresolved.<\/p>\n\n\n\n
                                                                32.3 Require Code Quality results<\/h3>\n\n\n\n
                                                                Use to block pull requests when GitHub Code Quality exceeds a selected severity threshold.<\/p>\n\n\n\n
                                                                32.4 Restrict code coverage<\/h3>\n\n\n\n
                                                                Use when coverage is collected and a defined coverage rule should be enforced.<\/p>\n\n\n\n
                                                                \n\n\n\n
                                                                33. Ruleset Administration<\/h2>\n\n\n\n
                                                                Typical lifecycle:<\/p>\n\n\n\n
                                                                flowchart LR\n    D[Design Rule] --> E[Evaluate]\n    E --> I[Inspect Insights]\n    I --> T[Tune Rule]\n    T --> A[Activate]\n    A --> M[Monitor Bypasses]\n<\/code><\/pre>\n\n\n\n
                                                                Recommended rollout<\/h3>\n\n\n\n
                                                                  \n
                                                                1. Document desired policy.<\/li>\n\n\n\n
                                                                2. Create ruleset.<\/li>\n\n\n\n
                                                                3. Use Evaluate mode where supported.<\/li>\n\n\n\n
                                                                4. Review rule insights.<\/li>\n\n\n\n
                                                                5. Fix workflows or unnecessary blockers.<\/li>\n\n\n\n
                                                                6. Activate.<\/li>\n\n\n\n
                                                                7. Review bypass and failure trends.<\/li>\n<\/ol>\n\n\n\n
                                                                  Rulesets can also be imported\/exported and managed via REST\/GraphQL APIs.<\/p>\n\n\n\n
                                                                  \n\n\n\n
                                                                  34. Custom Properties<\/h2>\n\n\n\n
                                                                  Custom properties are organization-defined structured metadata attached to repositories.<\/p>\n\n\n\n
                                                                  Supported property types include:<\/p>\n\n\n\n
                                                                    \n
                                                                  • Text<\/li>\n\n\n\n
                                                                  • True\/false<\/li>\n\n\n\n
                                                                  • Single select<\/li>\n\n\n\n
                                                                  • Multi select<\/li>\n<\/ul>\n\n\n\n
                                                                    Useful property schema<\/h3>\n\n\n\n
                                                                    Property<\/th>Type<\/th>Example<\/th><\/tr><\/thead>
                                                                    owner_team<\/code><\/td>Single select<\/td>payments<\/code><\/td><\/tr>
                                                                    service_tier<\/code><\/td>Single select<\/td>tier-1<\/code><\/td><\/tr>
                                                                    production<\/code><\/td>Boolean<\/td>true<\/code><\/td><\/tr>
                                                                    data_classification<\/code><\/td>Single select<\/td>confidential<\/code><\/td><\/tr>
                                                                    lifecycle<\/code><\/td>Single select<\/td>active<\/code><\/td><\/tr>
                                                                    technology<\/code><\/td>Multi select<\/td>go<\/code>, postgres<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                                                                    Why properties matter<\/h3>\n\n\n\n
                                                                    They can support:<\/p>\n\n\n\n
                                                                      \n
                                                                    • Repository discovery<\/li>\n\n\n\n
                                                                    • Ruleset targeting<\/li>\n\n\n\n
                                                                    • Governance<\/li>\n\n\n\n
                                                                    • Automation<\/li>\n\n\n\n
                                                                    • Ownership reporting<\/li>\n\n\n\n
                                                                    • Compliance inventory<\/li>\n<\/ul>\n\n\n\n
                                                                      A mature organization should prefer structured properties over encoding all metadata in repository names.<\/p>\n\n\n\n
                                                                      \n\n\n\n
                                                                      35. Branch Administration<\/h2>\n\n\n\n
                                                                      Typical branch operations include:<\/p>\n\n\n\n
                                                                        \n
                                                                      • Rename<\/li>\n\n\n\n
                                                                      • Delete<\/li>\n\n\n\n
                                                                      • Restore<\/li>\n\n\n\n
                                                                      • Change default branch<\/li>\n\n\n\n
                                                                      • View protection\/rules<\/li>\n<\/ul>\n\n\n\n
                                                                        Branch naming example<\/h3>\n\n\n\n
                                                                        feature\/ABC-123-add-tax-rule\nbugfix\/ABC-456-fix-rounding\nrelease\/2026.09\nhotfix\/ABC-999-payment-timeout\n<\/code><\/pre>\n\n\n\n
                                                                        Branch naming conventions should support humans and automation without becoming unnecessarily rigid.<\/p>\n\n\n\n
                                                                        \n\n\n\n
                                                                        36. Legacy Branch Protection vs Rulesets<\/h2>\n\n\n\n
                                                                        Legacy branch protection remains supported, but rulesets provide a more composable governance model.<\/p>\n\n\n\n
                                                                        Branch protection<\/th>Rulesets<\/th><\/tr><\/thead>
                                                                        Only one matching branch-protection rule ultimately applies<\/td>Multiple rulesets can apply together<\/td><\/tr>
                                                                        Older policy model<\/td>Newer policy model<\/td><\/tr>
                                                                        Repository-focused<\/td>Repository and organization governance<\/td><\/tr>
                                                                        Limited aggregate visibility<\/td>Better rule visibility and insights<\/td><\/tr>
                                                                        No push-content ruleset model<\/td>Push rulesets available where eligible<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                                                                        GitHub provides conversion flows from branch protection to rulesets.<\/p>\n\n\n\n
                                                                        Migration approach<\/h3>\n\n\n\n
                                                                          \n
                                                                        1. Identify existing branch protection.<\/li>\n\n\n\n
                                                                        2. Convert to ruleset.<\/li>\n\n\n\n
                                                                        3. Use Evaluate mode if available.<\/li>\n\n\n\n
                                                                        4. Compare behavior.<\/li>\n\n\n\n
                                                                        5. Delete the old protection only after validation.<\/li>\n<\/ol>\n\n\n\n
                                                                          Be aware that not every legacy setting maps one-to-one in every scenario.<\/p>\n\n\n\n
                                                                          \n\n\n\n
                                                                          37. Tags and Tag Rulesets<\/h2>\n\n\n\n
                                                                          Tags frequently represent release boundaries, so tag mutation should be treated as a supply-chain concern.<\/p>\n\n\n\n
                                                                          A tag ruleset can restrict:<\/p>\n\n\n\n
                                                                            \n
                                                                          • Tag creation<\/li>\n\n\n\n
                                                                          • Tag updates<\/li>\n\n\n\n
                                                                          • Tag deletion<\/li>\n\n\n\n
                                                                          • Matching tag patterns<\/li>\n<\/ul>\n\n\n\n
                                                                            Example:<\/p>\n\n\n\n
                                                                            v*\nrelease-*\nprod-*\n<\/code><\/pre>\n\n\n\n
                                                                            For production release tags, combine tag governance with release immutability.<\/p>\n\n\n\n
                                                                            Part V \u2014 GitHub Actions Repository Settings<\/h1>\n\n\n\n
                                                                            38. Actions Permissions<\/h2>\n\n\n\n
                                                                            Repository Actions settings control whether workflows can run and which Actions or reusable workflows they may call.<\/p>\n\n\n\n
                                                                            Common policy choices include:<\/p>\n\n\n\n
                                                                              \n
                                                                            • Disable Actions entirely<\/li>\n\n\n\n
                                                                            • Allow all actions and reusable workflows<\/li>\n\n\n\n
                                                                            • Allow actions\/reusable workflows owned by your organization<\/li>\n\n\n\n
                                                                            • Allow selected actions\/reusable workflows<\/li>\n\n\n\n
                                                                            • Allow GitHub-owned actions<\/li>\n\n\n\n
                                                                            • Allow verified Marketplace creators where policy permits<\/li>\n<\/ul>\n\n\n\n
                                                                              Higher-level organization or enterprise policy can restrict these options.<\/p>\n\n\n\n
                                                                              Why this matters<\/h3>\n\n\n\n
                                                                              Every third-party Action is code executed inside your CI\/CD trust boundary. Treat it like a software dependency.<\/p>\n\n\n\n
                                                                              Recommended model<\/h3>\n\n\n\n
                                                                              Enterprise baseline\n        \u2193\nOrganization allowlist\n        \u2193\nRepository-specific narrowing\n        \u2193\nWorkflow-level least privilege\n<\/code><\/pre>\n\n\n\n
                                                                              Example allowlist philosophy<\/h3>\n\n\n\n
                                                                              Allow:\n- actions\/checkout pinned to a trusted version or SHA\n- actions\/setup-node pinned\n- actions\/cache pinned\n- organization-owned reusable workflows\n\nReview before allowing:\n- Unverified third-party actions\n- Actions with broad token permissions\n- Actions that download\/execute remote scripts\n<\/code><\/pre>\n\n\n\n
                                                                              \n\n\n\n
                                                                              39. Workflow Permissions and GITHUB_TOKEN<\/code><\/h2>\n\n\n\n
                                                                              Every GitHub Actions job can receive a repository-scoped GITHUB_TOKEN<\/code>.<\/p>\n\n\n\n
                                                                              Repository settings provide a default permission model, commonly either:<\/p>\n\n\n\n
                                                                                \n
                                                                              • Restricted read access<\/li>\n\n\n\n
                                                                              • Read\/write access<\/li>\n<\/ul>\n\n\n\n
                                                                                Workflow YAML can then further reduce permissions.<\/p>\n\n\n\n
                                                                                Recommended pattern<\/h3>\n\n\n\n
                                                                                Set a restrictive repository default, then grant only what a workflow requires.<\/p>\n\n\n\n
                                                                                name: CI\n\non:\n  pull_request:\n  push:\n    branches:\n      - main\n\npermissions:\n  contents: read\n\njobs:\n  test:\n    runs-on: ubuntu-latest\n    steps:\n      - uses: actions\/checkout@v7\n      - run: echo \"Run tests here\"\n<\/code><\/pre>\n\n\n\n
                                                                                A release workflow may need more:<\/p>\n\n\n\n
                                                                                permissions:\n  contents: write\n  id-token: write\n<\/code><\/pre>\n\n\n\n
                                                                                id-token: write<\/code> is commonly used for OIDC federation to cloud providers. It does not by itself grant cloud permissions; the cloud trust policy decides what the issued identity may do.<\/p>\n\n\n\n
                                                                                Pull request creation\/approval<\/h3>\n\n\n\n
                                                                                Repository settings can also control whether GitHub Actions is allowed to create and approve pull requests with GITHUB_TOKEN<\/code>.<\/p>\n\n\n\n
                                                                                Keep this disabled unless automation genuinely requires it.<\/p>\n\n\n\n
                                                                                \n\n\n\n
                                                                                40. Fork Pull Request Workflows<\/h2>\n\n\n\n
                                                                                Workflows triggered from forks are a special security boundary because the contributor may control code executed by the workflow.<\/p>\n\n\n\n
                                                                                Key questions:<\/p>\n\n\n\n
                                                                                  \n
                                                                                • Does the workflow receive a write-capable token?<\/li>\n\n\n\n
                                                                                • Are repository secrets available?<\/li>\n\n\n\n
                                                                                • Does a maintainer need to approve the run?<\/li>\n\n\n\n
                                                                                • Is the event\u00a0pull_request<\/code>\u00a0or\u00a0pull_request_target<\/code>?<\/li>\n<\/ul>\n\n\n\n
                                                                                  Safe principle<\/h3>\n\n\n\n
                                                                                  Treat code from an untrusted fork as untrusted input.<\/p>\n\n\n\n
                                                                                  Never expose production credentials simply because a pull request needs CI.<\/p>\n\n\n\n
                                                                                  \n\n\n\n
                                                                                  41. Private Actions and Reusable Workflow Access<\/h2>\n\n\n\n
                                                                                  A private repository can contain:<\/p>\n\n\n\n
                                                                                    \n
                                                                                  • Composite\/Docker\/JavaScript Actions<\/li>\n\n\n\n
                                                                                  • Reusable workflows<\/li>\n<\/ul>\n\n\n\n
                                                                                    Repository settings can control whether other repositories in the same user\/organization context can access them.<\/p>\n\n\n\n
                                                                                    Real-world pattern<\/h3>\n\n\n\n
                                                                                    platform-workflows\n  .github\/workflows\/build.yml\n  .github\/workflows\/deploy.yml\n\nservice-a\n  calls platform-workflows\/build.yml\n\nservice-b\n  calls platform-workflows\/build.yml\n<\/code><\/pre>\n\n\n\n
                                                                                    Central reusable workflows reduce policy drift but create a shared dependency. Protect the reusable-workflow repository with stronger change control than an ordinary application repository.<\/p>\n\n\n\n
                                                                                    \n\n\n\n
                                                                                    42. Workflow, Check, Status, Artifact, and Log Retention<\/h2>\n\n\n\n
                                                                                    GitHub lets repository administrators configure retention for workflow-related data subject to organization\/enterprise maximums.<\/p>\n\n\n\n
                                                                                    Current September 2026 note<\/h3>\n\n\n\n
                                                                                    GitHub documentation states that beginning October 1, 2026<\/strong>, configured retention policies will also apply to checks, workflow runs, and commit statuses. Until that date, those objects may be retained for 400+ days even when a shorter retention setting is configured. Artifacts and logs already follow the configured retention behavior.<\/p>\n\n\n\n
                                                                                    Typical configured ranges:<\/p>\n\n\n\n
                                                                                    Repository type<\/th>Configurable retention<\/th><\/tr><\/thead>
                                                                                    Public<\/td>1\u201390 days<\/td><\/tr>
                                                                                    Private\/internal<\/td>1\u2013400 days<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                                                                                    The default is commonly 90 days, subject to higher-level policy.<\/p>\n\n\n\n
                                                                                    Choosing retention<\/h3>\n\n\n\n
                                                                                    Repository<\/th>Example policy<\/th><\/tr><\/thead>
                                                                                    Public OSS<\/td>30\u201390 days<\/td><\/tr>
                                                                                    Standard internal app<\/td>30\u201390 days<\/td><\/tr>
                                                                                    Regulated release pipeline<\/td>Align with audit evidence requirement<\/td><\/tr>
                                                                                    High-volume test repository<\/td>Shorter if compliance allows<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                                                                                    Do not use Actions retention as your only long-term audit archive when legal or regulatory evidence must be preserved independently.<\/p>\n\n\n\n
                                                                                    \n\n\n\n
                                                                                    43. Actions Cache Settings<\/h2>\n\n\n\n
                                                                                    GitHub can configure repository cache retention and a total cache size eviction limit.<\/p>\n\n\n\n
                                                                                    Current documented defaults include:<\/p>\n\n\n\n
                                                                                      \n
                                                                                    • Cache retention: 7 days<\/li>\n\n\n\n
                                                                                    • Total cache size limit: 10 GB<\/li>\n<\/ul>\n\n\n\n
                                                                                      For eligible plans, administrators can raise limits within GitHub and organization maximums. GitHub documentation currently describes up to 90 days for public repositories and 365 days for private\/internal repositories, with repository cache-size limits up to higher account-specific maximums.<\/p>\n\n\n\n
                                                                                      Cache is not artifact storage<\/h3>\n\n\n\n
                                                                                      Cache<\/th>Artifact<\/th><\/tr><\/thead>
                                                                                      Speeds future workflow runs<\/td>Preserves workflow output<\/td><\/tr>
                                                                                      Eviction expected<\/td>Retained for configured evidence\/output period<\/td><\/tr>
                                                                                      Key-based retrieval<\/td>Run-associated download<\/td><\/tr>
                                                                                      Should be reproducible<\/td>May contain release\/test evidence<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                                                                                      \n\n\n\n
                                                                                      44. Repository Runners<\/h2>\n\n\n\n
                                                                                      A repository can use:<\/p>\n\n\n\n
                                                                                        \n
                                                                                      • GitHub-hosted runners<\/li>\n\n\n\n
                                                                                      • Repository self-hosted runners<\/li>\n\n\n\n
                                                                                      • Organization runners<\/li>\n\n\n\n
                                                                                      • Enterprise runners<\/li>\n<\/ul>\n\n\n\n
                                                                                        Repository-scoped self-hosted runner<\/h3>\n\n\n\n
                                                                                        Use only when the runner should be dedicated to one repository.<\/p>\n\n\n\n
                                                                                        Organization runner<\/h3>\n\n\n\n
                                                                                        Prefer when multiple repositories need the same controlled execution environment.<\/p>\n\n\n\n
                                                                                        Security rule<\/h3>\n\n\n\n
                                                                                        A self-hosted runner executes repository-controlled workflow code on infrastructure you operate. Protect it accordingly.<\/p>\n\n\n\n
                                                                                        Recommended<\/strong><\/p>\n\n\n\n
                                                                                          \n
                                                                                        • Ephemeral runners for untrusted or high-risk workloads<\/li>\n\n\n\n
                                                                                        • Network segmentation<\/li>\n\n\n\n
                                                                                        • Minimal credentials<\/li>\n\n\n\n
                                                                                        • Short-lived OIDC credentials<\/li>\n\n\n\n
                                                                                        • Patch automation<\/li>\n\n\n\n
                                                                                        • Runner groups for scope control<\/li>\n<\/ul>\n\n\n\n
                                                                                          Avoid<\/strong><\/p>\n\n\n\n
                                                                                            \n
                                                                                          • Long-lived cloud keys on the host<\/li>\n\n\n\n
                                                                                          • Shared production network access for arbitrary PR jobs<\/li>\n\n\n\n
                                                                                          • Reusing a dirty workspace for unrelated security domains<\/li>\n<\/ul>\n\n\n\n
                                                                                            \n\n\n\n
                                                                                            Part VI \u2014 Webhooks<\/h1>\n\n\n\n
                                                                                            45. Repository Webhooks<\/h2>\n\n\n\n
                                                                                            Webhooks send HTTP requests to external services when selected GitHub events occur.<\/p>\n\n\n\n
                                                                                            Core settings<\/h3>\n\n\n\n
                                                                                              \n
                                                                                            • Payload URL<\/li>\n\n\n\n
                                                                                            • Content type<\/li>\n\n\n\n
                                                                                            • Secret<\/li>\n\n\n\n
                                                                                            • SSL verification<\/li>\n\n\n\n
                                                                                            • Event subscriptions<\/li>\n\n\n\n
                                                                                            • Active\/inactive state<\/li>\n<\/ul>\n\n\n\n
                                                                                              Typical events<\/h3>\n\n\n\n
                                                                                                \n
                                                                                              • push<\/code><\/li>\n\n\n\n
                                                                                              • pull_request<\/code><\/li>\n\n\n\n
                                                                                              • issues<\/code><\/li>\n\n\n\n
                                                                                              • release<\/code><\/li>\n\n\n\n
                                                                                              • deployment<\/code><\/li>\n\n\n\n
                                                                                              • workflow-related events<\/li>\n\n\n\n
                                                                                              • package events<\/li>\n\n\n\n
                                                                                              • repository events<\/li>\n\n\n\n
                                                                                              • security events where supported<\/li>\n<\/ul>\n\n\n\n
                                                                                                Architecture<\/h3>\n\n\n\n
                                                                                                flowchart LR\n    G[GitHub Event] --> W[Webhook Delivery]\n    W --> A[Receiver API]\n    A --> V[Verify Signature]\n    V --> Q[Queue or Worker]\n    Q --> B[Business Logic]\n<\/code><\/pre>\n\n\n\n
                                                                                                Do not perform expensive processing before validating the request.<\/p>\n\n\n\n
                                                                                                \n\n\n\n
                                                                                                46. Webhook Security<\/h2>\n\n\n\n
                                                                                                Use HTTPS and configure a strong webhook secret.<\/p>\n\n\n\n
                                                                                                GitHub signs webhook payloads. The receiver should verify the signature from the X-Hub-Signature-256<\/code> header using HMAC SHA-256.<\/p>\n\n\n\n
                                                                                                Python verification example<\/h3>\n\n\n\n
                                                                                                import hashlib\nimport hmac\n\n\ndef valid_signature(secret: bytes, body: bytes, header: str) -> bool:\n    expected = \"sha256=\" + hmac.new(\n        secret,\n        body,\n        hashlib.sha256,\n    ).hexdigest()\n\n    return hmac.compare_digest(expected, header)\n<\/code><\/pre>\n\n\n\n
                                                                                                Important controls<\/h3>\n\n\n\n
                                                                                                  \n
                                                                                                • Verify the signature before parsing trusted fields.<\/li>\n\n\n\n
                                                                                                • Use constant-time comparison.<\/li>\n\n\n\n
                                                                                                • Keep the webhook secret out of source code.<\/li>\n\n\n\n
                                                                                                • Reject unexpected content types.<\/li>\n\n\n\n
                                                                                                • Consider idempotency\/replay handling.<\/li>\n\n\n\n
                                                                                                • Log the GitHub delivery ID for troubleshooting.<\/li>\n<\/ul>\n\n\n\n
                                                                                                  \n\n\n\n
                                                                                                  47. Webhook Delivery Operations<\/h2>\n\n\n\n
                                                                                                  GitHub provides delivery history that can show:<\/p>\n\n\n\n
                                                                                                    \n
                                                                                                  • Request headers<\/li>\n\n\n\n
                                                                                                  • Request payload<\/li>\n\n\n\n
                                                                                                  • Response status<\/li>\n\n\n\n
                                                                                                  • Response body<\/li>\n\n\n\n
                                                                                                  • Delivery duration<\/li>\n\n\n\n
                                                                                                  • Redelivery controls<\/li>\n\n\n\n
                                                                                                  • Ping\/test deliveries<\/li>\n<\/ul>\n\n\n\n
                                                                                                    Troubleshooting flow<\/h3>\n\n\n\n
                                                                                                    flowchart TD\n    F[Webhook Failed] --> D[Open Delivery]\n    D --> S{HTTP Status}\n    S -->|2xx| L[Inspect Receiver Logic]\n    S -->|4xx| A[Check Auth or Payload]\n    S -->|5xx| E[Check Server Error]\n    S -->|Timeout| N[Check Network and Latency]\n<\/code><\/pre>\n\n\n\n
                                                                                                    \n\n\n\n
                                                                                                    Part VII \u2014 Copilot Repository Settings<\/h1>\n\n\n\n
                                                                                                    48. Copilot Repository Controls<\/h2>\n\n\n\n
                                                                                                    Copilot repository settings are increasingly important because GitHub now supports repository-level behavior for code review and cloud agents.<\/p>\n\n\n\n
                                                                                                    Availability depends on:<\/p>\n\n\n\n
                                                                                                      \n
                                                                                                    • Copilot plan<\/li>\n\n\n\n
                                                                                                    • Organization\/enterprise policy<\/li>\n\n\n\n
                                                                                                    • Feature rollout<\/li>\n\n\n\n
                                                                                                    • Repository eligibility<\/li>\n<\/ul>\n\n\n\n
                                                                                                      \n\n\n\n
                                                                                                      49. Copilot Code Review<\/h2>\n\n\n\n
                                                                                                      Copilot code review can review pull requests and use repository-specific instructions.<\/p>\n\n\n\n
                                                                                                      Repository admins can control whether custom instructions are used for Copilot reviews.<\/p>\n\n\n\n
                                                                                                      Repository-wide instruction file<\/h3>\n\n\n\n
                                                                                                      .github\/copilot-instructions.md\n<\/code><\/pre>\n\n\n\n
                                                                                                      Example:<\/p>\n\n\n\n
                                                                                                      # Repository review instructions\n\n- Prefer small, backward-compatible changes.\n- Flag SQL queries that do not use parameter binding.\n- Require unit tests for new business logic.\n- Do not suggest changing public API behavior without documenting migration impact.\n<\/code><\/pre>\n\n\n\n
                                                                                                      Path-specific instructions<\/h3>\n\n\n\n
                                                                                                      GitHub supports path-specific instruction files under patterns such as:<\/p>\n\n\n\n
                                                                                                      .github\/instructions\/*.instructions.md\n<\/code><\/pre>\n\n\n\n
                                                                                                      Use these when different areas of a monorepo need different standards.<\/p>\n\n\n\n
                                                                                                      Agent instruction files<\/h3>\n\n\n\n
                                                                                                      GitHub Copilot features can also consume agent-oriented repository context such as AGENTS.md<\/code>, depending on the Copilot experience being used.<\/p>\n\n\n\n
                                                                                                      The source syllabus also lists CLAUDE.md<\/code> and GEMINI.md<\/code>; these are agent\/tool-specific files rather than universal GitHub repository settings. Do not assume every GitHub Copilot surface consumes every third-party agent file. Verify support for the exact Copilot feature before standardizing around them.<\/p>\n\n\n\n
                                                                                                      \n\n\n\n
                                                                                                      50. Copilot MCP Servers<\/h2>\n\n\n\n
                                                                                                      GitHub supports repository-level Model Context Protocol configuration for Copilot cloud agent and Copilot code review.<\/p>\n\n\n\n
                                                                                                      What MCP does<\/h3>\n\n\n\n
                                                                                                      MCP allows Copilot to call approved tools exposed by configured MCP servers.<\/p>\n\n\n\n
                                                                                                      Examples:<\/p>\n\n\n\n
                                                                                                        \n
                                                                                                      • Internal documentation search<\/li>\n\n\n\n
                                                                                                      • Issue tracker lookup<\/li>\n\n\n\n
                                                                                                      • Service catalog lookup<\/li>\n\n\n\n
                                                                                                      • Test tools<\/li>\n\n\n\n
                                                                                                      • Incident context<\/li>\n<\/ul>\n\n\n\n
                                                                                                        Security warning<\/h3>\n\n\n\n
                                                                                                        Configured MCP tools can be invoked autonomously by supported Copilot agents. Treat an MCP server as privileged integration code.<\/p>\n\n\n\n
                                                                                                        Recommended<\/strong><\/p>\n\n\n\n
                                                                                                          \n
                                                                                                        • Allowlist specific tools<\/li>\n\n\n\n
                                                                                                        • Prefer read-only tools for review use cases<\/li>\n\n\n\n
                                                                                                        • Scope secrets narrowly<\/li>\n\n\n\n
                                                                                                        • Validate tool output<\/li>\n\n\n\n
                                                                                                        • Avoid broad filesystem\/network access<\/li>\n<\/ul>\n\n\n\n
                                                                                                          GitHub currently documents built-in GitHub and Playwright MCP integrations in this area, and repository MCP configuration can be shared between Copilot cloud agent and code review.<\/p>\n\n\n\n
                                                                                                          Current limitation to understand<\/h3>\n\n\n\n
                                                                                                          Support differs by Copilot surface. For example, code review applies safety constraints to tools and expects read-only semantics for supported MCP review tools.<\/p>\n\n\n\n
                                                                                                          \n\n\n\n
                                                                                                          51. Copilot Cloud Agent \/ Coding Agent<\/h2>\n\n\n\n
                                                                                                          Repository configuration for cloud agents may include:<\/p>\n\n\n\n
                                                                                                            \n
                                                                                                          • Repository access<\/li>\n\n\n\n
                                                                                                          • Development environment setup<\/li>\n\n\n\n
                                                                                                          • Agent instructions<\/li>\n\n\n\n
                                                                                                          • Agent secrets<\/li>\n\n\n\n
                                                                                                          • Agent variables<\/li>\n\n\n\n
                                                                                                          • MCP configuration<\/li>\n\n\n\n
                                                                                                          • Pull request creation behavior<\/li>\n<\/ul>\n\n\n\n
                                                                                                            Safe agent design<\/h3>\n\n\n\n
                                                                                                            Read code\n   \u2193\nUnderstand instructions\n   \u2193\nCreate isolated change\n   \u2193\nRun tests\n   \u2193\nOpen pull request\n   \u2193\nHuman review + repository rules\n<\/code><\/pre>\n\n\n\n
                                                                                                            Do not bypass branch governance just because a change was created by an AI agent.<\/p>\n\n\n\n
                                                                                                            \n\n\n\n
                                                                                                            Part VIII \u2014 Planning and Issue Configuration<\/h1>\n\n\n\n
                                                                                                            52. Issue Templates<\/h2>\n\n\n\n
                                                                                                            Issue templates improve input quality and reduce repeated clarification.<\/p>\n\n\n\n
                                                                                                            Markdown template example<\/h3>\n\n\n\n
                                                                                                            ---\nname: Bug report\nabout: Report a reproducible defect\nlabels: bug\n---\n\n## What happened?\n\n## Expected behavior\n\n## Steps to reproduce\n\n1.\n2.\n3.\n\n## Environment\n\n## Logs or screenshots\n<\/code><\/pre>\n\n\n\n
                                                                                                            \n\n\n\n
                                                                                                            53. Issue Forms<\/h2>\n\n\n\n
                                                                                                            Issue Forms provide structured YAML-driven input.<\/p>\n\n\n\n
                                                                                                            Example:<\/p>\n\n\n\n
                                                                                                            name: Bug report\ndescription: Report a reproducible product defect\ntitle: \"[Bug]: \"\nlabels:\n  - bug\nbody:\n  - type: markdown\n    attributes:\n      value: \"Thanks for helping us improve the project.\"\n\n  - type: textarea\n    id: description\n    attributes:\n      label: What happened?\n      description: Describe the problem.\n    validations:\n      required: true\n\n  - type: input\n    id: version\n    attributes:\n      label: Version\n      placeholder: \"v2.3.1\"\n    validations:\n      required: true\n\n  - type: dropdown\n    id: environment\n    attributes:\n      label: Environment\n      options:\n        - Development\n        - Staging\n        - Production\n    validations:\n      required: true\n<\/code><\/pre>\n\n\n\n
                                                                                                            Template chooser configuration<\/h3>\n\n\n\n
                                                                                                            Use .github\/ISSUE_TEMPLATE\/config.yml<\/code> for options such as blank-issue behavior and external contact links.<\/p>\n\n\n\n
                                                                                                            \n\n\n\n
                                                                                                            54. Issue Metadata<\/h2>\n\n\n\n
                                                                                                            Repository planning commonly uses:<\/p>\n\n\n\n
                                                                                                              \n
                                                                                                            • Labels<\/li>\n\n\n\n
                                                                                                            • Assignees<\/li>\n\n\n\n
                                                                                                            • Milestones<\/li>\n\n\n\n
                                                                                                            • Issue types where available<\/li>\n\n\n\n
                                                                                                            • Parent\/sub-issue relationships<\/li>\n\n\n\n
                                                                                                            • Project fields<\/li>\n<\/ul>\n\n\n\n
                                                                                                              Keep labels small and meaningful<\/h3>\n\n\n\n
                                                                                                              Good:<\/p>\n\n\n\n
                                                                                                              kind\/bug\nkind\/feature\npriority\/p1\npriority\/p2\narea\/api\narea\/frontend\nstatus\/blocked\n<\/code><\/pre>\n\n\n\n
                                                                                                              Avoid hundreds of overlapping labels that nobody understands.<\/p>\n\n\n\n
                                                                                                              \n\n\n\n
                                                                                                              55. Automatic Planning Behavior<\/h2>\n\n\n\n
                                                                                                              Repositories can connect work through:<\/p>\n\n\n\n
                                                                                                              Issue \u2192 Branch \u2192 Pull Request \u2192 Review \u2192 Merge \u2192 Issue closure \u2192 Project automation\n<\/code><\/pre>\n\n\n\n
                                                                                                              Use consistent issue\/PR relationships so reporting and automation have reliable signals.<\/p>\n\n\n\n
                                                                                                              \n\n\n\n
                                                                                                              Part IX \u2014 Deployment Environments<\/h1>\n\n\n\n
                                                                                                              56. What Is a GitHub Environment?<\/h2>\n\n\n\n
                                                                                                              An environment represents a deployment target such as:<\/p>\n\n\n\n
                                                                                                                \n
                                                                                                              • development<\/code><\/li>\n\n\n\n
                                                                                                              • staging<\/code><\/li>\n\n\n\n
                                                                                                              • uat<\/code><\/li>\n\n\n\n
                                                                                                              • production<\/code><\/li>\n<\/ul>\n\n\n\n
                                                                                                                An environment can provide:<\/p>\n\n\n\n
                                                                                                                  \n
                                                                                                                • Required reviewers<\/li>\n\n\n\n
                                                                                                                • Wait timers<\/li>\n\n\n\n
                                                                                                                • Deployment branch\/tag restrictions<\/li>\n\n\n\n
                                                                                                                • Custom protection rules<\/li>\n\n\n\n
                                                                                                                • Environment secrets<\/li>\n\n\n\n
                                                                                                                • Environment variables<\/li>\n<\/ul>\n\n\n\n
                                                                                                                  A job references an environment:<\/p>\n\n\n\n
                                                                                                                  jobs:\n  deploy:\n    environment: production\n    runs-on: ubuntu-latest\n    steps:\n      - run: echo \"Deploy production\"\n<\/code><\/pre>\n\n\n\n
                                                                                                                  Protection rules are evaluated before the job gets access to the environment’s protected secrets.<\/p>\n\n\n\n
                                                                                                                  \n\n\n\n
                                                                                                                  57. Required Reviewers<\/h2>\n\n\n\n
                                                                                                                  Required reviewers create a human approval gate before deployment.<\/p>\n\n\n\n
                                                                                                                  GitHub documentation currently supports selecting up to six users or teams as reviewers for an environment; only one approval is required for the deployment to proceed unless your broader process adds additional controls.<\/p>\n\n\n\n
                                                                                                                  You can also prevent self-review.<\/p>\n\n\n\n
                                                                                                                  Use case<\/h3>\n\n\n\n
                                                                                                                  Deployment initiated by developer\n        \u2193\nProduction environment gate\n        \u2193\nSRE or release team approval\n        \u2193\nEnvironment secrets released to job\n        \u2193\nDeployment runs\n<\/code><\/pre>\n\n\n\n
                                                                                                                  \n\n\n\n
                                                                                                                  58. Wait Timers<\/h2>\n\n\n\n
                                                                                                                  A wait timer delays a deployment for a configured period.<\/p>\n\n\n\n
                                                                                                                  Use cases:<\/p>\n\n\n\n
                                                                                                                    \n
                                                                                                                  • Observation window<\/li>\n\n\n\n
                                                                                                                  • Change freeze delay<\/li>\n\n\n\n
                                                                                                                  • Staged rollout<\/li>\n\n\n\n
                                                                                                                  • Manual cancellation opportunity<\/li>\n<\/ul>\n\n\n\n
                                                                                                                    Current GitHub documentation allows wait timers from 1 minute up to 43,200 minutes (30 days) where the plan supports them.<\/p>\n\n\n\n
                                                                                                                    \n\n\n\n
                                                                                                                    59. Deployment Branches and Tags<\/h2>\n\n\n\n
                                                                                                                    Environment rules can restrict which refs may deploy.<\/p>\n\n\n\n
                                                                                                                    Typical choices include:<\/p>\n\n\n\n
                                                                                                                      \n
                                                                                                                    • No restriction<\/li>\n\n\n\n
                                                                                                                    • Protected branches only<\/li>\n\n\n\n
                                                                                                                    • Selected branch\/tag patterns<\/li>\n<\/ul>\n\n\n\n
                                                                                                                      Production example<\/h3>\n\n\n\n
                                                                                                                      Allowed:\nmain\nv*\n\nDenied:\nfeature\/*\n<\/code><\/pre>\n\n\n\n
                                                                                                                      A release process can therefore require both:<\/p>\n\n\n\n
                                                                                                                        \n
                                                                                                                      1. Repository rule allows merge\/tag operation.<\/li>\n\n\n\n
                                                                                                                      2. Environment rule allows deployment from the resulting ref.<\/li>\n<\/ol>\n\n\n\n
                                                                                                                        \n\n\n\n
                                                                                                                        60. Custom Deployment Protection Rules<\/h2>\n\n\n\n
                                                                                                                        GitHub Apps can implement external deployment gates.<\/p>\n\n\n\n
                                                                                                                        Examples:<\/p>\n\n\n\n
                                                                                                                          \n
                                                                                                                        • Change-management ticket approved<\/li>\n\n\n\n
                                                                                                                        • Monitoring health acceptable<\/li>\n\n\n\n
                                                                                                                        • Security scan passed<\/li>\n\n\n\n
                                                                                                                        • Maintenance window open<\/li>\n\n\n\n
                                                                                                                        • External release orchestrator approved<\/li>\n<\/ul>\n\n\n\n
                                                                                                                          This is a powerful extension point for enterprise release governance.<\/p>\n\n\n\n
                                                                                                                          \n\n\n\n
                                                                                                                          61. Environment Secrets<\/h2>\n\n\n\n
                                                                                                                          Environment secrets are only made available to jobs that reference the environment and satisfy its protection requirements.<\/p>\n\n\n\n
                                                                                                                          Example access:<\/p>\n\n\n\n
                                                                                                                          - name: Use deployment credential\n  env:\n    DEPLOY_TOKEN: ${{ secrets.DEPLOY_TOKEN }}\n  run: .\/deploy.sh\n<\/code><\/pre>\n\n\n\n
                                                                                                                          Prefer OIDC for cloud authentication where possible so long-lived cloud keys do not need to be stored as environment secrets.<\/p>\n\n\n\n
                                                                                                                          \n\n\n\n
                                                                                                                          62. Environment Variables<\/h2>\n\n\n\n
                                                                                                                          Environment variables are non-secret configuration values exposed through the vars<\/code> context.<\/p>\n\n\n\n
                                                                                                                          Example:<\/p>\n\n\n\n
                                                                                                                          - run: echo \"Deploying to ${{ vars.REGION }}\"\n<\/code><\/pre>\n\n\n\n
                                                                                                                          Good uses:<\/p>\n\n\n\n
                                                                                                                            \n
                                                                                                                          • Region<\/li>\n\n\n\n
                                                                                                                          • Environment name<\/li>\n\n\n\n
                                                                                                                          • Feature toggle defaults<\/li>\n\n\n\n
                                                                                                                          • Non-sensitive endpoint names<\/li>\n<\/ul>\n\n\n\n
                                                                                                                            Do not place credentials in variables.<\/p>\n\n\n\n
                                                                                                                            \n\n\n\n
                                                                                                                            Part X \u2014 GitHub Pages<\/h1>\n\n\n\n
                                                                                                                            63. GitHub Pages<\/h2>\n\n\n\n
                                                                                                                            GitHub Pages publishes static websites from repository content.<\/p>\n\n\n\n
                                                                                                                            Common uses:<\/p>\n\n\n\n
                                                                                                                              \n
                                                                                                                            • Project documentation<\/li>\n\n\n\n
                                                                                                                            • Internal documentation on eligible enterprise configurations<\/li>\n\n\n\n
                                                                                                                            • Static product sites<\/li>\n\n\n\n
                                                                                                                            • Training material<\/li>\n<\/ul>\n\n\n\n
                                                                                                                              Publishing methods<\/h3>\n\n\n\n
                                                                                                                                \n
                                                                                                                              1. Deploy from a branch<\/li>\n\n\n\n
                                                                                                                              2. Deploy with GitHub Actions<\/li>\n<\/ol>\n\n\n\n
                                                                                                                                \n\n\n\n
                                                                                                                                64. Branch Publishing Source<\/h2>\n\n\n\n
                                                                                                                                Branch publishing can use:<\/p>\n\n\n\n
                                                                                                                                  \n
                                                                                                                                • Repository root\u00a0\/<\/code><\/li>\n\n\n\n
                                                                                                                                • \/docs<\/code>\u00a0directory<\/li>\n<\/ul>\n\n\n\n
                                                                                                                                  Example:<\/p>\n\n\n\n
                                                                                                                                  main\n\u2514\u2500\u2500 docs\/\n    \u251c\u2500\u2500 index.html\n    \u2514\u2500\u2500 assets\/\n<\/code><\/pre>\n\n\n\n
                                                                                                                                  Use branch publishing when you do not need a custom build pipeline.<\/p>\n\n\n\n
                                                                                                                                  \n\n\n\n
                                                                                                                                  65. GitHub Actions Pages Deployment<\/h2>\n\n\n\n
                                                                                                                                  Use Actions when the site must be built first.<\/p>\n\n\n\n
                                                                                                                                  Typical flow:<\/p>\n\n\n\n
                                                                                                                                  flowchart LR\n    P[Push] --> B[Build Site]\n    B --> U[Upload Pages Artifact]\n    U --> D[Deploy Pages]\n    D --> W[Website]\n<\/code><\/pre>\n\n\n\n
                                                                                                                                  GitHub’s Pages workflow typically uses a github-pages<\/code> environment.<\/p>\n\n\n\n
                                                                                                                                  \n\n\n\n
                                                                                                                                  66. Custom Domains<\/h2>\n\n\n\n
                                                                                                                                  A Pages site can use a custom domain.<\/p>\n\n\n\n
                                                                                                                                  Common DNS records:<\/p>\n\n\n\n
                                                                                                                                    \n
                                                                                                                                  • CNAME<\/code>\u00a0for a subdomain<\/li>\n\n\n\n
                                                                                                                                  • A<\/code>\/AAAA<\/code>\u00a0or DNS-provider-supported apex configuration for root domains<\/li>\n<\/ul>\n\n\n\n
                                                                                                                                    Critical security practice<\/h3>\n\n\n\n
                                                                                                                                    Verify the domain and remove stale DNS when a Pages site or repository is retired. Abandoned DNS records can create domain takeover risk.<\/p>\n\n\n\n
                                                                                                                                    \n\n\n\n
                                                                                                                                    67. HTTPS<\/h2>\n\n\n\n
                                                                                                                                    Use HTTPS enforcement when available.<\/p>\n\n\n\n
                                                                                                                                    GitHub provisions TLS certificates for supported Pages custom-domain configurations after DNS is correctly configured.<\/p>\n\n\n\n
                                                                                                                                    Troubleshoot HTTPS problems by checking:<\/p>\n\n\n\n
                                                                                                                                      \n
                                                                                                                                    • DNS correctness<\/li>\n\n\n\n
                                                                                                                                    • CAA restrictions<\/li>\n\n\n\n
                                                                                                                                    • Existing conflicting records<\/li>\n\n\n\n
                                                                                                                                    • Domain ownership\/verification<\/li>\n\n\n\n
                                                                                                                                    • Certificate provisioning delay<\/li>\n<\/ul>\n\n\n\n
                                                                                                                                      \n\n\n\n
                                                                                                                                      68. Pages Visibility<\/h2>\n\n\n\n
                                                                                                                                      Do not assume a Pages site inherits repository visibility.<\/p>\n\n\n\n
                                                                                                                                      GitHub Pages behavior depends on plan and enterprise configuration. Public Pages can be internet-accessible even when the source repository is private. Eligible enterprise configurations can support privately published Pages.<\/p>\n\n\n\n
                                                                                                                                      Always verify the Pages site’s effective visibility independently from repository visibility.<\/p>\n\n\n\n
                                                                                                                                      Part XI \u2014 Advanced Security<\/h1>\n\n\n\n
                                                                                                                                      69. Security and Analysis Overview<\/h2>\n\n\n\n
                                                                                                                                      Repository security settings can include several distinct products and controls. GitHub’s 2026 terminology increasingly separates capabilities into products such as Code Security and Secret Protection, while the repository navigation still groups many controls under Advanced Security<\/strong> or Security and quality<\/strong>.<\/p>\n\n\n\n
                                                                                                                                      Think in layers:<\/p>\n\n\n\n
                                                                                                                                      flowchart TD\n    D[Dependency Risk] --> DG[Dependency Graph and Dependabot]\n    C[Code Risk] --> CS[Code Scanning and AI Scan]\n    S[Secret Risk] --> SS[Secret Scanning and Push Protection]\n    Q[Quality Risk] --> CQ[Code Quality]\n    DG --> G[Merge Governance]\n    CS --> G\n    SS --> G\n    CQ --> G\n<\/code><\/pre>\n\n\n\n
                                                                                                                                      Do not assume all private repositories receive all advanced features automatically. Availability depends on visibility, plan, and the security products enabled for the organization\/enterprise.<\/p>\n\n\n\n
                                                                                                                                      \n\n\n\n
                                                                                                                                      70. Dependency Graph<\/h2>\n\n\n\n
                                                                                                                                      The dependency graph parses supported manifest and lock files to understand direct and transitive dependencies.<\/p>\n\n\n\n
                                                                                                                                      Examples include ecosystem files such as:<\/p>\n\n\n\n
                                                                                                                                      package.json\npackage-lock.json\npom.xml\nbuild.gradle\nrequirements.txt\npoetry.lock\nGemfile.lock\ngo.mod\nCargo.lock\n<\/code><\/pre>\n\n\n\n
                                                                                                                                      The exact list varies by ecosystem and evolves over time.<\/p>\n\n\n\n
                                                                                                                                      Why it matters<\/h3>\n\n\n\n
                                                                                                                                      The dependency graph is foundational for:<\/p>\n\n\n\n
                                                                                                                                        \n
                                                                                                                                      • Dependabot alerts<\/li>\n\n\n\n
                                                                                                                                      • Security updates<\/li>\n\n\n\n
                                                                                                                                      • Dependency review<\/li>\n\n\n\n
                                                                                                                                      • Dependency inventory<\/li>\n\n\n\n
                                                                                                                                      • Supply-chain visibility<\/li>\n<\/ul>\n\n\n\n
                                                                                                                                        \n\n\n\n
                                                                                                                                        71. Dependabot Alerts<\/h2>\n\n\n\n
                                                                                                                                        Dependabot alerts notify repository maintainers when a dependency is affected by a known vulnerability in GitHub’s advisory data.<\/p>\n\n\n\n
                                                                                                                                        Alert workflow<\/h3>\n\n\n\n
                                                                                                                                        Manifest\/lock file\n      \u2193\nDependency graph\n      \u2193\nKnown vulnerable version\n      \u2193\nDependabot alert\n      \u2193\nTriage \/ upgrade \/ dismiss with reason\n<\/code><\/pre>\n\n\n\n
                                                                                                                                        Best practices<\/h3>\n\n\n\n
                                                                                                                                          \n
                                                                                                                                        • Assign ownership for alerts.<\/li>\n\n\n\n
                                                                                                                                        • Prioritize exploitable\/runtime dependencies over blanket severity-only handling.<\/li>\n\n\n\n
                                                                                                                                        • Record dismissal reasons.<\/li>\n\n\n\n
                                                                                                                                        • Keep manifests and lock files committed where appropriate.<\/li>\n<\/ul>\n\n\n\n
                                                                                                                                          \n\n\n\n
                                                                                                                                          72. Dependabot Security Updates<\/h2>\n\n\n\n
                                                                                                                                          Dependabot security updates can automatically open pull requests that upgrade vulnerable dependencies to a secure version where GitHub can determine an update path.<\/p>\n\n\n\n
                                                                                                                                          Use security updates together with normal CI and repository rules. Automation should not bypass tests or review.<\/p>\n\n\n\n
                                                                                                                                          \n\n\n\n
                                                                                                                                          73. Dependabot Version Updates<\/h2>\n\n\n\n
                                                                                                                                          Version updates are configured with:<\/p>\n\n\n\n
                                                                                                                                          .github\/dependabot.yml\n<\/code><\/pre>\n\n\n\n
                                                                                                                                          Example:<\/p>\n\n\n\n
                                                                                                                                          version: 2\nupdates:\n  - package-ecosystem: npm\n    directory: \"\/\"\n    schedule:\n      interval: weekly\n    open-pull-requests-limit: 5\n<\/code><\/pre>\n\n\n\n
                                                                                                                                          For private registries, use Dependabot-specific credentials rather than assuming Actions repository secrets are available.<\/p>\n\n\n\n
                                                                                                                                          \n\n\n\n
                                                                                                                                          74. Dependency Review<\/h2>\n\n\n\n
                                                                                                                                          Dependency review analyzes dependency changes introduced by a pull request.<\/p>\n\n\n\n
                                                                                                                                          Useful checks include:<\/p>\n\n\n\n
                                                                                                                                            \n
                                                                                                                                          • Newly introduced vulnerable dependency<\/li>\n\n\n\n
                                                                                                                                          • Version change<\/li>\n\n\n\n
                                                                                                                                          • License information<\/li>\n\n\n\n
                                                                                                                                          • Dependency additions\/removals<\/li>\n<\/ul>\n\n\n\n
                                                                                                                                            A mature PR policy asks not only \u201cdoes the code compile?\u201d but also \u201cwhat new software supply-chain risk does this PR introduce?\u201d<\/p>\n\n\n\n
                                                                                                                                            \n\n\n\n
                                                                                                                                            75. Code Scanning<\/h2>\n\n\n\n
                                                                                                                                            Code scanning identifies potential vulnerabilities and coding errors.<\/p>\n\n\n\n
                                                                                                                                            Setup models<\/h3>\n\n\n\n
                                                                                                                                            GitHub supports:<\/p>\n\n\n\n
                                                                                                                                              \n
                                                                                                                                            • Default setup<\/strong>\u00a0\u2014 low-maintenance CodeQL configuration<\/li>\n\n\n\n
                                                                                                                                            • Advanced setup<\/strong>\u00a0\u2014 workflow-driven, highly customizable scanning<\/li>\n\n\n\n
                                                                                                                                            • Third-party SARIF upload<\/strong>\u00a0\u2014 integrate supported scanners through SARIF<\/li>\n<\/ul>\n\n\n\n
                                                                                                                                              Recommended starting point<\/h3>\n\n\n\n
                                                                                                                                              Use default setup unless you have a concrete reason to need advanced workflow customization.<\/p>\n\n\n\n
                                                                                                                                              SARIF<\/h3>\n\n\n\n
                                                                                                                                              SARIF is a JSON-based static-analysis result format. GitHub currently supports the relevant subset of SARIF 2.1.0 for code scanning integrations.<\/p>\n\n\n\n
                                                                                                                                              Typical third-party flow:<\/p>\n\n\n\n
                                                                                                                                              flowchart LR\n    C[Code] --> T[Third Party Scanner]\n    T --> S[SARIF File]\n    S --> G[GitHub Code Scanning]\n    G --> A[Alert]\n<\/code><\/pre>\n\n\n\n
                                                                                                                                              \n\n\n\n
                                                                                                                                              76. CodeQL Default Setup<\/h2>\n\n\n\n
                                                                                                                                              Default setup is designed to minimize workflow maintenance.<\/p>\n\n\n\n
                                                                                                                                              It can scan supported languages on:<\/p>\n\n\n\n
                                                                                                                                                \n
                                                                                                                                              • Pushes to the default\/protected branches<\/li>\n\n\n\n
                                                                                                                                              • Pull requests targeting relevant protected\/default branches<\/li>\n\n\n\n
                                                                                                                                              • Scheduled analysis according to GitHub behavior<\/li>\n<\/ul>\n\n\n\n
                                                                                                                                                Use the tool-status view when troubleshooting coverage or scan errors.<\/p>\n\n\n\n
                                                                                                                                                \n\n\n\n
                                                                                                                                                77. CodeQL Advanced Setup<\/h2>\n\n\n\n
                                                                                                                                                Use advanced setup when you need capabilities beyond default setup, for example:<\/p>\n\n\n\n
                                                                                                                                                  \n
                                                                                                                                                • Custom build steps<\/li>\n\n\n\n
                                                                                                                                                • Matrix behavior<\/li>\n\n\n\n
                                                                                                                                                • More granular triggers<\/li>\n\n\n\n
                                                                                                                                                • Custom query packs\/suites<\/li>\n\n\n\n
                                                                                                                                                • Complex generated-code handling<\/li>\n\n\n\n
                                                                                                                                                • External CI orchestration<\/li>\n<\/ul>\n\n\n\n
                                                                                                                                                  The tradeoff is more configuration and more long-term maintenance.<\/p>\n\n\n\n
                                                                                                                                                  \n\n\n\n
                                                                                                                                                  78. AI Scan for Pull Requests<\/h2>\n\n\n\n
                                                                                                                                                  As of September 2026, AI Scan for pull requests is in public preview<\/strong>.<\/p>\n\n\n\n
                                                                                                                                                  Its purpose is to extend security detection to languages and frameworks that CodeQL does not cover well or at all.<\/p>\n\n\n\n
                                                                                                                                                  Current important characteristics:<\/p>\n\n\n\n
                                                                                                                                                    \n
                                                                                                                                                  • Runs on pull requests<\/li>\n\n\n\n
                                                                                                                                                  • Complements CodeQL rather than replacing it<\/li>\n\n\n\n
                                                                                                                                                  • Findings are PR-oriented rather than a full default-branch backlog equivalent<\/li>\n\n\n\n
                                                                                                                                                  • Requires code scanning to be enabled<\/li>\n\n\n\n
                                                                                                                                                  • As of the September 16, 2026 update, it no longer requires CodeQL default setup<\/li>\n\n\n\n
                                                                                                                                                  • Public preview availability currently depends on GitHub Advanced Security eligibility and Copilot licensing\/AI-credit conditions described by GitHub<\/li>\n\n\n\n
                                                                                                                                                  • Not supported on GitHub Enterprise Server for this preview release<\/li>\n<\/ul>\n\n\n\n
                                                                                                                                                    Treat preview behavior as subject to change.<\/p>\n\n\n\n
                                                                                                                                                    \n\n\n\n
                                                                                                                                                    79. Secret Scanning<\/h2>\n\n\n\n
                                                                                                                                                    Secret scanning detects credentials and secret-like values committed to supported GitHub surfaces.<\/p>\n\n\n\n
                                                                                                                                                    Detection can include:<\/p>\n\n\n\n
                                                                                                                                                      \n
                                                                                                                                                    • Provider patterns<\/li>\n\n\n\n
                                                                                                                                                    • Non-provider patterns<\/li>\n\n\n\n
                                                                                                                                                    • Custom patterns<\/li>\n\n\n\n
                                                                                                                                                    • Generic AI-assisted detection where available<\/li>\n<\/ul>\n\n\n\n
                                                                                                                                                      Response lifecycle<\/h3>\n\n\n\n
                                                                                                                                                      Secret detected\n    \u2193\nDetermine validity\n    \u2193\nRevoke \/ rotate credential\n    \u2193\nRemove exposure if appropriate\n    \u2193\nClose alert with reason\n<\/code><\/pre>\n\n\n\n
                                                                                                                                                      Removing a secret from the latest commit is not enough if the credential is still valid. Rotation\/revocation is the primary response.<\/strong><\/p>\n\n\n\n
                                                                                                                                                      \n\n\n\n
                                                                                                                                                      80. Push Protection<\/h2>\n\n\n\n
                                                                                                                                                      Push protection attempts to stop supported secrets before they enter the repository.<\/p>\n\n\n\n
                                                                                                                                                      A contributor may be blocked when GitHub detects a secret in the push.<\/p>\n\n\n\n
                                                                                                                                                      Organizations can define bypass workflows and, in some configurations, review bypass requests or exempt trusted actors.<\/p>\n\n\n\n
                                                                                                                                                      Best practice<\/h3>\n\n\n\n
                                                                                                                                                      Keep bypass narrow and auditable. If a secret must be bypassed because it is a false positive, document the reason rather than teaching developers to bypass every block.<\/p>\n\n\n\n
                                                                                                                                                      \n\n\n\n
                                                                                                                                                      Part XII \u2014 GitHub Code Quality<\/h1>\n\n\n\n
                                                                                                                                                      81. What Is GitHub Code Quality?<\/h2>\n\n\n\n
                                                                                                                                                      GitHub Code Quality is a repository\/organization feature that analyzes code for quality concerns such as maintainability and reliability and integrates findings into pull request and default-branch workflows.<\/p>\n\n\n\n
                                                                                                                                                      As of September 2026, GitHub documents Code Quality for GitHub Team and GitHub Enterprise Cloud customers, subject to enterprise enablement and billing\/licensing conditions.<\/p>\n\n\n\n
                                                                                                                                                      GitHub’s current implementation combines deterministic CodeQL quality queries with AI-powered analysis in supported scenarios.<\/p>\n\n\n\n
                                                                                                                                                      \n\n\n\n
                                                                                                                                                      82. Enabling Code Quality<\/h2>\n\n\n\n
                                                                                                                                                      Typical repository flow:<\/p>\n\n\n\n
                                                                                                                                                        \n
                                                                                                                                                      1. Open\u00a0Settings<\/strong>.<\/li>\n\n\n\n
                                                                                                                                                      2. Open\u00a0Code quality<\/strong>\u00a0under the security\/quality area.<\/li>\n\n\n\n
                                                                                                                                                      3. Enable Code Quality.<\/li>\n\n\n\n
                                                                                                                                                      4. Select supported languages if exposed.<\/li>\n\n\n\n
                                                                                                                                                      5. Choose runner type if required.<\/li>\n\n\n\n
                                                                                                                                                      6. Save.<\/li>\n<\/ol>\n\n\n\n
                                                                                                                                                        GitHub Actions must be enabled because Code Quality analysis uses Actions execution.<\/p>\n\n\n\n
                                                                                                                                                        \n\n\n\n
                                                                                                                                                        83. Code Quality Pull Request Controls<\/h2>\n\n\n\n
                                                                                                                                                        Code Quality can feed rulesets.<\/p>\n\n\n\n
                                                                                                                                                        A branch ruleset can enable Require code quality results<\/strong> and define the lowest result severity that must be resolved before merge.<\/p>\n\n\n\n
                                                                                                                                                        Rollout model<\/h3>\n\n\n\n
                                                                                                                                                        Enable Code Quality\n      \u2193\nObserve findings\n      \u2193\nTune team workflow\n      \u2193\nRuleset in Evaluate mode\n      \u2193\nSet quality threshold\n      \u2193\nActivate merge protection\n<\/code><\/pre>\n\n\n\n
                                                                                                                                                        Do not turn on a strict blocking threshold across hundreds of repositories before measuring the baseline.<\/p>\n\n\n\n
                                                                                                                                                        \n\n\n\n
                                                                                                                                                        84. Code Coverage<\/h2>\n\n\n\n
                                                                                                                                                        GitHub Code Quality can integrate code coverage into the repository quality experience and ruleset governance.<\/p>\n\n\n\n
                                                                                                                                                        Use coverage to answer:<\/p>\n\n\n\n
                                                                                                                                                          \n
                                                                                                                                                        • Which changed code is untested?<\/li>\n\n\n\n
                                                                                                                                                        • Is coverage decreasing?<\/li>\n\n\n\n
                                                                                                                                                        • Should a pull request be blocked below a defined threshold?<\/li>\n<\/ul>\n\n\n\n
                                                                                                                                                          Coverage percentage is a signal, not proof of test quality. High coverage with weak assertions can still provide poor protection.<\/p>\n\n\n\n
                                                                                                                                                          \n\n\n\n
                                                                                                                                                          Part XIII \u2014 Deploy Keys, Secrets, and Variables<\/h1>\n\n\n\n
                                                                                                                                                          85. Deploy Keys<\/h2>\n\n\n\n
                                                                                                                                                          A deploy key is an SSH public key attached directly to one repository.<\/p>\n\n\n\n
                                                                                                                                                          The corresponding private key normally lives on a machine or deployment system.<\/p>\n\n\n\n
                                                                                                                                                          Deploy keys can be:<\/p>\n\n\n\n
                                                                                                                                                            \n
                                                                                                                                                          • Read-only<\/li>\n\n\n\n
                                                                                                                                                          • Write-enabled<\/li>\n<\/ul>\n\n\n\n
                                                                                                                                                            Common use case<\/h3>\n\n\n\n
                                                                                                                                                            A legacy deployment server needs to clone one private repository without acting as a human user.<\/p>\n\n\n\n
                                                                                                                                                            Security characteristics<\/h3>\n\n\n\n
                                                                                                                                                            Advantages<\/strong><\/p>\n\n\n\n
                                                                                                                                                              \n
                                                                                                                                                            • Repository-scoped<\/li>\n\n\n\n
                                                                                                                                                            • Simple SSH model<\/li>\n\n\n\n
                                                                                                                                                            • No user account required for the key itself<\/li>\n<\/ul>\n\n\n\n
                                                                                                                                                              Risks<\/strong><\/p>\n\n\n\n
                                                                                                                                                                \n
                                                                                                                                                              • Private key may be long-lived<\/li>\n\n\n\n
                                                                                                                                                              • Rotation is manual<\/li>\n\n\n\n
                                                                                                                                                              • Write access can be dangerous<\/li>\n\n\n\n
                                                                                                                                                              • Poor fit for dynamic multi-repository automation<\/li>\n<\/ul>\n\n\n\n
                                                                                                                                                                Prefer GitHub Apps or OIDC-capable automation when you need scalable, short-lived, centrally governable authentication.<\/p>\n\n\n\n
                                                                                                                                                                \n\n\n\n
                                                                                                                                                                86. Deploy Key Rotation<\/h2>\n\n\n\n
                                                                                                                                                                Recommended procedure:<\/p>\n\n\n\n
                                                                                                                                                                  \n
                                                                                                                                                                1. Generate a new SSH key pair.<\/li>\n\n\n\n
                                                                                                                                                                2. Install the new public key as a deploy key.<\/li>\n\n\n\n
                                                                                                                                                                3. Update the consumer with the new private key.<\/li>\n\n\n\n
                                                                                                                                                                4. Verify access.<\/li>\n\n\n\n
                                                                                                                                                                5. Remove the old deploy key.<\/li>\n\n\n\n
                                                                                                                                                                6. Destroy the old private key.<\/li>\n\n\n\n
                                                                                                                                                                7. Record rotation evidence.<\/li>\n<\/ol>\n\n\n\n
                                                                                                                                                                  Example key generation:<\/p>\n\n\n\n
                                                                                                                                                                  ssh-keygen -t ed25519 -C \"deploy-payment-api\" -f .\/payment-api-deploy\n<\/code><\/pre>\n\n\n\n
                                                                                                                                                                  Protect the private key with appropriate host and secret-management controls.<\/p>\n\n\n\n
                                                                                                                                                                  \n\n\n\n
                                                                                                                                                                  87. Actions Repository Secrets<\/h2>\n\n\n\n
                                                                                                                                                                  Repository secrets are encrypted values intended for workflow use.<\/p>\n\n\n\n
                                                                                                                                                                  Create with GitHub CLI:<\/p>\n\n\n\n
                                                                                                                                                                  gh secret set API_TOKEN --repo \"$OWNER\/$REPO\"\n<\/code><\/pre>\n\n\n\n
                                                                                                                                                                  List secret names:<\/p>\n\n\n\n
                                                                                                                                                                  gh secret list --repo \"$OWNER\/$REPO\"\n<\/code><\/pre>\n\n\n\n
                                                                                                                                                                  GitHub does not return secret plaintext after storage.<\/p>\n\n\n\n
                                                                                                                                                                  Best practice<\/h3>\n\n\n\n
                                                                                                                                                                  Use secret scope deliberately:<\/p>\n\n\n\n
                                                                                                                                                                  Scope<\/th>Use<\/th><\/tr><\/thead>
                                                                                                                                                                  Organization<\/td>Shared secret across selected repositories<\/td><\/tr>
                                                                                                                                                                  Repository<\/td>Secret applies to whole repository<\/td><\/tr>
                                                                                                                                                                  Environment<\/td>Secret only for a deployment environment<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                                                                                                                                                                  Prefer the narrowest practical scope.<\/p>\n\n\n\n
                                                                                                                                                                  \n\n\n\n
                                                                                                                                                                  88. Actions Variables<\/h2>\n\n\n\n
                                                                                                                                                                  Variables are for non-sensitive configuration.<\/p>\n\n\n\n
                                                                                                                                                                  Create:<\/p>\n\n\n\n
                                                                                                                                                                  gh variable set REGION --body \"ap-northeast-1\" --repo \"$OWNER\/$REPO\"\n<\/code><\/pre>\n\n\n\n
                                                                                                                                                                  Use in workflow:<\/p>\n\n\n\n
                                                                                                                                                                  - run: echo \"Region is ${{ vars.REGION }}\"\n<\/code><\/pre>\n\n\n\n
                                                                                                                                                                  Never rely on a variable being masked as a secret.<\/p>\n\n\n\n
                                                                                                                                                                  \n\n\n\n
                                                                                                                                                                  89. Dependabot Secrets<\/h2>\n\n\n\n
                                                                                                                                                                  Dependabot uses its own secret store for authentication to private package registries and related update operations.<\/p>\n\n\n\n
                                                                                                                                                                  This separation matters because Dependabot-triggered workflows do not automatically receive normal Actions secrets in the same way as trusted Actions events.<\/p>\n\n\n\n
                                                                                                                                                                  \n\n\n\n
                                                                                                                                                                  90. Codespaces Secrets<\/h2>\n\n\n\n
                                                                                                                                                                  Codespaces can use repository\/user\/organization scoped secrets for development environments.<\/p>\n\n\n\n
                                                                                                                                                                  Use them for development-time credentials that should not be committed to the repository.<\/p>\n\n\n\n
                                                                                                                                                                  Do not turn Codespaces secrets into a substitute for production deployment credential management.<\/p>\n\n\n\n
                                                                                                                                                                  \n\n\n\n
                                                                                                                                                                  91. Copilot \/ Agent Secrets and Variables<\/h2>\n\n\n\n
                                                                                                                                                                  GitHub’s current repository settings may expose secrets and variables for cloud agents and MCP-related use cases.<\/p>\n\n\n\n
                                                                                                                                                                  Treat these credentials as privileged automation credentials:<\/p>\n\n\n\n
                                                                                                                                                                    \n
                                                                                                                                                                  • Scope them to the smallest system surface<\/li>\n\n\n\n
                                                                                                                                                                  • Prefer read-only access where practical<\/li>\n\n\n\n
                                                                                                                                                                  • Rotate them<\/li>\n\n\n\n
                                                                                                                                                                  • Avoid sharing production credentials with agent tooling unless the use case is explicitly designed and reviewed for it<\/li>\n<\/ul>\n\n\n\n
                                                                                                                                                                    \n\n\n\n
                                                                                                                                                                    92. OIDC Instead of Long-Lived Cloud Secrets<\/h2>\n\n\n\n
                                                                                                                                                                    For cloud deployments, prefer OpenID Connect where the cloud provider supports it.<\/p>\n\n\n\n
                                                                                                                                                                    Workflow:<\/p>\n\n\n\n
                                                                                                                                                                    flowchart LR\n    W[GitHub Workflow] --> O[OIDC Token]\n    O --> C[Cloud Identity Provider]\n    C --> R[Short Lived Role]\n    R --> D[Deploy]\n<\/code><\/pre>\n\n\n\n
                                                                                                                                                                    Minimal permission block:<\/p>\n\n\n\n
                                                                                                                                                                    permissions:\n  contents: read\n  id-token: write\n<\/code><\/pre>\n\n\n\n
                                                                                                                                                                    Then constrain the cloud trust policy by repository, branch, environment, or other supported claims.<\/p>\n\n\n\n
                                                                                                                                                                    \n\n\n\n
                                                                                                                                                                    Part XIV \u2014 GitHub Apps and Email Notifications<\/h1>\n\n\n\n
                                                                                                                                                                    93. Installed GitHub Apps<\/h2>\n\n\n\n
                                                                                                                                                                    A GitHub App can be installed on an account and granted access to:<\/p>\n\n\n\n
                                                                                                                                                                      \n
                                                                                                                                                                    • All repositories<\/li>\n\n\n\n
                                                                                                                                                                    • Selected repositories<\/li>\n<\/ul>\n\n\n\n
                                                                                                                                                                      The app receives only the repository and organization permissions it requests and the installation grants.<\/p>\n\n\n\n
                                                                                                                                                                      Repository settings can show Apps that currently have access to the repository, but changing an installation may redirect you to the owning account’s app installation configuration because app access is managed at installation scope.<\/p>\n\n\n\n
                                                                                                                                                                      Review checklist<\/h3>\n\n\n\n
                                                                                                                                                                      [ ] Is this app still needed?\n[ ] Does it need all repositories?\n[ ] Are requested permissions justified?\n[ ] Can write\/admin permissions be reduced?\n[ ] Is the publisher trusted?\n[ ] Is there an owner for the integration?\n<\/code><\/pre>\n\n\n\n
                                                                                                                                                                      \n\n\n\n
                                                                                                                                                                      94. GitHub App Permissions<\/h2>\n\n\n\n
                                                                                                                                                                      Repository permissions can cover areas such as:<\/p>\n\n\n\n
                                                                                                                                                                        \n
                                                                                                                                                                      • Contents<\/li>\n\n\n\n
                                                                                                                                                                      • Issues<\/li>\n\n\n\n
                                                                                                                                                                      • Pull requests<\/li>\n\n\n\n
                                                                                                                                                                      • Actions<\/li>\n\n\n\n
                                                                                                                                                                      • Checks<\/li>\n\n\n\n
                                                                                                                                                                      • Deployments<\/li>\n\n\n\n
                                                                                                                                                                      • Environments<\/li>\n\n\n\n
                                                                                                                                                                      • Metadata<\/li>\n\n\n\n
                                                                                                                                                                      • Security events<\/li>\n<\/ul>\n\n\n\n
                                                                                                                                                                        The exact permission set evolves. Review the app’s requested permissions at installation time and during periodic audits.<\/p>\n\n\n\n
                                                                                                                                                                        GitHub App vs PAT<\/h3>\n\n\n\n
                                                                                                                                                                        GitHub App<\/th>Personal access token<\/th><\/tr><\/thead>
                                                                                                                                                                        App identity<\/td>User identity<\/td><\/tr>
                                                                                                                                                                        Installation-scoped<\/td>User\/account-scoped<\/td><\/tr>
                                                                                                                                                                        Fine-grained permissions<\/td>Depends on token type<\/td><\/tr>
                                                                                                                                                                        Short-lived installation tokens<\/td>PAT often longer-lived<\/td><\/tr>
                                                                                                                                                                        Better for platform integrations<\/td>Useful for user-driven tooling<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                                                                                                                                                                        For service automation, GitHub Apps are generally easier to govern at scale than a shared human PAT.<\/p>\n\n\n\n
                                                                                                                                                                        \n\n\n\n
                                                                                                                                                                        95. Push Email Notifications<\/h2>\n\n\n\n
                                                                                                                                                                        Repository administrators can configure email notifications for pushes.<\/p>\n\n\n\n
                                                                                                                                                                        Current GitHub documentation supports up to two destination addresses directly. A group mailbox can be used when more recipients are needed.<\/p>\n\n\n\n
                                                                                                                                                                        Push emails include useful metadata such as:<\/p>\n\n\n\n
                                                                                                                                                                          \n
                                                                                                                                                                        • Repository<\/li>\n\n\n\n
                                                                                                                                                                        • Branch<\/li>\n\n\n\n
                                                                                                                                                                        • Commit SHA<\/li>\n\n\n\n
                                                                                                                                                                        • Author<\/li>\n\n\n\n
                                                                                                                                                                        • Commit message<\/li>\n\n\n\n
                                                                                                                                                                        • Changed files\/diff links<\/li>\n<\/ul>\n\n\n\n
                                                                                                                                                                          GitHub also supports an approved header value that a receiving system can use as an additional trust signal.<\/p>\n\n\n\n
                                                                                                                                                                          \n\n\n\n
                                                                                                                                                                          Part XV \u2014 Policy Inheritance and Governance Architecture<\/h1>\n\n\n\n
                                                                                                                                                                          96. Organization Policy Overrides<\/h2>\n\n\n\n
                                                                                                                                                                          Organization-level controls can affect repository behavior for areas including:<\/p>\n\n\n\n
                                                                                                                                                                            \n
                                                                                                                                                                          • Actions<\/li>\n\n\n\n
                                                                                                                                                                          • Rulesets<\/li>\n\n\n\n
                                                                                                                                                                          • Security configurations<\/li>\n\n\n\n
                                                                                                                                                                          • Custom properties<\/li>\n\n\n\n
                                                                                                                                                                          • Base repository permissions<\/li>\n\n\n\n
                                                                                                                                                                          • Copilot policy<\/li>\n\n\n\n
                                                                                                                                                                          • GitHub App policy<\/li>\n\n\n\n
                                                                                                                                                                          • Repository visibility and lifecycle operations<\/li>\n<\/ul>\n\n\n\n
                                                                                                                                                                            A repository admin may therefore encounter a locked setting with an explanation that organization policy controls it.<\/p>\n\n\n\n
                                                                                                                                                                            \n\n\n\n
                                                                                                                                                                            97. Enterprise Policy Overrides<\/h2>\n\n\n\n
                                                                                                                                                                            Enterprise controls can add another policy layer for:<\/p>\n\n\n\n
                                                                                                                                                                              \n
                                                                                                                                                                            • Actions<\/li>\n\n\n\n
                                                                                                                                                                            • Identity<\/li>\n\n\n\n
                                                                                                                                                                            • Repository visibility<\/li>\n\n\n\n
                                                                                                                                                                            • Security products<\/li>\n\n\n\n
                                                                                                                                                                            • Network controls<\/li>\n\n\n\n
                                                                                                                                                                            • Apps\/integrations<\/li>\n\n\n\n
                                                                                                                                                                            • Copilot<\/li>\n<\/ul>\n\n\n\n
                                                                                                                                                                              Troubleshooting rule<\/h3>\n\n\n\n
                                                                                                                                                                              When a repository setting appears impossible to change, inspect policy from the top down:<\/p>\n\n\n\n
                                                                                                                                                                              Enterprise \u2192 Organization \u2192 Repository \u2192 Environment \u2192 Workflow\n<\/code><\/pre>\n\n\n\n
                                                                                                                                                                              \n\n\n\n
                                                                                                                                                                              98. Repository Governance Architecture<\/h2>\n\n\n\n
                                                                                                                                                                              A scalable repository model separates concerns:<\/p>\n\n\n\n
                                                                                                                                                                              flowchart TD\n    I[Identity and Access] --> R[Repository]\n    P[Policy and Rulesets] --> R\n    S[Security Configuration] --> R\n    A[Actions Standards] --> R\n    R --> C[Code Change]\n    C --> T[Tests and Scans]\n    T --> M[Merge]\n    M --> E[Environment Gate]\n    E --> D[Deployment]\n<\/code><\/pre>\n\n\n\n
                                                                                                                                                                              Access model<\/h3>\n\n\n\n
                                                                                                                                                                              Prefer:<\/p>\n\n\n\n
                                                                                                                                                                              Organization membership\n      \u2193\nTeam membership\n      \u2193\nRepository role\n<\/code><\/pre>\n\n\n\n
                                                                                                                                                                              Use direct collaborators as exceptions, not the normal architecture.<\/p>\n\n\n\n
                                                                                                                                                                              Security model<\/h3>\n\n\n\n
                                                                                                                                                                              Layer:<\/p>\n\n\n\n
                                                                                                                                                                                \n
                                                                                                                                                                              • Rulesets<\/li>\n\n\n\n
                                                                                                                                                                              • CODEOWNERS<\/li>\n\n\n\n
                                                                                                                                                                              • Required checks<\/li>\n\n\n\n
                                                                                                                                                                              • Code scanning<\/li>\n\n\n\n
                                                                                                                                                                              • Secret scanning<\/li>\n\n\n\n
                                                                                                                                                                              • Push protection<\/li>\n\n\n\n
                                                                                                                                                                              • Code Quality<\/li>\n\n\n\n
                                                                                                                                                                              • Protected environments<\/li>\n\n\n\n
                                                                                                                                                                              • Deployment approvals<\/li>\n<\/ul>\n\n\n\n
                                                                                                                                                                                No single control replaces the others.<\/p>\n\n\n\n
                                                                                                                                                                                \n\n\n\n
                                                                                                                                                                                99. CI\/CD Governance Model<\/h2>\n\n\n\n
                                                                                                                                                                                A strong repository pipeline uses multiple enforcement points:<\/p>\n\n\n\n
                                                                                                                                                                                Action allowlist\n      \u2193\nMinimal GITHUB_TOKEN\n      \u2193\nPinned dependencies\/actions\n      \u2193\nProtected default branch\n      \u2193\nRequired CI checks\n      \u2193\nOIDC authentication\n      \u2193\nProtected environment\n      \u2193\nDeployment approval\n<\/code><\/pre>\n\n\n\n
                                                                                                                                                                                Supply-chain baseline<\/h3>\n\n\n\n
                                                                                                                                                                                  \n
                                                                                                                                                                                • Pin critical third-party Actions to immutable commits where practical.<\/li>\n\n\n\n
                                                                                                                                                                                • Review action source and maintainer trust.<\/li>\n\n\n\n
                                                                                                                                                                                • Prefer organization-owned reusable workflows.<\/li>\n\n\n\n
                                                                                                                                                                                • Use artifact attestations\/provenance where appropriate.<\/li>\n\n\n\n
                                                                                                                                                                                • Protect workflow files through CODEOWNERS and rules.<\/li>\n<\/ul>\n\n\n\n
                                                                                                                                                                                  \n\n\n\n
                                                                                                                                                                                  Part XVI \u2014 Repository APIs and CLI Administration<\/h1>\n\n\n\n
                                                                                                                                                                                  100. REST API Fundamentals<\/h2>\n\n\n\n
                                                                                                                                                                                  GitHub’s REST API is versioned. As of this guide, current documentation examples use:<\/p>\n\n\n\n
                                                                                                                                                                                  X-GitHub-Api-Version: 2026-03-10\n<\/code><\/pre>\n\n\n\n
                                                                                                                                                                                  When using gh api<\/code>, GitHub CLI handles authentication for you.<\/p>\n\n\n\n
                                                                                                                                                                                  Read repository configuration<\/h3>\n\n\n\n
                                                                                                                                                                                  gh api \\\n  -H \"X-GitHub-Api-Version: 2026-03-10\" \\\n  \"\/repos\/$OWNER\/$REPO\"\n<\/code><\/pre>\n\n\n\n
                                                                                                                                                                                  Extract selected values:<\/p>\n\n\n\n
                                                                                                                                                                                  gh api \\\n  -H \"X-GitHub-Api-Version: 2026-03-10\" \\\n  \"\/repos\/$OWNER\/$REPO\" \\\n  --jq '{name,visibility,default_branch,archived,has_issues,has_wiki}'\n<\/code><\/pre>\n\n\n\n
                                                                                                                                                                                  \n\n\n\n
                                                                                                                                                                                  101. Update Repository Settings with REST<\/h2>\n\n\n\n
                                                                                                                                                                                  Many General settings are exposed through the repository update endpoint.<\/p>\n\n\n\n
                                                                                                                                                                                  Example:<\/p>\n\n\n\n
                                                                                                                                                                                  gh api \\\n  --method PATCH \\\n  -H \"X-GitHub-Api-Version: 2026-03-10\" \\\n  \"\/repos\/$OWNER\/$REPO\" \\\n  -f has_wiki=false \\\n  -f delete_branch_on_merge=true\n<\/code><\/pre>\n\n\n\n
                                                                                                                                                                                  Before scripting a setting at scale, confirm the current REST field and plan requirements in GitHub’s endpoint documentation.<\/p>\n\n\n\n
                                                                                                                                                                                  \n\n\n\n
                                                                                                                                                                                  102. Collaborators API<\/h2>\n\n\n\n
                                                                                                                                                                                  List collaborators:<\/p>\n\n\n\n
                                                                                                                                                                                  gh api \\\n  -H \"X-GitHub-Api-Version: 2026-03-10\" \\\n  \"\/repos\/$OWNER\/$REPO\/collaborators\"\n<\/code><\/pre>\n\n\n\n
                                                                                                                                                                                  Check a specific user’s permission with the appropriate collaborators-permission endpoint when building access audits.<\/p>\n\n\n\n
                                                                                                                                                                                  For organization repositories, remember that direct-collaborator data is only part of the effective-access picture; teams and base permissions matter too.<\/p>\n\n\n\n
                                                                                                                                                                                  \n\n\n\n
                                                                                                                                                                                  103. Rulesets API<\/h2>\n\n\n\n
                                                                                                                                                                                  List repository rulesets:<\/p>\n\n\n\n
                                                                                                                                                                                  gh api \\\n  -H \"X-GitHub-Api-Version: 2026-03-10\" \\\n  \"\/repos\/$OWNER\/$REPO\/rulesets\"\n<\/code><\/pre>\n\n\n\n
                                                                                                                                                                                  Use API automation for:<\/p>\n\n\n\n
                                                                                                                                                                                    \n
                                                                                                                                                                                  • Repository bootstrap<\/li>\n\n\n\n
                                                                                                                                                                                  • Policy drift detection<\/li>\n\n\n\n
                                                                                                                                                                                  • Ruleset inventory<\/li>\n\n\n\n
                                                                                                                                                                                  • Migration reporting<\/li>\n\n\n\n
                                                                                                                                                                                  • Rule insights\/rule suite analysis<\/li>\n<\/ul>\n\n\n\n
                                                                                                                                                                                    Keep desired-state policy in version control rather than constructing large JSON bodies manually in shell history.<\/p>\n\n\n\n
                                                                                                                                                                                    \n\n\n\n
                                                                                                                                                                                    104. Actions Administration API<\/h2>\n\n\n\n
                                                                                                                                                                                    Repository Actions APIs can manage or inspect areas such as:<\/p>\n\n\n\n
                                                                                                                                                                                      \n
                                                                                                                                                                                    • Actions permissions<\/li>\n\n\n\n
                                                                                                                                                                                    • Workflow permissions<\/li>\n\n\n\n
                                                                                                                                                                                    • Runners<\/li>\n\n\n\n
                                                                                                                                                                                    • Caches<\/li>\n\n\n\n
                                                                                                                                                                                    • Artifacts<\/li>\n\n\n\n
                                                                                                                                                                                    • Secrets metadata<\/li>\n\n\n\n
                                                                                                                                                                                    • Variables<\/li>\n<\/ul>\n\n\n\n
                                                                                                                                                                                      Example: inspect repository Actions permissions:<\/p>\n\n\n\n
                                                                                                                                                                                      gh api \\\n  -H \"X-GitHub-Api-Version: 2026-03-10\" \\\n  \"\/repos\/$OWNER\/$REPO\/actions\/permissions\"\n<\/code><\/pre>\n\n\n\n
                                                                                                                                                                                      \n\n\n\n
                                                                                                                                                                                      105. Environment API<\/h2>\n\n\n\n
                                                                                                                                                                                      REST endpoints support creating\/configuring deployment environments and associated protection\/deployment policies.<\/p>\n\n\n\n
                                                                                                                                                                                      Use APIs when environments must be standardized across many repositories.<\/p>\n\n\n\n
                                                                                                                                                                                      Typical desired state:<\/p>\n\n\n\n
                                                                                                                                                                                      {\n  \"environment\": \"production\",\n  \"prevent_self_review\": true,\n  \"allowed_refs\": [\"main\", \"v*\"]\n}\n<\/code><\/pre>\n\n\n\n
                                                                                                                                                                                      The JSON above is conceptual; use the current GitHub REST schema for actual API requests because reviewer and deployment-policy payloads have specific endpoint structures.<\/p>\n\n\n\n
                                                                                                                                                                                      \n\n\n\n
                                                                                                                                                                                      106. Webhooks API<\/h2>\n\n\n\n
                                                                                                                                                                                      Repository webhook APIs support:<\/p>\n\n\n\n
                                                                                                                                                                                        \n
                                                                                                                                                                                      • Create<\/li>\n\n\n\n
                                                                                                                                                                                      • Update<\/li>\n\n\n\n
                                                                                                                                                                                      • Delete<\/li>\n\n\n\n
                                                                                                                                                                                      • List hooks<\/li>\n\n\n\n
                                                                                                                                                                                      • Inspect deliveries<\/li>\n\n\n\n
                                                                                                                                                                                      • Redeliver supported deliveries<\/li>\n<\/ul>\n\n\n\n
                                                                                                                                                                                        Automating webhooks is useful when every service repository must integrate with the same platform system.<\/p>\n\n\n\n
                                                                                                                                                                                        \n\n\n\n
                                                                                                                                                                                        107. AI Scan API<\/h2>\n\n\n\n
                                                                                                                                                                                        As of September 2026, GitHub has public-preview REST endpoints to inspect and update AI Scan enablement at organization and repository scope.<\/p>\n\n\n\n
                                                                                                                                                                                        Example read path documented by GitHub:<\/p>\n\n\n\n
                                                                                                                                                                                        \/repos\/{owner}\/{repo}\/code-scanning\/ai-scan\n<\/code><\/pre>\n\n\n\n
                                                                                                                                                                                        Because this endpoint is preview functionality, verify the current API contract immediately before production automation.<\/p>\n\n\n\n
                                                                                                                                                                                        \n\n\n\n
                                                                                                                                                                                        108. GitHub CLI Administration<\/h2>\n\n\n\n
                                                                                                                                                                                        Useful command families include:<\/p>\n\n\n\n
                                                                                                                                                                                        gh repo view\ngh repo edit\ngh repo archive\ngh repo delete\ngh secret list\ngh secret set\ngh variable list\ngh variable set\ngh api\n<\/code><\/pre>\n\n\n\n
                                                                                                                                                                                        Example repository edit<\/h3>\n\n\n\n
                                                                                                                                                                                        gh repo edit \"$OWNER\/$REPO\" --delete-branch-on-merge\n<\/code><\/pre>\n\n\n\n
                                                                                                                                                                                        Use gh api<\/code> when a setting is not exposed by a first-class CLI subcommand.<\/p>\n\n\n\n
                                                                                                                                                                                        \n\n\n\n
                                                                                                                                                                                        109. GraphQL Administration<\/h2>\n\n\n\n
                                                                                                                                                                                        GitHub GraphQL is useful for querying connected repository metadata in fewer round trips.<\/p>\n\n\n\n
                                                                                                                                                                                        Typical uses:<\/p>\n\n\n\n
                                                                                                                                                                                          \n
                                                                                                                                                                                        • Repository inventory<\/li>\n\n\n\n
                                                                                                                                                                                        • Branch protection data<\/li>\n\n\n\n
                                                                                                                                                                                        • Collaborator\/permission relationships<\/li>\n\n\n\n
                                                                                                                                                                                        • Deployments<\/li>\n\n\n\n
                                                                                                                                                                                        • Projects<\/li>\n\n\n\n
                                                                                                                                                                                        • Security-related reporting where fields are exposed<\/li>\n<\/ul>\n\n\n\n
                                                                                                                                                                                          GraphQL and REST do not have identical feature coverage. Choose the API that exposes the capability cleanly rather than forcing all automation into one style.<\/p>\n\n\n\n
                                                                                                                                                                                          \n\n\n\n
                                                                                                                                                                                          Part XVII \u2014 Infrastructure as Code<\/h1>\n\n\n\n
                                                                                                                                                                                          110. Terraform GitHub Provider<\/h2>\n\n\n\n
                                                                                                                                                                                          The official community-supported integrations\/github<\/code> Terraform provider can manage many repository controls.<\/p>\n\n\n\n
                                                                                                                                                                                          As of September 2026, Terraform Registry shows provider version 6.13.0<\/strong> as the latest published version in the retrieved provider index. Always verify the current version before pinning.<\/p>\n\n\n\n
                                                                                                                                                                                          Common resources include:<\/p>\n\n\n\n
                                                                                                                                                                                          github_repository\ngithub_branch_default\ngithub_repository_ruleset\ngithub_team_repository\ngithub_repository_collaborator\ngithub_repository_collaborators\ngithub_actions_repository_permissions\ngithub_actions_secret\ngithub_actions_variable\ngithub_repository_environment\ngithub_repository_environment_deployment_policy\ngithub_actions_environment_secret\ngithub_actions_environment_variable\ngithub_dependabot_secret\ngithub_repository_webhook\ngithub_repository_deploy_key\ngithub_repository_pages\n<\/code><\/pre>\n\n\n\n
                                                                                                                                                                                          \n\n\n\n
                                                                                                                                                                                          111. Terraform Repository Example<\/h2>\n\n\n\n
                                                                                                                                                                                          terraform {\n  required_providers {\n    github = {\n      source  = \"integrations\/github\"\n      version = \"~> 6.13\"\n    }\n  }\n}\n\nprovider \"github\" {\n  owner = var.github_owner\n}\n\nresource \"github_repository\" \"app\" {\n  name                   = \"payment-api\"\n  description            = \"Payment service API\"\n  visibility             = \"private\"\n  has_issues             = true\n  has_wiki               = false\n  delete_branch_on_merge = true\n\n  allow_merge_commit = false\n  allow_squash_merge = true\n  allow_rebase_merge = false\n}\n<\/code><\/pre>\n\n\n\n
                                                                                                                                                                                          Pin a provider range intentionally and review provider release notes before major upgrades.<\/p>\n\n\n\n
                                                                                                                                                                                          \n\n\n\n
                                                                                                                                                                                          112. Terraform Actions Permissions<\/h2>\n\n\n\n
                                                                                                                                                                                          resource \"github_actions_repository_permissions\" \"app\" {\n  repository      = github_repository.app.name\n  enabled         = true\n  allowed_actions = \"selected\"\n\n  allowed_actions_config {\n    github_owned_allowed = true\n    verified_allowed     = false\n    patterns_allowed = [\n      \"actions\/checkout@*\",\n      \"actions\/cache@*\",\n    ]\n  }\n}\n<\/code><\/pre>\n\n\n\n
                                                                                                                                                                                          For high-assurance supply-chain policy, consider whether your organization should require SHA pinning instead of broad tag patterns.<\/p>\n\n\n\n
                                                                                                                                                                                          \n\n\n\n
                                                                                                                                                                                          113. Terraform Ruleset Example<\/h2>\n\n\n\n
                                                                                                                                                                                          resource \"github_repository_ruleset\" \"main\" {\n  name        = \"protect-main\"\n  repository  = github_repository.app.name\n  target      = \"branch\"\n  enforcement = \"active\"\n\n  conditions {\n    ref_name {\n      include = [\"~DEFAULT_BRANCH\"]\n      exclude = []\n    }\n  }\n\n  rules {\n    deletion                = true\n    non_fast_forward        = true\n    required_linear_history = true\n\n    pull_request {\n      required_approving_review_count = 1\n      require_code_owner_review       = true\n      required_review_thread_resolution = true\n    }\n  }\n}\n<\/code><\/pre>\n\n\n\n
                                                                                                                                                                                          Provider schemas evolve. Validate nested rule names against the pinned provider version before applying production configuration.<\/p>\n\n\n\n
                                                                                                                                                                                          \n\n\n\n
                                                                                                                                                                                          114. Terraform Environment Example<\/h2>\n\n\n\n
                                                                                                                                                                                          resource \"github_repository_environment\" \"production\" {\n  repository  = github_repository.app.name\n  environment = \"production\"\n\n  prevent_self_review = true\n\n  deployment_branch_policy {\n    protected_branches     = false\n    custom_branch_policies = true\n  }\n}\n\nresource \"github_repository_environment_deployment_policy\" \"main\" {\n  repository     = github_repository.app.name\n  environment    = github_repository_environment.production.environment\n  branch_pattern = \"main\"\n}\n<\/code><\/pre>\n\n\n\n
                                                                                                                                                                                          \n\n\n\n
                                                                                                                                                                                          115. Terraform Secret Warning<\/h2>\n\n\n\n
                                                                                                                                                                                          Terraform can manage GitHub secrets, but secret values can still become sensitive Terraform state data depending on how they are provided.<\/p>\n\n\n\n
                                                                                                                                                                                          Treat state as a secret-bearing system.<\/p>\n\n\n\n
                                                                                                                                                                                          Recommended<\/strong><\/p>\n\n\n\n
                                                                                                                                                                                            \n
                                                                                                                                                                                          • Encrypted remote state<\/li>\n\n\n\n
                                                                                                                                                                                          • Strict state access<\/li>\n\n\n\n
                                                                                                                                                                                          • Avoid plaintext secrets in\u00a0.tf<\/code>\u00a0files<\/li>\n\n\n\n
                                                                                                                                                                                          • Prefer external secret injection or encrypted values where practical<\/li>\n\n\n\n
                                                                                                                                                                                          • Rotate credentials if state exposure occurs<\/li>\n<\/ul>\n\n\n\n
                                                                                                                                                                                            \n\n\n\n
                                                                                                                                                                                            116. Repository as Code<\/h2>\n\n\n\n
                                                                                                                                                                                            A mature organization can standardize repository provisioning:<\/p>\n\n\n\n
                                                                                                                                                                                            Repository request\n      \u2193\nApproved metadata\n      \u2193\nTerraform module\n      \u2193\nRepository + teams\n      \u2193\nRulesets\n      \u2193\nActions policy\n      \u2193\nEnvironments\n      \u2193\nSecurity configuration\n      \u2193\nContinuous drift check\n<\/code><\/pre>\n\n\n\n
                                                                                                                                                                                            What belongs in desired state<\/h3>\n\n\n\n
                                                                                                                                                                                              \n
                                                                                                                                                                                            • Name\/description\/visibility<\/li>\n\n\n\n
                                                                                                                                                                                            • Topics\/custom properties<\/li>\n\n\n\n
                                                                                                                                                                                            • Teams and permissions<\/li>\n\n\n\n
                                                                                                                                                                                            • Rulesets<\/li>\n\n\n\n
                                                                                                                                                                                            • Actions policy<\/li>\n\n\n\n
                                                                                                                                                                                            • Environments<\/li>\n\n\n\n
                                                                                                                                                                                            • Webhooks<\/li>\n\n\n\n
                                                                                                                                                                                            • Pages when applicable<\/li>\n\n\n\n
                                                                                                                                                                                            • Security configuration where provider\/API coverage exists<\/li>\n<\/ul>\n\n\n\n
                                                                                                                                                                                              Not every GitHub feature has immediate Terraform-provider parity. Use APIs only where needed and track the gap explicitly.<\/p>\n\n\n\n
                                                                                                                                                                                              Part XVIII \u2014 Repository Standardization<\/h1>\n\n\n\n
                                                                                                                                                                                              117. Repository Templates and Standard Structure<\/h2>\n\n\n\n
                                                                                                                                                                                              A standardized repository should make common expectations obvious before a developer reads internal documentation.<\/p>\n\n\n\n
                                                                                                                                                                                              Example:<\/p>\n\n\n\n
                                                                                                                                                                                              .github\/\n  CODEOWNERS\n  ISSUE_TEMPLATE\/\n  workflows\/\n  copilot-instructions.md\nCODE_OF_CONDUCT.md\nCONTRIBUTING.md\nLICENSE\nREADME.md\nSECURITY.md\nsrc\/\ntests\/\n<\/code><\/pre>\n\n\n\n
                                                                                                                                                                                              Not every repository needs every file. Use the minimum set that supports the repository’s users and risk profile.<\/p>\n\n\n\n
                                                                                                                                                                                              Recommended baseline files<\/h3>\n\n\n\n
                                                                                                                                                                                              File<\/th>Purpose<\/th><\/tr><\/thead>
                                                                                                                                                                                              README.md<\/code><\/td>What the repository is and how to use it<\/td><\/tr>
                                                                                                                                                                                              CONTRIBUTING.md<\/code><\/td>Contribution workflow<\/td><\/tr>
                                                                                                                                                                                              SECURITY.md<\/code><\/td>Vulnerability reporting policy<\/td><\/tr>
                                                                                                                                                                                              CODEOWNERS<\/code><\/td>Review ownership for sensitive paths<\/td><\/tr>
                                                                                                                                                                                              LICENSE<\/code><\/td>Reuse\/legal terms where appropriate<\/td><\/tr>
                                                                                                                                                                                              .github\/ISSUE_TEMPLATE\/*<\/code><\/td>Structured issue intake<\/td><\/tr>
                                                                                                                                                                                              .github\/workflows\/*<\/code><\/td>CI\/CD automation<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                                                                                                                                                                                              \n\n\n\n
                                                                                                                                                                                              118. CODEOWNERS<\/h2>\n\n\n\n
                                                                                                                                                                                              CODEOWNERS<\/code> maps file paths to responsible reviewers.<\/p>\n\n\n\n
                                                                                                                                                                                              Example:<\/p>\n\n\n\n
                                                                                                                                                                                              # Default owners\n* @example\/platform\n\n# Security-sensitive workflows\n.github\/workflows\/ @example\/platform-security\n\n# Payments domain\nsrc\/payments\/ @example\/payments-team\n\n# Infrastructure\nterraform\/ @example\/cloud-platform\n<\/code><\/pre>\n\n\n\n
                                                                                                                                                                                              CODEOWNERS alone does not force a review. Pair it with a branch\/ruleset rule that requires code-owner review.<\/p>\n\n\n\n
                                                                                                                                                                                              \n\n\n\n
                                                                                                                                                                                              119. Repository Metadata Standards<\/h2>\n\n\n\n
                                                                                                                                                                                              A platform team should standardize metadata just as it standardizes CI.<\/p>\n\n\n\n
                                                                                                                                                                                              Example minimum:<\/p>\n\n\n\n
                                                                                                                                                                                              Metadata<\/th>Required?<\/th>Example<\/th><\/tr><\/thead>
                                                                                                                                                                                              Description<\/td>Yes<\/td>Customer profile API<\/code><\/td><\/tr>
                                                                                                                                                                                              Owner team<\/td>Yes<\/td>identity-platform<\/code><\/td><\/tr>
                                                                                                                                                                                              Service tier<\/td>Yes for services<\/td>tier-1<\/code><\/td><\/tr>
                                                                                                                                                                                              Data classification<\/td>Yes where relevant<\/td>confidential<\/code><\/td><\/tr>
                                                                                                                                                                                              Lifecycle<\/td>Yes<\/td>active<\/code><\/td><\/tr>
                                                                                                                                                                                              Documentation URL<\/td>Recommended<\/td>Internal docs URL<\/td><\/tr>
                                                                                                                                                                                              Topics<\/td>Recommended<\/td>go<\/code>, api<\/code>, production<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                                                                                                                                                                                              Custom properties are preferable to free-form README metadata when the information must drive automation.<\/p>\n\n\n\n
                                                                                                                                                                                              \n\n\n\n
                                                                                                                                                                                              120. Repository Protection Standard<\/h2>\n\n\n\n
                                                                                                                                                                                              Example baseline for a production service:<\/p>\n\n\n\n
                                                                                                                                                                                              Default branch protected by ruleset\nPull request required\n1-2 approvals based on risk\nCode owner review for sensitive paths\nRequired CI checks\nCode\/secret scanning gate where licensed\nForce push blocked\nDeletion restricted\nAuto-delete merged branches enabled\nProduction deployment through protected environment\n<\/code><\/pre>\n\n\n\n
                                                                                                                                                                                              Keep stronger profiles for critical repositories and lighter profiles for prototypes.<\/p>\n\n\n\n
                                                                                                                                                                                              \n\n\n\n
                                                                                                                                                                                              Part XIX \u2014 Repository Security Hardening<\/h1>\n\n\n\n
                                                                                                                                                                                              121. Least Privilege<\/h2>\n\n\n\n
                                                                                                                                                                                              Apply least privilege to every actor:<\/p>\n\n\n\n
                                                                                                                                                                                                \n
                                                                                                                                                                                              • Human users<\/li>\n\n\n\n
                                                                                                                                                                                              • Teams<\/li>\n\n\n\n
                                                                                                                                                                                              • GitHub Apps<\/li>\n\n\n\n
                                                                                                                                                                                              • GITHUB_TOKEN<\/code><\/li>\n\n\n\n
                                                                                                                                                                                              • Deploy keys<\/li>\n\n\n\n
                                                                                                                                                                                              • PATs<\/li>\n\n\n\n
                                                                                                                                                                                              • CI runners<\/li>\n\n\n\n
                                                                                                                                                                                              • Environment credentials<\/li>\n\n\n\n
                                                                                                                                                                                              • MCP\/agent tools<\/li>\n<\/ul>\n\n\n\n
                                                                                                                                                                                                Practical hierarchy<\/h3>\n\n\n\n
                                                                                                                                                                                                Read < Triage < Write < Maintain < Admin\n<\/code><\/pre>\n\n\n\n
                                                                                                                                                                                                Do not grant Admin simply because someone needs one administrative operation. Use custom roles or controlled workflows where available.<\/p>\n\n\n\n
                                                                                                                                                                                                \n\n\n\n
                                                                                                                                                                                                122. Credential Hardening<\/h2>\n\n\n\n
                                                                                                                                                                                                Recommended order for automation identity:<\/p>\n\n\n\n
                                                                                                                                                                                                  \n
                                                                                                                                                                                                1. OIDC federation for cloud credentials<\/li>\n\n\n\n
                                                                                                                                                                                                2. GitHub App installation token for GitHub automation<\/li>\n\n\n\n
                                                                                                                                                                                                3. Fine-grained PAT when a user identity is genuinely required<\/li>\n\n\n\n
                                                                                                                                                                                                4. Deploy key for narrow SSH repository access<\/li>\n\n\n\n
                                                                                                                                                                                                5. Classic PAT only when no better mechanism fits<\/li>\n<\/ol>\n\n\n\n
                                                                                                                                                                                                  Rotate these regularly<\/h3>\n\n\n\n
                                                                                                                                                                                                    \n
                                                                                                                                                                                                  • Deploy keys<\/li>\n\n\n\n
                                                                                                                                                                                                  • PATs<\/li>\n\n\n\n
                                                                                                                                                                                                  • Webhook secrets<\/li>\n\n\n\n
                                                                                                                                                                                                  • External registry credentials<\/li>\n\n\n\n
                                                                                                                                                                                                  • App private keys<\/li>\n\n\n\n
                                                                                                                                                                                                  • Long-lived repository\/environment secrets<\/li>\n<\/ul>\n\n\n\n
                                                                                                                                                                                                    \n\n\n\n
                                                                                                                                                                                                    123. Supply-Chain Security<\/h2>\n\n\n\n
                                                                                                                                                                                                    A strong repository baseline combines:<\/p>\n\n\n\n
                                                                                                                                                                                                      \n
                                                                                                                                                                                                    • Dependency graph<\/li>\n\n\n\n
                                                                                                                                                                                                    • Dependabot alerts<\/li>\n\n\n\n
                                                                                                                                                                                                    • Dependabot security updates<\/li>\n\n\n\n
                                                                                                                                                                                                    • Dependency review<\/li>\n\n\n\n
                                                                                                                                                                                                    • Code scanning<\/li>\n\n\n\n
                                                                                                                                                                                                    • Secret scanning<\/li>\n\n\n\n
                                                                                                                                                                                                    • Push protection<\/li>\n\n\n\n
                                                                                                                                                                                                    • Release immutability<\/li>\n\n\n\n
                                                                                                                                                                                                    • Artifact attestations where relevant<\/li>\n\n\n\n
                                                                                                                                                                                                    • SHA-pinned third-party Actions for high-assurance workflows<\/li>\n<\/ul>\n\n\n\n
                                                                                                                                                                                                      Threat flow<\/h3>\n\n\n\n
                                                                                                                                                                                                      flowchart LR\n    D[Dependency] --> B[Build]\n    A[Action] --> B\n    C[Source Code] --> B\n    B --> X[Artifact]\n    X --> R[Release]\n    R --> P[Production]\n<\/code><\/pre>\n\n\n\n
                                                                                                                                                                                                      A compromise at any upstream point can reach production. Repository settings should therefore protect both source and automation.<\/p>\n\n\n\n
                                                                                                                                                                                                      \n\n\n\n
                                                                                                                                                                                                      124. Workflow File Protection<\/h2>\n\n\n\n
                                                                                                                                                                                                      Workflow files are privileged code because they can access tokens, runners, OIDC, secrets, and deployment environments.<\/p>\n\n\n\n
                                                                                                                                                                                                      Protect:<\/p>\n\n\n\n
                                                                                                                                                                                                      .github\/workflows\/**\n<\/code><\/pre>\n\n\n\n
                                                                                                                                                                                                      with:<\/p>\n\n\n\n
                                                                                                                                                                                                        \n
                                                                                                                                                                                                      • CODEOWNERS<\/li>\n\n\n\n
                                                                                                                                                                                                      • Required code-owner review<\/li>\n\n\n\n
                                                                                                                                                                                                      • Rulesets<\/li>\n\n\n\n
                                                                                                                                                                                                      • Minimal Actions permissions<\/li>\n\n\n\n
                                                                                                                                                                                                      • Controlled reusable workflows<\/li>\n<\/ul>\n\n\n\n
                                                                                                                                                                                                        \n\n\n\n
                                                                                                                                                                                                        125. Self-Hosted Runner Hardening<\/h2>\n\n\n\n
                                                                                                                                                                                                        If self-hosted runners are used:<\/p>\n\n\n\n
                                                                                                                                                                                                          \n
                                                                                                                                                                                                        • Keep runner scope as narrow as practical.<\/li>\n\n\n\n
                                                                                                                                                                                                        • Prefer ephemeral runners.<\/li>\n\n\n\n
                                                                                                                                                                                                        • Separate trusted and untrusted workloads.<\/li>\n\n\n\n
                                                                                                                                                                                                        • Restrict network paths.<\/li>\n\n\n\n
                                                                                                                                                                                                        • Patch the host image frequently.<\/li>\n\n\n\n
                                                                                                                                                                                                        • Do not persist cloud credentials.<\/li>\n\n\n\n
                                                                                                                                                                                                        • Destroy workspaces after jobs.<\/li>\n\n\n\n
                                                                                                                                                                                                        • Monitor runner registration and usage.<\/li>\n<\/ul>\n\n\n\n
                                                                                                                                                                                                          Public-repository pull requests and long-lived privileged runners are a particularly risky combination.<\/p>\n\n\n\n
                                                                                                                                                                                                          \n\n\n\n
                                                                                                                                                                                                          Part XX \u2014 Repository Lifecycle<\/h1>\n\n\n\n
                                                                                                                                                                                                          126. Creation Phase<\/h2>\n\n\n\n
                                                                                                                                                                                                          A new repository should not spend weeks in an insecure default state.<\/p>\n\n\n\n
                                                                                                                                                                                                          Creation checklist<\/h3>\n\n\n\n
                                                                                                                                                                                                          [ ] Correct owner and visibility\n[ ] Description and metadata\n[ ] Owner team\n[ ] Default branch\n[ ] Merge strategy\n[ ] Ruleset\/protection\n[ ] Actions policy\n[ ] Security configuration\n[ ] CODEOWNERS\n[ ] CI workflow\n[ ] Environment controls\n[ ] Dependabot configuration\n[ ] Documentation\n<\/code><\/pre>\n\n\n\n
                                                                                                                                                                                                          Automate this baseline with templates\/IaC where possible.<\/p>\n\n\n\n
                                                                                                                                                                                                          \n\n\n\n
                                                                                                                                                                                                          127. Active Operations Phase<\/h2>\n\n\n\n
                                                                                                                                                                                                          Regular repository operations should include:<\/p>\n\n\n\n
                                                                                                                                                                                                            \n
                                                                                                                                                                                                          • Access review<\/li>\n\n\n\n
                                                                                                                                                                                                          • Ruleset review<\/li>\n\n\n\n
                                                                                                                                                                                                          • CI health review<\/li>\n\n\n\n
                                                                                                                                                                                                          • Runner review<\/li>\n\n\n\n
                                                                                                                                                                                                          • Dependency maintenance<\/li>\n\n\n\n
                                                                                                                                                                                                          • Security alert triage<\/li>\n\n\n\n
                                                                                                                                                                                                          • Secret rotation<\/li>\n\n\n\n
                                                                                                                                                                                                          • App\/integration review<\/li>\n\n\n\n
                                                                                                                                                                                                          • Environment reviewer review<\/li>\n\n\n\n
                                                                                                                                                                                                          • Metadata ownership validation<\/li>\n<\/ul>\n\n\n\n
                                                                                                                                                                                                            \n\n\n\n
                                                                                                                                                                                                            128. Deprecation Phase<\/h2>\n\n\n\n
                                                                                                                                                                                                            A repository that is no longer strategic should move through a controlled deprecation stage rather than disappearing suddenly.<\/p>\n\n\n\n
                                                                                                                                                                                                            Recommended:<\/p>\n\n\n\n
                                                                                                                                                                                                              \n
                                                                                                                                                                                                            1. Add a deprecation notice.<\/li>\n\n\n\n
                                                                                                                                                                                                            2. Name the replacement repository\/service.<\/li>\n\n\n\n
                                                                                                                                                                                                            3. Stop feature development.<\/li>\n\n\n\n
                                                                                                                                                                                                            4. Migrate consumers.<\/li>\n\n\n\n
                                                                                                                                                                                                            5. Retire deployment automation.<\/li>\n\n\n\n
                                                                                                                                                                                                            6. Revoke unused credentials.<\/li>\n\n\n\n
                                                                                                                                                                                                            7. Close remaining issues\/PRs.<\/li>\n\n\n\n
                                                                                                                                                                                                            8. Archive when dependencies are gone.<\/li>\n<\/ol>\n\n\n\n
                                                                                                                                                                                                              \n\n\n\n
                                                                                                                                                                                                              129. Archival Phase<\/h2>\n\n\n\n
                                                                                                                                                                                                              When archiving:<\/p>\n\n\n\n
                                                                                                                                                                                                                \n
                                                                                                                                                                                                              • Record the owning team.<\/li>\n\n\n\n
                                                                                                                                                                                                              • Record the replacement\/successor.<\/li>\n\n\n\n
                                                                                                                                                                                                              • Keep a useful README.<\/li>\n\n\n\n
                                                                                                                                                                                                              • Verify package\/deployment dependencies.<\/li>\n\n\n\n
                                                                                                                                                                                                              • Preserve compliance evidence externally if required.<\/li>\n\n\n\n
                                                                                                                                                                                                              • Review whether security scanning on the archived code is required.<\/li>\n<\/ul>\n\n\n\n
                                                                                                                                                                                                                \n\n\n\n
                                                                                                                                                                                                                130. Deletion Phase<\/h2>\n\n\n\n
                                                                                                                                                                                                                Deletion should be exceptional for business repositories.<\/p>\n\n\n\n
                                                                                                                                                                                                                Use approval and evidence:<\/p>\n\n\n\n
                                                                                                                                                                                                                Owner approval\nSecurity\/compliance check\nDependency check\nBackup\/export decision\nCredential revocation\nDeletion\nPost-delete verification\n<\/code><\/pre>\n\n\n\n
                                                                                                                                                                                                                \n\n\n\n
                                                                                                                                                                                                                Part XXI \u2014 Troubleshooting Guide<\/h1>\n\n\n\n
                                                                                                                                                                                                                131. Access Troubleshooting<\/h2>\n\n\n\n
                                                                                                                                                                                                                Problem<\/th>Likely cause<\/th>Diagnose<\/th>Solution<\/th><\/tr><\/thead>
                                                                                                                                                                                                                User cannot clone private repo<\/td>No effective Read access<\/td>Check direct, team, base access<\/td>Add appropriate team\/role<\/td><\/tr>
                                                                                                                                                                                                                User has more access than expected<\/td>Multiple access paths<\/td>Review teams and base permissions<\/td>Remove excess path<\/td><\/tr>
                                                                                                                                                                                                                Cannot add outside collaborator<\/td>Org\/enterprise policy<\/td>Check organization policy<\/td>Use approved invitation path<\/td><\/tr>
                                                                                                                                                                                                                User cannot change setting<\/td>Higher-level enforcement<\/td>Check org\/enterprise policy<\/td>Change policy at owning layer<\/td><\/tr>
                                                                                                                                                                                                                Collaborator invitation pending<\/td>Not accepted \/ identity policy<\/td>Check access page<\/td>Reinvite or satisfy identity requirement<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                                                                                                                                                                                                                Debug principle<\/h3>\n\n\n\n
                                                                                                                                                                                                                Do not ask only \u201cwhat role does the user have?\u201d Ask:<\/p>\n\n\n\n
                                                                                                                                                                                                                What are all paths that grant this user access?\n<\/code><\/pre>\n\n\n\n
                                                                                                                                                                                                                \n\n\n\n
                                                                                                                                                                                                                132. Ruleset Troubleshooting<\/h2>\n\n\n\n
                                                                                                                                                                                                                Problem<\/th>Likely cause<\/th>Diagnose<\/th>Solution<\/th><\/tr><\/thead>
                                                                                                                                                                                                                Push blocked unexpectedly<\/td>Branch\/tag\/push ruleset<\/td>Open repository rules \/ rule insights<\/td>Identify matching rule<\/td><\/tr>
                                                                                                                                                                                                                Merge blocked<\/td>Required review\/check\/deployment<\/td>Check PR merge box<\/td>Complete missing condition<\/td><\/tr>
                                                                                                                                                                                                                Required check missing<\/td>Job renamed or workflow not triggered<\/td>Inspect Actions run and ruleset check name<\/td>Restore check or update rule<\/td><\/tr>
                                                                                                                                                                                                                Admin cannot bypass<\/td>No bypass or rule applies to admins<\/td>Inspect bypass list<\/td>Add approved bypass actor<\/td><\/tr>
                                                                                                                                                                                                                Fork push blocked<\/td>Root push ruleset<\/td>Inspect source repository rules<\/td>Change root policy if justified<\/td><\/tr>
                                                                                                                                                                                                                Conversion behaves differently<\/td>Legacy rule not 1:1 mapped<\/td>Compare branch protection and ruleset<\/td>Tune converted ruleset<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                                                                                                                                                                                                                Rule debugging order<\/h3>\n\n\n\n
                                                                                                                                                                                                                1. Which ref is targeted?\n2. Which rulesets match?\n3. Is legacy branch protection also active?\n4. Which rule is most restrictive?\n5. Is an organization ruleset layered on top?\n6. Is bypass actually granted to this actor?\n<\/code><\/pre>\n\n\n\n
                                                                                                                                                                                                                \n\n\n\n
                                                                                                                                                                                                                133. Actions Settings Troubleshooting<\/h2>\n\n\n\n
                                                                                                                                                                                                                Problem<\/th>Likely cause<\/th>Diagnose<\/th>Solution<\/th><\/tr><\/thead>
                                                                                                                                                                                                                Workflow never starts<\/td>Actions disabled<\/td>Settings \u2192 Actions<\/td>Enable if policy permits<\/td><\/tr>
                                                                                                                                                                                                                Action denied<\/td>Allowlist policy<\/td>Check failure message and Actions policy<\/td>Allow approved action<\/td><\/tr>
                                                                                                                                                                                                                GITHUB_TOKEN<\/code> permission denied<\/td>Token too restricted<\/td>Inspect workflow permissions<\/code><\/td>Grant minimal required scope<\/td><\/tr>
                                                                                                                                                                                                                Reusable workflow inaccessible<\/td>Private workflow access not granted<\/td>Check source repo Actions access<\/td>Grant org\/repo access<\/td><\/tr>
                                                                                                                                                                                                                Cache constantly evicted<\/td>Cache limit too small<\/td>Inspect cache usage<\/td>Increase limit or improve keys<\/td><\/tr>
                                                                                                                                                                                                                Runner offline<\/td>Host\/registration\/network failure<\/td>Runner settings and host logs<\/td>Restore or re-register runner<\/td><\/tr>
                                                                                                                                                                                                                Secret empty<\/td>Event or scope restriction<\/td>Check event and secret scope<\/td>Use correct environment\/repo secret<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                                                                                                                                                                                                                Example permissions failure<\/h3>\n\n\n\n
                                                                                                                                                                                                                If a workflow tries to create a release with:<\/p>\n\n\n\n
                                                                                                                                                                                                                permissions:\n  contents: read\n<\/code><\/pre>\n\n\n\n
                                                                                                                                                                                                                it will not have the required write capability. Grant only the needed permission:<\/p>\n\n\n\n
                                                                                                                                                                                                                permissions:\n  contents: write\n<\/code><\/pre>\n\n\n\n
                                                                                                                                                                                                                \n\n\n\n
                                                                                                                                                                                                                134. Environment Troubleshooting<\/h2>\n\n\n\n
                                                                                                                                                                                                                Problem<\/th>Likely cause<\/th>Diagnose<\/th>Solution<\/th><\/tr><\/thead>
                                                                                                                                                                                                                Deployment waits indefinitely<\/td>Required reviewer<\/td>Open deployment review UI<\/td>Approve with eligible reviewer<\/td><\/tr>
                                                                                                                                                                                                                Initiator cannot approve<\/td>Prevent self-review enabled<\/td>Check environment protection<\/td>Use another reviewer<\/td><\/tr>
                                                                                                                                                                                                                Branch cannot deploy<\/td>Branch\/tag restriction<\/td>Compare ref with environment rule<\/td>Update ref or approved policy<\/td><\/tr>
                                                                                                                                                                                                                Secret not available<\/td>Job not using environment<\/td>Inspect workflow job<\/td>Add environment:<\/code><\/td><\/tr>
                                                                                                                                                                                                                Protection App blocks deployment<\/td>External gate failed<\/td>Inspect protection rule response<\/td>Fix external condition<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                                                                                                                                                                                                                \n\n\n\n
                                                                                                                                                                                                                135. Advanced Security Troubleshooting<\/h2>\n\n\n\n
                                                                                                                                                                                                                Problem<\/th>Likely cause<\/th>Diagnose<\/th>Solution<\/th><\/tr><\/thead>
                                                                                                                                                                                                                Code scanning option unavailable<\/td>Visibility\/license\/product issue<\/td>Check plan and security configuration<\/td>Enable required product<\/td><\/tr>
                                                                                                                                                                                                                Default setup cannot enable<\/td>Actions disabled or unsupported repo<\/td>Check prerequisites<\/td>Enable Actions \/ use eligible repository<\/td><\/tr>
                                                                                                                                                                                                                Secret scanning missing<\/td>Product\/policy not enabled<\/td>Check Advanced Security config<\/td>Enable Secret Protection\/eligible feature<\/td><\/tr>
                                                                                                                                                                                                                Dependabot alerts absent<\/td>Dependency graph unavailable\/disabled<\/td>Check dependency graph<\/td>Enable and commit supported manifests<\/td><\/tr>
                                                                                                                                                                                                                AI Scan not available<\/td>Preview eligibility\/licensing<\/td>Check GHAS\/Copilot\/policy<\/td>Enable only if eligible<\/td><\/tr>
                                                                                                                                                                                                                Code Quality unavailable<\/td>Plan\/enterprise policy<\/td>Check entitlement and policy<\/td>Enable where supported<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                                                                                                                                                                                                                \n\n\n\n
                                                                                                                                                                                                                136. Pages Troubleshooting<\/h2>\n\n\n\n
                                                                                                                                                                                                                Problem<\/th>Likely cause<\/th>Diagnose<\/th>Solution<\/th><\/tr><\/thead>
                                                                                                                                                                                                                Site not publishing<\/td>Wrong source<\/td>Pages settings \/ Actions<\/td>Correct branch or workflow<\/td><\/tr>
                                                                                                                                                                                                                404<\/td>Missing index or wrong path<\/td>Inspect published artifact<\/td>Add valid site root<\/td><\/tr>
                                                                                                                                                                                                                Custom domain fails<\/td>DNS wrong<\/td>DNS lookup + Pages settings<\/td>Correct record<\/td><\/tr>
                                                                                                                                                                                                                HTTPS unavailable<\/td>DNS\/CAA\/certificate issue<\/td>Check domain and certificate state<\/td>Fix DNS\/CAA and retry<\/td><\/tr>
                                                                                                                                                                                                                Old domain points to deleted site<\/td>Stale DNS<\/td>DNS audit<\/td>Remove\/update record immediately<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                                                                                                                                                                                                                \n\n\n\n
                                                                                                                                                                                                                137. Webhook Troubleshooting<\/h2>\n\n\n\n
                                                                                                                                                                                                                Symptom<\/th>Likely cause<\/th>What to inspect<\/th><\/tr><\/thead>
                                                                                                                                                                                                                401\/403<\/td>Signature\/auth failure<\/td>Secret and signature verification<\/td><\/tr>
                                                                                                                                                                                                                404<\/td>Wrong endpoint<\/td>Payload URL<\/td><\/tr>
                                                                                                                                                                                                                5xx<\/td>Receiver application error<\/td>Server logs<\/td><\/tr>
                                                                                                                                                                                                                Timeout<\/td>Receiver slow\/unreachable<\/td>Network and processing time<\/td><\/tr>
                                                                                                                                                                                                                Duplicate processing<\/td>Redelivery\/retry\/idempotency issue<\/td>Delivery ID and idempotency key<\/td><\/tr>
                                                                                                                                                                                                                Missing event<\/td>Event not subscribed<\/td>Webhook event settings<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                                                                                                                                                                                                                \n\n\n\n
                                                                                                                                                                                                                Part XXII \u2014 Best Practices<\/h1>\n\n\n\n
                                                                                                                                                                                                                138. Access Best Practices<\/h2>\n\n\n\n
                                                                                                                                                                                                                Recommended<\/strong><\/p>\n\n\n\n