{"id":78752,"date":"2026-09-26T07:16:33","date_gmt":"2026-09-26T07:16:33","guid":{"rendered":"https:\/\/www.devopsschool.com\/blog\/?p=78752"},"modified":"2026-09-26T07:16:37","modified_gmt":"2026-09-26T07:16:37","slug":"github-repository-settings-essentials-2-hour-tutorial","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/blog\/github-repository-settings-essentials-2-hour-tutorial\/","title":{"rendered":"GitHub Repository Settings Essentials \u2014 2-Hour Tutorial"},"content":{"rendered":"\n
\n

Last Verified:<\/strong> September 2026
Based on:<\/strong> GitHub Repository Settings \u2014 Complete Reference Guide & Tutorial<\/em>
Duration:<\/strong> 2 hours
Platform:<\/strong> GitHub.com \/ GitHub Enterprise Cloud unless stated otherwise
Audience:<\/strong> Developers, DevOps\/platform engineers, repository administrators, security engineers, team leads, and technical trainers.<\/p>\n<\/blockquote>\n\n\n\n

This is the Essentials<\/strong> version of the complete GitHub Repository Settings guide. It intentionally removes deep API automation, Terraform, Pages, Copilot\/MCP administration, Code Quality deep-dives, advanced governance, and rarely used settings so a learner can understand and practice the repository controls that matter most in normal engineering work in about two hours<\/strong>.<\/p>\n\n\n\n

The goal is not to memorize every item in the Settings<\/strong> sidebar. The goal is to understand the repository control path:<\/p>\n\n\n

General behavior -> Access -> Change protection -> CI\/CD authority\n                 -> Deployment protection -> Security -> Lifecycle safety\n<\/code><\/span><\/pre>\n\n
flowchart<\/span> LR<\/span>\n    G<\/span>[General]<\/span> --<\/span>> A<\/span>[Access]<\/span>\n    A<\/span> --<\/span>> R<\/span>[Rulesets]<\/span>\n    R<\/span> --<\/span>> C<\/span>[Actions]<\/span>\n    C<\/span> --<\/span>> E<\/span>[Environments]<\/span>\n    E<\/span> --<\/span>> S<\/span>[Security]<\/span>\n    S<\/span> --<\/span>> L<\/span>[Lifecycle]<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
By the end of this tutorial, a learner should be able to configure a normal repository safely, explain why a pull request is blocked, understand what authority a workflow has, protect production deployments, and recognize high-risk repository changes.<\/p>\n\n\n\n
\n
Important:<\/strong> Exact settings depend on repository visibility, GitHub plan, enabled products, organization settings, and enterprise policy. A repository administrator cannot override a more restrictive organization or enterprise policy.<\/p>\n<\/blockquote>\n\n\n\n
\n\n\n\n
1. Two-Hour Learning Plan<\/h2>\n\n\n\n
Time<\/th>Module<\/th>Outcome<\/th><\/tr><\/thead>
0\u201310 min<\/td>Repository foundations<\/td>Understand settings hierarchy and repository roles<\/td><\/tr>
10\u201325 min<\/td>General settings<\/td>Configure default branch, features, and merge behavior<\/td><\/tr>
25\u201340 min<\/td>Access and permissions<\/td>Understand teams, direct access, roles, and access review<\/td><\/tr>
40\u201360 min<\/td>Rulesets and branches<\/td>Protect main<\/code> with PR, review, and CI requirements<\/td><\/tr>
60\u201380 min<\/td>GitHub Actions<\/td>Control workflow authority, trusted Actions, runners, and forks<\/td><\/tr>
80\u201395 min<\/td>Environments and secrets<\/td>Protect deployments and scope credentials correctly<\/td><\/tr>
95\u2013105 min<\/td>Security essentials<\/td>Understand dependencies, code scanning, secrets, and push protection<\/td><\/tr>
105\u2013115 min<\/td>Hands-on baseline lab<\/td>Apply the essentials to a training repository<\/td><\/tr>
115\u2013120 min<\/td>Review<\/td>Reinforce the operating model and troubleshooting sequence<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
What is intentionally outside this 2-hour scope?<\/h3>\n\n\n\n
Use the complete reference guide later for:<\/p>\n\n\n\n
    \n
  • Detailed moderation and interaction limits<\/li>\n\n\n\n
  • Advanced tag and push rules<\/li>\n\n\n\n
  • Release immutability deep-dive<\/li>\n\n\n\n
  • Actions retention and cache tuning<\/li>\n\n\n\n
  • Advanced self-hosted runner architecture<\/li>\n\n\n\n
  • Webhook implementation and signature verification<\/li>\n\n\n\n
  • Copilot instructions, coding agent, and MCP<\/li>\n\n\n\n
  • GitHub Pages<\/li>\n\n\n\n
  • Code Quality and AI Scan administration<\/li>\n\n\n\n
  • Detailed deploy-key operations<\/li>\n\n\n\n
  • Codespaces and Dependabot secret administration<\/li>\n\n\n\n
  • REST, GraphQL, and Terraform automation<\/li>\n\n\n\n
  • Enterprise-scale repository governance<\/li>\n<\/ul>\n\n\n\n
    These are important, but they are not prerequisites for day-to-day repository administration<\/strong>.<\/p>\n\n\n\n
    \n\n\n\n
    Module 1 \u2014 Repository Settings Foundations<\/h1>\n\n\n\n
    2. What Do Repository Settings Control?<\/h2>\n\n\n\n
    Repository settings are the control plane for one repository<\/strong>.<\/p>\n\n\n\n
    They decide:<\/p>\n\n\n\n
      \n
    • Who can access the repository<\/li>\n\n\n\n
    • Which branch is the default<\/li>\n\n\n\n
    • How pull requests may be merged<\/li>\n\n\n\n
    • Whether unsafe changes are blocked<\/li>\n\n\n\n
    • Which GitHub Actions workflows may run<\/li>\n\n\n\n
    • What permissions workflows receive<\/li>\n\n\n\n
    • How production deployment is protected<\/li>\n\n\n\n
    • Where secrets and variables are stored<\/li>\n\n\n\n
    • Which security features are enabled<\/li>\n\n\n\n
    • Whether the repository can be exposed, transferred, archived, or deleted<\/li>\n<\/ul>\n\n\n\n
      Think of two planes:<\/p>\n\n\n
      Development plane\n- Code\n- Issues\n- Pull requests\n- Releases\n- Workflows\n\nControl plane\n- Settings\n- Access\n- Rulesets\n- Actions policy\n- Environments\n- Security\n<\/code><\/span><\/pre>\n\n\n
      Developers spend most of their time in the development plane. Repository administrators must understand the control plane.<\/p>\n\n\n\n
      \n\n\n\n
      3. Repository Configuration Hierarchy<\/h2>\n\n\n\n
      A repository does not operate in isolation.<\/p>\n\n\n
      flowchart<\/span> TD<\/span>\n    E<\/span>[Enterprise policy]<\/span> --<\/span>> O<\/span>[Organization policy]<\/span>\n    O<\/span> --<\/span>> R<\/span>[Repository settings]<\/span>\n    R<\/span> --<\/span>> B<\/span>[Branch \/ tag rules]<\/span>\n    R<\/span> --<\/span>> A<\/span>[Actions settings]<\/span>\n    R<\/span> --<\/span>> V<\/span>[Environment protection]<\/span>\n    A<\/span> --<\/span>> W<\/span>[Workflow permissions]<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
      A useful precedence model is:<\/p>\n\n\n
      Enterprise policy\n        \u2193\nOrganization policy\n        \u2193\nRepository settings\n        \u2193\nEnvironment protection\n        \u2193\nWorkflow \/ job permissions\n<\/code><\/span><\/pre>\n\n\n
      For example, a repository cannot allow an Action that the organization has blocked.<\/p>\n\n\n\n
      Troubleshooting rule<\/h3>\n\n\n\n
      When a setting is disabled or cannot be made more permissive, ask:<\/p>\n\n\n\n
      \n
      Is this control owned by the repository, organization, or enterprise?<\/p>\n<\/blockquote>\n\n\n\n
      \n\n\n\n
      4. Repository Roles<\/h2>\n\n\n\n
      For organization repositories, the standard roles are:<\/p>\n\n\n\n
      Role<\/th>Typical use<\/th>Code write?<\/th>Administration<\/th><\/tr><\/thead>
      Read<\/td>Viewers, auditors<\/td>No<\/td>Minimal<\/td><\/tr>
      Triage<\/td>Issue\/PR coordinators<\/td>No<\/td>Issue\/PR management<\/td><\/tr>
      Write<\/td>Developers<\/td>Yes<\/td>Normal development<\/td><\/tr>
      Maintain<\/td>Repository maintainers<\/td>Yes<\/td>Many management operations<\/td><\/tr>
      Admin<\/td>Repository administrators<\/td>Yes<\/td>Full repository administration, subject to higher policy<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
      Use the lowest role that enables the job<\/strong>.<\/p>\n\n\n
      Developer        -> Write\nRepository lead  -> Maintain when sufficient\nRepo admin       -> Admin only when required\nAuditor          -> Read\nIssue coordinator -> Triage\n<\/code><\/span><\/pre>\n\n\n
      \n\n\n\n
      5. Training Repository Setup<\/h2>\n\n\n\n
      Use a disposable test repository, for example:<\/p>\n\n\n
      acme-engineering\/repository-settings-lab\n<\/code><\/span><\/pre>\n\n\n
      Recommended prerequisites:<\/p>\n\n\n\n
        \n
      • Admin access to the test repository<\/li>\n\n\n\n
      • GitHub CLI installed<\/li>\n\n\n\n
      • Git installed<\/li>\n\n\n\n
      • GitHub Actions enabled<\/li>\n\n\n\n
      • A simple CI workflow<\/li>\n<\/ul>\n\n\n\n
        Authenticate:<\/p>\n\n\n
        gh auth login\ngh auth status\n<\/code><\/span><\/pre>\n\n\n
        Set reusable variables:<\/p>\n\n\n
        export<\/span> OWNER=\"acme-engineering\"<\/span>\nexport<\/span> REPO=\"repository-settings-lab\"<\/span>\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
        Verify access:<\/p>\n\n\n
        gh repo view \"$OWNER\/$REPO\"<\/span>\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
        \n\n\n\n
        Module 2 \u2014 General Settings That Matter<\/h1>\n\n\n\n
        6. Repository Identity and Default Branch<\/h2>\n\n\n\n
        Repository identity includes the name, owner, description, website, topics, and visibility.<\/p>\n\n\n\n
        A rename can affect:<\/p>\n\n\n\n
          \n
        • Clone URLs<\/li>\n\n\n\n
        • CI\/CD references<\/li>\n\n\n\n
        • Documentation<\/li>\n\n\n\n
        • Badges<\/li>\n\n\n\n
        • Package configuration<\/li>\n\n\n\n
        • External integrations<\/li>\n<\/ul>\n\n\n\n
          GitHub commonly redirects old repository URLs, but integrations should be updated rather than relying on redirects indefinitely.<\/p>\n\n\n\n
          Update a local remote after a rename:<\/p>\n\n\n
          git remote set<\/span>-url origin git@github.com:acme\/payments-api.git\ngit remote -v\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
          Default branch<\/h3>\n\n\n\n
          The default branch\u2014commonly main<\/code>\u2014influences:<\/p>\n\n\n\n
            \n
          • New pull requests<\/li>\n\n\n\n
          • Repository landing view<\/li>\n\n\n\n
          • Branch comparisons<\/li>\n\n\n\n
          • Workflow assumptions<\/li>\n\n\n\n
          • Protection rules<\/li>\n\n\n\n
          • Deployment rules<\/li>\n<\/ul>\n\n\n\n
            A workflow may explicitly depend on it:<\/p>\n\n\n
            on<\/span>:\n  push<\/span>:\n    branches<\/span>: [main]<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
            Changing the default branch does not<\/strong> automatically rewrite every workflow or external integration.<\/p>\n\n\n\n
            \n\n\n\n
            7. Repository Features<\/h2>\n\n\n\n
            Common optional features include:<\/p>\n\n\n\n
            Feature<\/th>Use it for<\/th><\/tr><\/thead>
            Issues<\/td>Bugs, tasks, feature requests<\/td><\/tr>
            Discussions<\/td>Community or long-form discussion<\/td><\/tr>
            Projects<\/td>Planning connected to repository work<\/td><\/tr>
            Wiki<\/td>Repository documentation when a wiki model fits<\/td><\/tr>
            Actions<\/td>CI\/CD and automation<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
            Enable what the team actually uses.<\/p>\n\n\n\n
            Example internal microservice:<\/p>\n\n\n
            Issues<\/span>: Yes\nActions<\/span>: Yes\nProjects<\/span>: Only if planning happens in GitHub\nDiscussions<\/span>: Usually no\nWiki<\/span>: Usually no if docs live elsewhere\n<\/code><\/span>Code language:<\/span> HTTP<\/span> (<\/span>http<\/span>)<\/span><\/small><\/pre>\n\n\n
            \n\n\n\n
            8. Pull Request Merge Methods<\/h2>\n\n\n\n
            GitHub supports three common strategies:<\/p>\n\n\n\n
            Method<\/th>Result<\/th>Good fit<\/th><\/tr><\/thead>
            Merge commit<\/td>Keeps branch commits and adds merge commit<\/td>Full branch history<\/td><\/tr>
            Squash merge<\/td>One commit per PR<\/td>Clean application history<\/td><\/tr>
            Rebase merge<\/td>Replays commits onto base<\/td>Linear individual-commit history<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
            Simple decision model:<\/p>\n\n\n
            One commit per PR?           -> Squash\nKeep complete branch history? -> Merge commit\nLinear individual commits?    -> Rebase\n<\/code><\/span><\/pre>\n\n\n
            The right method depends on how the team uses Git history.<\/p>\n\n\n\n
            \n\n\n\n
            9. Auto-Merge and Branch Cleanup<\/h2>\n\n\n\n
            Auto-merge lets a pull request merge automatically after all required conditions pass.<\/p>\n\n\n
            flowchart LR\n    PR[Pull request] --> RV[Review]\n    RV --> CI[Required CI]\n    CI --> Q{All rules pass?}\n    Q -- No --> W[Wait]\n    Q -- Yes --> M[Merge]\n<\/code><\/span><\/pre>\n\n\n
            It works well when CI is reliable and protection rules are meaningful.<\/p>\n\n\n\n
            GitHub can also automatically delete the source branch after merge. This is useful for short-lived feature branches and keeps the repository clean.<\/p>\n\n\n\n
            Practical baseline<\/h3>\n\n\n
            Default<\/span> branch: main\nIssues: Enabled\nActions: Enabled\nSquash merge: Enabled\nAuto-merge: Optional, when team uses it\nDelete merged head branches: Enabled\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
            \n\n\n\n
            Module 3 \u2014 Access and Permissions<\/h1>\n\n\n\n
            10. Repository Access Model<\/h2>\n\n\n\n
            Access can come from multiple sources.<\/p>\n\n\n
            flowchart<\/span> TD<\/span>\n    T<\/span>[Team]<\/span> --<\/span>> E<\/span>[Effective access]<\/span>\n    D<\/span>[Direct collaborator]<\/span> --<\/span>> E<\/span>\n    O<\/span>[Organization \/ base access]<\/span> --<\/span>> E<\/span>\n    E<\/span> --<\/span>> P<\/span>[Repository protections still apply]<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
            Important distinction:<\/p>\n\n\n\n
            \n
            Permission determines what a user may attempt. Rules determine what changes GitHub will accept.<\/strong><\/p>\n<\/blockquote>\n\n\n\n
            A developer may have Write<\/code> access and still be blocked from pushing to main<\/code> because a ruleset requires pull requests.<\/p>\n\n\n\n
            \n\n\n\n
            11. Team Access vs Direct Access<\/h2>\n\n\n\n
            For organization repositories, prefer team-based access.<\/p>\n\n\n
            Alice ----+\nBob ------+--> payments-team --> payments repositories\nCarol ----+\n<\/code><\/span><\/pre>\n\n\n
            Benefits:<\/p>\n\n\n\n
              \n
            • Easier onboarding\/offboarding<\/li>\n\n\n\n
            • Easier access review<\/li>\n\n\n\n
            • Better ownership model<\/li>\n\n\n\n
            • Works well with CODEOWNERS<\/li>\n\n\n\n
            • Less permission drift<\/li>\n<\/ul>\n\n\n\n
              Direct access is reasonable for exceptional or temporary cases, such as a contractor who needs one repository for a limited period.<\/p>\n\n\n\n
              \n\n\n\n
              12. Mixed Roles and Access Review<\/h2>\n\n\n\n
              A user can receive access from multiple sources.<\/p>\n\n\n\n
              Example:<\/p>\n\n\n
              Alice\n  -> engineering team: Write\n  -> direct grant: Admin\n<\/code><\/span><\/pre>\n\n\n
              Her effective access is more powerful than the team role suggests.<\/p>\n\n\n\n
              Use Settings -> Collaborators and teams<\/strong> to inspect people, teams, roles, and mixed access.<\/p>\n\n\n\n
              A simple review table:<\/p>\n\n\n\n
              Actor<\/th>Source<\/th>Role<\/th>Needed?<\/th>Action<\/th><\/tr><\/thead>
              payments-team<\/code><\/td>Team<\/td>Write<\/td>Yes<\/td>Keep<\/td><\/tr>
              platform-team<\/code><\/td>Team<\/td>Maintain<\/td>Yes<\/td>Keep<\/td><\/tr>
              contractor-a<\/code><\/td>Direct<\/td>Write<\/td>No<\/td>Remove<\/td><\/tr>
              alice<\/code><\/td>Direct<\/td>Admin<\/td>Maybe not<\/td>Replace with team role<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
              Essential rule<\/h3>\n\n\n\n
              \n
              Repository access should be explainable in one minute.<\/p>\n<\/blockquote>\n\n\n\n
              \n\n\n\n
              Module 4 \u2014 Rulesets and Protected Branches<\/h1>\n\n\n\n
              13. Why Rulesets Matter<\/h2>\n\n\n\n
              Rulesets control how users interact with branches, tags, and\u2014on eligible plans\u2014pushes.<\/p>\n\n\n\n
              The most important use case is protecting the default branch.<\/p>\n\n\n
              flowchart<\/span> LR<\/span>\n    F<\/span>[Feature branch]<\/span> --<\/span>> PR<\/span>[Pull request]<\/span>\n    PR<\/span> --<\/span>> R<\/span>[Review]<\/span>\n    R<\/span> --<\/span>> CI<\/span>[Required checks]<\/span>\n    CI<\/span> --<\/span>> M<\/span>[Merge]<\/span>\n    M<\/span> --<\/span>> MAIN<\/span>[main]<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
              Without protection:<\/p>\n\n\n
              Developer -> direct push -> main\n<\/code><\/span><\/pre>\n\n\n
              With a ruleset:<\/p>\n\n\n
              Developer -> PR -> review -> CI -> merge -> main\n<\/code><\/span><\/pre>\n\n\n
              \n\n\n\n
              14. Rulesets vs Legacy Branch Protection<\/h2>\n\n\n\n
              Both can protect branches.<\/p>\n\n\n\n
              Capability<\/th>Branch protection<\/th>Rulesets<\/th><\/tr><\/thead>
              Protect branch<\/td>Yes<\/td>Yes<\/td><\/tr>
              Multiple policies layer<\/td>Limited<\/td>Yes<\/td><\/tr>
              Easy visibility of active policy<\/td>Less<\/td>Better<\/td><\/tr>
              Branch and tag targeting<\/td>Primarily branch<\/td>Branch and tag<\/td><\/tr>
              Push restrictions<\/td>No<\/td>Supported on eligible plans<\/td><\/tr>
              Disable policy without deleting<\/td>Less flexible<\/td>Yes<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
              Rulesets and legacy branch protection can apply at the same time<\/strong>. If a pull request is unexpectedly blocked, inspect both.<\/p>\n\n\n\n
              \n\n\n\n
              15. Essential Default-Branch Rules<\/h2>\n\n\n\n
              For an important application repository, a practical starting baseline is:<\/p>\n\n\n\n
                \n
              • Require pull request before merge<\/li>\n\n\n\n
              • Require at least one approval<\/li>\n\n\n\n
              • Require meaningful status checks<\/li>\n\n\n\n
              • Require conversation resolution where useful<\/li>\n\n\n\n
              • Require CODEOWNER review for sensitive paths when needed<\/li>\n\n\n\n
              • Block force pushes<\/li>\n\n\n\n
              • Restrict deletion of the protected branch<\/li>\n<\/ul>\n\n\n\n
                Optional depending on policy:<\/p>\n\n\n\n
                  \n
                • Signed commits<\/li>\n\n\n\n
                • Linear history<\/li>\n\n\n\n
                • Multiple approvals<\/li>\n\n\n\n
                • Required deployment before merge<\/li>\n<\/ul>\n\n\n\n
                  Example:<\/p>\n\n\n
                  Target: main\nRequire<\/span> pull request: Yes\nApprovals: 1<\/span>\nRequired check: test\nBlock force push: Yes\nRestrict deletion: Yes\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
                  Start simple. A ruleset nobody understands becomes operational friction.<\/p>\n\n\n\n
                  \n\n\n\n
                  16. Required Status Checks<\/h2>\n\n\n\n
                  Required checks connect CI to merge governance.<\/p>\n\n\n\n
                  Example:<\/p>\n\n\n
                  name: CI\n\non:\n  pull_request:\n\npermissions:\n  contents: read\n\njobs:\n  test:\n    runs-on: ubuntu-latest\n    steps:\n      - uses: actions\/checkout@v7\n      - run: echo<\/span> \"run tests\"<\/span>\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
                  If the required check is renamed or the workflow no longer triggers, the pull request may remain blocked.<\/p>\n\n\n\n
                  Troubleshoot in this order:<\/p>\n\n\n\n
                    \n
                  1. Did the workflow trigger?<\/li>\n\n\n\n
                  2. Did the job run?<\/li>\n\n\n\n
                  3. What is the exact check name?<\/li>\n\n\n\n
                  4. Does the ruleset require that exact check?<\/li>\n\n\n\n
                  5. Does another ruleset or branch protection rule also apply?<\/li>\n<\/ol>\n\n\n\n
                    \n\n\n\n
                    17. CODEOWNERS and Bypass<\/h2>\n\n\n\n
                    CODEOWNERS<\/code> maps sensitive paths to responsible reviewers.<\/p>\n\n\n
                    * @acme<\/span>\/platform\n.github\/workflows\/ @acme\/platform @acme\/security\nsrc\/payments\/ @acme\/payments\ninfra\/ @acme\/platform\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
                    A ruleset can require code-owner review.<\/p>\n\n\n\n
                    This is valuable for workflow files because they may control:<\/p>\n\n\n\n
                      \n
                    • GITHUB_TOKEN<\/code><\/li>\n\n\n\n
                    • Secrets<\/li>\n\n\n\n
                    • OIDC cloud identity<\/li>\n\n\n\n
                    • Production deployment<\/li>\n<\/ul>\n\n\n\n
                      Bypass<\/h3>\n\n\n\n
                      Rulesets can allow approved users, teams, roles, or GitHub Apps to bypass rules.<\/p>\n\n\n\n
                      Keep bypass narrow and documented.<\/p>\n\n\n\n
                      Before adding bypass, ask:<\/p>\n\n\n\n
                      \n
                      What exact operational scenario requires it?<\/p>\n<\/blockquote>\n\n\n\n
                      \n\n\n\n
                      Module 5 \u2014 GitHub Actions Repository Settings<\/h1>\n\n\n\n
                      18. Why Actions Settings Are Security Settings<\/h2>\n\n\n\n
                      GitHub Actions can:<\/p>\n\n\n\n
                        \n
                      • Execute arbitrary code<\/li>\n\n\n\n
                      • Read source code<\/li>\n\n\n\n
                      • Use\u00a0GITHUB_TOKEN<\/code><\/li>\n\n\n\n
                      • Read secrets<\/li>\n\n\n\n
                      • Request OIDC tokens<\/li>\n\n\n\n
                      • Publish packages\/releases<\/li>\n\n\n\n
                      • Deploy applications<\/li>\n\n\n\n
                      • Reach internal networks from self-hosted runners<\/li>\n<\/ul>\n\n\n\n
                        Therefore:<\/p>\n\n\n\n
                        \n
                        Workflow authority is repository authority.<\/strong><\/p>\n<\/blockquote>\n\n\n\n
                        \n\n\n\n
                        19. Five Essential Actions Controls<\/h2>\n\n\n
                        flowchart<\/span> TD<\/span>\n    A<\/span>[Actions enabled?]<\/span> --<\/span>> B<\/span>[Which Actions are trusted?]<\/span>\n    B<\/span> --<\/span>> C<\/span>[What may GITHUB_TOKEN do?]<\/span>\n    C<\/span> --<\/span>> D<\/span>[Where does the job run?]<\/span>\n    D<\/span> --<\/span>> E<\/span>[Which credentials can it access?]<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
                        The five controls are:<\/p>\n\n\n\n
                          \n
                        1. Actions enablement<\/li>\n\n\n\n
                        2. Allowed Actions and reusable workflows<\/li>\n\n\n\n
                        3. Default\u00a0GITHUB_TOKEN<\/code>\u00a0permissions<\/li>\n\n\n\n
                        4. Runner trust boundary<\/li>\n\n\n\n
                        5. Secrets \/ OIDC access<\/li>\n<\/ol>\n\n\n\n
                          \n\n\n\n
                          20. Allowed Actions and Reusable Workflows<\/h2>\n\n\n\n
                          Repository settings can disable Actions or restrict which actions and reusable workflows may run, subject to organization policy.<\/p>\n\n\n\n
                          Treat third-party Actions as software dependencies.<\/p>\n\n\n
                          - uses: vendor\/action@v1\n<\/code><\/span><\/pre>\n\n\n
                          This means third-party code executes inside your CI\/CD trust boundary.<\/p>\n\n\n\n
                          Prefer:<\/p>\n\n\n
                          GitHub-maintained Actions\nOrganization-maintained reusable workflows\nReviewed third-party Actions\nImmutable SHA pinning for high-assurance workflows\n<\/code><\/span><\/pre>\n\n\n
                          \n\n\n\n
                          21. GITHUB_TOKEN<\/code> Permissions<\/h2>\n\n\n\n
                          GitHub Actions can receive a repository-scoped GITHUB_TOKEN<\/code>.<\/p>\n\n\n\n
                          Strong baseline:<\/p>\n\n\n
                          Repository default<\/span>: Restricted\/read-oriented\nWorkflow<\/span>: Request only the permission it needs\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                          CI example:<\/p>\n\n\n
                          name: CI\n\non:\n  push:\n    branches: [main]\n  pull_request:\n\npermissions:\n  contents: read\n\njobs:\n  test:\n    runs-on: ubuntu-latest\n    steps:\n      - uses: actions\/checkout@v7\n      - run: echo<\/span> \"test\"<\/span>\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
                          A release workflow may need:<\/p>\n\n\n
                          permissions:\n  contents: write\n<\/code><\/span><\/pre>\n\n\n
                          OIDC-based cloud authentication commonly needs:<\/p>\n\n\n
                          permissions:\n  contents: read\n  id-token: write\n<\/code><\/span><\/pre>\n\n\n
                          id-token: write<\/code> permits requesting an OIDC token; the cloud trust policy still decides what cloud permissions are granted.<\/p>\n\n\n\n
                          \n\n\n\n
                          22. Fork Workflows and Runners<\/h2>\n\n\n\n
                          Fork pull requests are a trust boundary because an external contributor may control code executed by CI.<\/p>\n\n\n\n
                          Ask:<\/p>\n\n\n\n
                            \n
                          • Does the workflow receive secrets?<\/li>\n\n\n\n
                          • Is the token write-capable?<\/li>\n\n\n\n
                          • Does it run on a self-hosted runner?<\/li>\n\n\n\n
                          • Does it require approval first?<\/li>\n<\/ul>\n\n\n\n
                            Runner types<\/h3>\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
                              A self-hosted runner executes repository-controlled code on infrastructure you operate.<\/p>\n\n\n\n
                              Strong rule:<\/p>\n\n\n\n
                              \n
                              Do not run untrusted public pull-request code on a privileged, persistent self-hosted runner.<\/p>\n<\/blockquote>\n\n\n\n
                              Actions baseline<\/h3>\n\n\n
                              Actions: Enabled when needed\nAllowed Actions: Follow approved organization policy\nDefault<\/span> GITHUB_TOKEN: Restricted\nWorkflow permissions: Explicit in YAML\nSelf<\/span>-hosted runner: Only when justified\nCloud access: OIDC where practical\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
                              \n\n\n\n
                              Module 6 \u2014 Environments, Secrets, and Variables<\/h1>\n\n\n\n
                              23. What Is a GitHub Environment?<\/h2>\n\n\n\n
                              An environment represents a deployment target such as:<\/p>\n\n\n
                              development\nstaging\nproduction\n<\/code><\/span><\/pre>\n\n\n
                              A job can reference it:<\/p>\n\n\n
                              jobs:\n  deploy:\n    runs-on: ubuntu-latest\n    environment: production\n    steps:\n      - run: echo<\/span> \"deploying production\"<\/span>\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
                              Depending on plan and repository visibility, 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
                                \n\n\n\n
                                24. Production Environment Flow<\/h2>\n\n\n
                                flowchart TD\n    M[Code merged] --> W[Deployment workflow]\n    W --> E[production environment]\n    E --> A{Protection satisfied?}\n    A -- No --> X[Wait \/ block]\n    A -- Yes --> S[Environment secrets available]\n    S --> P[Deploy]\n<\/code><\/span><\/pre>\n\n\n
                                Environment protection separates normal CI from production authority.<\/p>\n\n\n\n
                                Useful controls include:<\/p>\n\n\n\n
                                  \n
                                • Required reviewer<\/li>\n\n\n\n
                                • Prevent self-review where supported<\/li>\n\n\n\n
                                • Branch\/tag restriction such as\u00a0main<\/code>\u00a0or\u00a0v*<\/code><\/li>\n<\/ul>\n\n\n\n
                                  An approval should represent a real control, not ceremony.<\/p>\n\n\n\n
                                  \n\n\n\n
                                  25. Secrets vs Variables<\/h2>\n\n\n\n
                                  Type<\/th>Use for<\/th>Example<\/th><\/tr><\/thead>
                                  Secret<\/td>Sensitive value<\/td>API token<\/td><\/tr>
                                  Variable<\/td>Non-sensitive configuration<\/td>REGION=ap-northeast-1<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                                  Repository secret:<\/p>\n\n\n
                                  env:\n  API_TOKEN: ${{ secrets.API_TOKEN }}\n<\/code><\/span><\/pre>\n\n\n
                                  Environment secret:<\/p>\n\n\n\n
                                    \n
                                  • Available only to jobs that reference the environment<\/li>\n\n\n\n
                                  • Released only after environment protections pass<\/li>\n<\/ul>\n\n\n\n
                                    For production credentials, environment scope is often better than broad repository scope.<\/p>\n\n\n\n
                                    Variable:<\/p>\n\n\n
                                    - run: echo<\/span> \"Region: ${{ vars.REGION }}\"<\/span>\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
                                    Never use variables as a password\/token store.<\/p>\n\n\n\n
                                    \n\n\n\n
                                    26. Prefer OIDC for Cloud Credentials<\/h2>\n\n\n\n
                                    Avoid long-lived cloud credentials when federation is practical.<\/p>\n\n\n\n
                                    Instead of:<\/p>\n\n\n
                                    AWS_ACCESS_KEY_ID -> GitHub secret\nAWS_SECRET_ACCESS_KEY -> GitHub secret\n<\/code><\/span><\/pre>\n\n\n
                                    Prefer:<\/p>\n\n\n
                                    GitHub workflow\n   -> OIDC token\n   -> cloud IAM trust policy\n   -> short-lived cloud credential\n<\/code><\/span><\/pre>\n\n\n
                                    Benefits:<\/p>\n\n\n\n
                                      \n
                                    • No permanent cloud key copied into GitHub<\/li>\n\n\n\n
                                    • Short-lived credentials<\/li>\n\n\n\n
                                    • Trust can be restricted by repository, branch, environment, or workflow identity<\/li>\n<\/ul>\n\n\n\n
                                      OIDC still requires least-privilege cloud IAM permissions.<\/p>\n\n\n\n
                                      \n\n\n\n
                                      Module 7 \u2014 Repository Security Essentials<\/h1>\n\n\n\n
                                      27. Security Controls Mental Model<\/h2>\n\n\n
                                      Dependencies -> Dependabot\nSource code  -> Code scanning\nSecrets      -> Secret scanning\nNew<\/span> pushes   -> Push protection\nChanges      -> Rulesets and<\/span> reviews\nDeployment   -> Environments\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
                                      Feature availability depends on plan, visibility, organization policy, and security-product licensing.<\/p>\n\n\n\n
                                      \n\n\n\n
                                      28. Dependency Security<\/h2>\n\n\n\n
                                      The dependency graph helps GitHub understand packages used by the repository.<\/p>\n\n\n\n
                                      Dependabot can provide:<\/p>\n\n\n\n
                                        \n
                                      • Vulnerability alerts<\/li>\n\n\n\n
                                      • Security update pull requests<\/li>\n\n\n\n
                                      • Scheduled version update pull requests<\/li>\n<\/ul>\n\n\n\n
                                        Minimal example:<\/p>\n\n\n
                                        version: 2<\/span>\nupdates<\/span>:\n  - package-ecosystem: \"npm\"<\/span>\n    directory<\/span>: \"\/\"<\/span>\n    schedule<\/span>:\n      interval: \"weekly\"<\/span>\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                                        Remember:<\/p>\n\n\n
                                        Dependabot alerts          -> tell you a dependency is vulnerable\nDependabot security update -> can open a remediation PR\nDependabot version update  -> keeps dependencies current on schedule\n<\/code><\/span><\/pre>\n\n\n
                                        \n\n\n\n
                                        29. Code Scanning<\/h2>\n\n\n\n
                                        Code scanning analyzes source code for vulnerabilities and coding errors. GitHub supports CodeQL and compatible SARIF integrations.<\/p>\n\n\n\n
                                        Sensible rollout:<\/p>\n\n\n\n
                                          \n
                                        1. Enable scanning.<\/li>\n\n\n\n
                                        2. Establish a baseline.<\/li>\n\n\n\n
                                        3. Fix meaningful existing findings.<\/li>\n\n\n\n
                                        4. Focus merge policy on important new findings.<\/li>\n\n\n\n
                                        5. Avoid blocking developers on an unexplained flood of legacy alerts.<\/li>\n<\/ol>\n\n\n\n
                                          Security gates work best when teams trust the signal.<\/p>\n\n\n\n
                                          \n\n\n\n
                                          30. Secret Scanning and Push Protection<\/h2>\n\n\n\n
                                          Secret scanning detects supported credentials committed to the repository.<\/p>\n\n\n\n
                                          If a real credential is committed, removing the line from the latest commit is not enough; the credential may still exist in history.<\/p>\n\n\n\n
                                          Response:<\/p>\n\n\n
                                          Detect\n-> revoke \/ rotate\n-> remove from<\/span> code\/history as<\/span> appropriate\n-> review exposure\n-> prevent recurrence\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                                          Push protection attempts to stop supported secrets before they enter the repository<\/strong>.<\/p>\n\n\n
                                          Secret scanning -> detect committed secrets\nPush protection -> prevent supported secrets from<\/span> being introduced\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                                          Essential security baseline<\/h3>\n\n\n\n
                                            \n
                                          • [ ] Dependency visibility enabled\/available as appropriate<\/li>\n\n\n\n
                                          • [ ] Dependabot alerts enabled where applicable<\/li>\n\n\n\n
                                          • [ ] Code scanning enabled where available and useful<\/li>\n\n\n\n
                                          • [ ] Secret scanning enabled where available<\/li>\n\n\n\n
                                          • [ ] Push protection enabled where available<\/li>\n\n\n\n
                                          • [ ] Default branch protected<\/li>\n\n\n\n
                                          • [ ] Workflow files protected through review\/CODEOWNERS<\/li>\n\n\n\n
                                          • [ ] Production protected with environments<\/li>\n<\/ul>\n\n\n\n
                                            \n\n\n\n
                                            Module 8 \u2014 High-Risk Lifecycle Settings<\/h1>\n\n\n\n
                                            31. Danger Zone<\/h2>\n\n\n\n
                                            Repository Danger Zone<\/strong> actions include:<\/p>\n\n\n\n
                                              \n
                                            • Change repository visibility<\/li>\n\n\n\n
                                            • Transfer repository<\/li>\n\n\n\n
                                            • Archive repository<\/li>\n\n\n\n
                                            • Delete repository<\/li>\n<\/ul>\n\n\n\n
                                              Treat them as change-management events, not routine clicks.<\/p>\n\n\n\n
                                              \n\n\n\n
                                              32. Visibility Changes<\/h2>\n\n\n\n
                                              Visibility may be public, private, or internal for eligible enterprise repositories.<\/p>\n\n\n\n
                                              A visibility change can affect more than source files, including:<\/p>\n\n\n\n
                                                \n
                                              • Fork relationships<\/li>\n\n\n\n
                                              • Actions history\/exposure<\/li>\n\n\n\n
                                              • Security behavior<\/li>\n\n\n\n
                                              • Pages or packages<\/li>\n\n\n\n
                                              • Stars\/watchers<\/li>\n\n\n\n
                                              • External access expectations<\/li>\n<\/ul>\n\n\n\n
                                                Safe procedure:<\/p>\n\n\n\n
                                                  \n
                                                1. Confirm why the change is needed.<\/li>\n\n\n\n
                                                2. Review code, issues, PRs, Actions logs\/artifacts, and integrations.<\/li>\n\n\n\n
                                                3. Review forks, packages, and publishing surfaces.<\/li>\n\n\n\n
                                                4. Confirm organization policy permits it.<\/li>\n\n\n\n
                                                5. Make the change.<\/li>\n\n\n\n
                                                6. Validate access afterward.<\/li>\n<\/ol>\n\n\n\n
                                                  \n
                                                  Never convert a private repository to public as a casual experiment.<\/p>\n<\/blockquote>\n\n\n\n
                                                  \n\n\n\n
                                                  33. Transfer, Archive, and Delete<\/h2>\n\n\n\n
                                                  Transfer<\/h3>\n\n\n\n
                                                  Before transfer, review:<\/p>\n\n\n\n
                                                    \n
                                                  • New owner permissions<\/li>\n\n\n\n
                                                  • Automation\/integrations<\/li>\n\n\n\n
                                                  • Packages<\/li>\n\n\n\n
                                                  • Fork relationships<\/li>\n\n\n\n
                                                  • Secrets\/deploy keys<\/li>\n\n\n\n
                                                  • Organization policies that will change<\/li>\n<\/ul>\n\n\n\n
                                                    Archive<\/h3>\n\n\n\n
                                                    Archiving makes a repository read-only while preserving it as reference.<\/p>\n\n\n\n
                                                    Good for retired or superseded systems.<\/p>\n\n\n\n
                                                    Delete<\/h3>\n\n\n\n
                                                    Deletion is destructive and can affect source code, issues, PRs, automation references, packages, and integrations.<\/p>\n\n\n\n
                                                    Recommended lifecycle:<\/p>\n\n\n
                                                    flowchart<\/span> LR<\/span>\n    A<\/span>[Active]<\/span> --<\/span>> D<\/span>[Deprecated]<\/span>\n    D<\/span> --<\/span>> AR<\/span>[Archived]<\/span>\n    AR<\/span> --<\/span>> X<\/span>[Deleted only if justified]<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
                                                    When practical:<\/p>\n\n\n
                                                    Deprecate -> Archive -> Delete only after review\n<\/code><\/span><\/pre>\n\n\n
                                                    \n\n\n\n
                                                    Module 9 \u2014 10-Minute Hands-On Essentials Lab<\/h1>\n\n\n\n
                                                    34. Scenario<\/h2>\n\n\n\n
                                                    You administer:<\/p>\n\n\n
                                                    acme-engineering\/repository-settings-lab\n<\/code><\/span><\/pre>\n\n\n
                                                    The repository contains a small web service. Your goal is to create a safe baseline without over-engineering it.<\/p>\n\n\n\n
                                                    \n\n\n\n
                                                    35. Lab Step 1 \u2014 General and Access<\/h2>\n\n\n\n
                                                    Confirm:<\/p>\n\n\n
                                                    Default<\/span> branch: main\nIssues: Enabled\nActions: Enabled\nSquash merge: Enabled\nDelete merged head branches: Enabled\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
                                                    Then open:<\/p>\n\n\n
                                                    Settings -> Collaborators and teams\n<\/code><\/span><\/pre>\n\n\n
                                                    Review:<\/p>\n\n\n\n
                                                      \n
                                                    • Who has Admin?<\/li>\n\n\n\n
                                                    • Which teams have Write\/Maintain?<\/li>\n\n\n\n
                                                    • Are direct grants necessary?<\/li>\n\n\n\n
                                                    • Are there stale collaborators or mixed roles?<\/li>\n<\/ul>\n\n\n\n
                                                      Target model:<\/p>\n\n\n
                                                      payments-dev -> Write\nplatform     -> Maintain\nrepo-admins  -> Admin only where necessary\n<\/code><\/span><\/pre>\n\n\n
                                                      \n\n\n\n
                                                      36. Lab Step 2 \u2014 CI and Ruleset<\/h2>\n\n\n\n
                                                      Create .github\/workflows\/ci.yml<\/code>:<\/p>\n\n\n
                                                      name: CI\n\non:\n  pull_request:\n  push:\n    branches: [main]\n\npermissions:\n  contents: read\n\njobs:\n  test:\n    runs-on: ubuntu-latest\n    steps:\n      - uses: actions\/checkout@v7\n      - name: Test\n        run: echo<\/span> \"tests passed\"<\/span>\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
                                                      Create a branch ruleset targeting main<\/code>:<\/p>\n\n\n
                                                      Require<\/span> pull request: Yes\nRequired approvals: 1<\/span> when practical\nRequired status check: CI\/test when stable\nBlock force push: Yes\nRestrict deletion: Yes\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
                                                      Test that GitHub explains which condition blocks a merge.<\/p>\n\n\n\n
                                                      \n\n\n\n
                                                      37. Lab Step 3 \u2014 Actions and Environment<\/h2>\n\n\n\n
                                                      Open:<\/p>\n\n\n
                                                      Settings -> Actions -> General\n<\/code><\/span><\/pre>\n\n\n
                                                      Review:<\/p>\n\n\n\n
                                                        \n
                                                      • Allowed Actions\/reusable workflows<\/li>\n\n\n\n
                                                      • Default\u00a0GITHUB_TOKEN<\/code>\u00a0permissions<\/li>\n\n\n\n
                                                      • Fork workflow policy<\/li>\n\n\n\n
                                                      • Runner configuration<\/li>\n<\/ul>\n\n\n\n
                                                        Then create environment:<\/p>\n\n\n
                                                        production\n<\/code><\/span><\/pre>\n\n\n
                                                        Where supported, configure:<\/p>\n\n\n\n
                                                          \n
                                                        • Required reviewer<\/li>\n\n\n\n
                                                        • Prevent self-review<\/li>\n\n\n\n
                                                        • Deployment branch restriction to\u00a0main<\/code><\/li>\n<\/ul>\n\n\n\n
                                                          Add non-sensitive variable:<\/p>\n\n\n
                                                          REGION=ap-northeast-1\n<\/code><\/span><\/pre>\n\n\n
                                                          Example workflow:<\/p>\n\n\n
                                                          name: Deploy\n\non:\n  workflow_dispatch:\n\npermissions:\n  contents: read\n\njobs:\n  deploy:\n    runs-on: ubuntu-latest\n    environment: production\n    steps:\n      - run: echo<\/span> \"Deploying to ${{ vars.REGION }}\"<\/span>\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
                                                          \n\n\n\n
                                                          38. Lab Step 4 \u2014 Security Review<\/h2>\n\n\n\n
                                                          Identify which controls are available in your repository:<\/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
                                                          • Code scanning<\/li>\n\n\n\n
                                                          • Secret scanning<\/li>\n\n\n\n
                                                          • Push protection<\/li>\n<\/ul>\n\n\n\n
                                                            Do not enable licensed features in a production organization without confirming policy and licensing.<\/p>\n\n\n\n
                                                            Expected learning outcome<\/h3>\n\n\n\n
                                                            You can explain this chain:<\/p>\n\n\n
                                                            User access\n-> repository role\n-> pull request\n-> ruleset\n-> CI authority\n-> environment gate\n-> security controls\n<\/code><\/span><\/pre>\n\n\n
                                                            That chain is the core of GitHub Repository Settings administration.<\/p>\n\n\n\n
                                                            \n\n\n\n
                                                            5-Minute Review<\/h1>\n\n\n\n
                                                            39. Ten Rules to Remember<\/h2>\n\n\n\n
                                                              \n
                                                            1. Learn the policy hierarchy.<\/strong>\u00a0Organization and enterprise controls can restrict repository settings.<\/li>\n\n\n\n
                                                            2. Keep Admin rare.<\/strong>\u00a0Use Write or Maintain when sufficient.<\/li>\n\n\n\n
                                                            3. Prefer teams.<\/strong>\u00a0Direct grants are harder to review and revoke.<\/li>\n\n\n\n
                                                            4. Protect the default branch.<\/strong>\u00a0Important changes should flow through PR + review + CI.<\/li>\n\n\n\n
                                                            5. Prefer rulesets for modern protection.<\/strong>\u00a0They are visible, targetable, and layerable.<\/li>\n\n\n\n
                                                            6. Treat workflows as privileged code.<\/strong>\u00a0They can control tokens, secrets, OIDC, and deployment.<\/li>\n\n\n\n
                                                            7. Keep\u00a0GITHUB_TOKEN<\/code>\u00a0restrictive.<\/strong>\u00a0Grant write permissions only where needed.<\/li>\n\n\n\n
                                                            8. Protect production with environments.<\/strong>\u00a0Separate CI authority from deployment authority.<\/li>\n\n\n\n
                                                            9. Use secrets correctly and prefer OIDC for cloud access.<\/strong>\u00a0Variables are not a credential store.<\/li>\n\n\n\n
                                                            10. Treat Danger Zone actions as governance events.<\/strong>\u00a0Visibility, transfer, archive, and delete can have broad side effects.<\/li>\n<\/ol>\n\n\n\n
                                                              \n\n\n\n
                                                              40. Common Anti-Patterns<\/h2>\n\n\n\n
                                                              Anti-pattern<\/th>Why it is a problem<\/th>Better approach<\/th><\/tr><\/thead>
                                                              Everyone is Admin<\/td>Large destructive blast radius<\/td>Write\/Maintain + limited Admin<\/td><\/tr>
                                                              Direct grants everywhere<\/td>Hard to review\/revoke<\/td>Team access<\/td><\/tr>
                                                              Unprotected main<\/code><\/td>Review\/CI can be bypassed<\/td>Ruleset<\/td><\/tr>
                                                              Too many required checks<\/td>Slow, flaky merges<\/td>Require policy-critical checks only<\/td><\/tr>
                                                              Broad bypass<\/td>Policy becomes optional<\/td>Small documented bypass set<\/td><\/tr>
                                                              Broad GITHUB_TOKEN<\/code><\/td>Workflow compromise gains power<\/td>Restricted default + explicit permissions<\/td><\/tr>
                                                              Any Marketplace Action allowed<\/td>Supply-chain risk<\/td>Approved Actions<\/td><\/tr>
                                                              Privileged self-hosted runner for untrusted PRs<\/td>Host\/network exposure<\/td>Trusted isolated\/ephemeral runners<\/td><\/tr>
                                                              Production secret is repository-wide<\/td>Broader exposure<\/td>Environment secret or OIDC<\/td><\/tr>
                                                              Secret placed in vars<\/code><\/td>Not a secret store<\/td>Use secrets<\/code><\/td><\/tr>
                                                              Workflow files have no special review<\/td>CI\/CD authority can change casually<\/td>CODEOWNERS + ruleset<\/td><\/tr>
                                                              Private repo made public without review<\/td>Data exposure<\/td>Visibility checklist<\/td><\/tr>
                                                              Old repo immediately deleted<\/td>History\/context lost<\/td>Deprecate -> archive -> delete if justified<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                                                              \n\n\n\n
                                                              41. Troubleshooting Essentials<\/h2>\n\n\n\n
                                                              Problem<\/th>First thing to check<\/th><\/tr><\/thead>
                                                              User cannot access repository<\/td>Team\/direct access and role<\/td><\/tr>
                                                              User has too much access<\/td>Mixed roles and direct grants<\/td><\/tr>
                                                              Direct push blocked<\/td>Rulesets + branch protection<\/td><\/tr>
                                                              PR cannot merge<\/td>Review, status check, conversation, deployment rule<\/td><\/tr>
                                                              Required check missing<\/td>Workflow trigger and exact check name<\/td><\/tr>
                                                              Ruleset seems ignored<\/td>Target and enforcement status<\/td><\/tr>
                                                              Admin cannot bypass<\/td>Bypass configuration<\/td><\/tr>
                                                              Workflow does not run<\/td>Actions policy + trigger<\/td><\/tr>
                                                              Action denied<\/td>Repository\/org allowlist<\/td><\/tr>
                                                              Workflow gets 403<\/td>GITHUB_TOKEN<\/code> permissions<\/td><\/tr>
                                                              Job stays queued<\/td>Runner labels\/access\/capacity<\/td><\/tr>
                                                              Secret unavailable<\/td>Secret scope, event, environment reference<\/td><\/tr>
                                                              Production waits<\/td>Environment protection\/reviewer<\/td><\/tr>
                                                              Branch cannot deploy<\/td>Environment branch\/tag rule<\/td><\/tr>
                                                              Security feature unavailable<\/td>Plan, visibility, license, org policy<\/td><\/tr>
                                                              Setting greyed out<\/td>Organization\/enterprise policy<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                                                              Universal troubleshooting order:<\/p>\n\n\n
                                                              1. What action is failing?\n2. Which repository role does the actor have?\n3. Which ruleset\/protection applies?\n4. Is there a higher-level policy?\n5. Is the problem access, rules, Actions, environment, or security?\n6. What exact unmet condition does GitHub show?\n<\/code><\/span><\/pre>\n\n\n
                                                              \n\n\n\n
                                                              42. Quick Reference Cheat Sheet<\/h2>\n\n\n\n
                                                              Main settings locations<\/h3>\n\n\n\n
                                                              Need<\/th>Common area<\/th><\/tr><\/thead>
                                                              Rename \/ merge settings<\/td>Settings -> General<\/td><\/tr>
                                                              Manage people\/teams<\/td>Settings -> Collaborators and teams<\/td><\/tr>
                                                              Rulesets<\/td>Settings -> Rulesets<\/td><\/tr>
                                                              Legacy branch protection<\/td>Settings -> Branches<\/td><\/tr>
                                                              Actions permissions<\/td>Settings -> Actions -> General<\/td><\/tr>
                                                              Runners<\/td>Settings -> Actions -> Runners<\/td><\/tr>
                                                              Environments<\/td>Settings -> Environments<\/td><\/tr>
                                                              Actions secrets\/variables<\/td>Settings -> Secrets and variables -> Actions<\/td><\/tr>
                                                              Security features<\/td>Settings -> Advanced Security \/ Security and analysis<\/td><\/tr>
                                                              Visibility \/ transfer \/ archive \/ delete<\/td>Settings -> General -> Danger Zone<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                                                              GitHub navigation changes over time. Learn the capability name and purpose<\/strong>, not only the sidebar position.<\/p>\n\n\n\n
                                                              Essential CLI<\/h3>\n\n\n
                                                              gh auth status\ngh repo view \"$OWNER\/$REPO\"<\/span>\ngh api \"\/repos\/$OWNER\/$REPO\"<\/span>\ngh api --paginate \"\/repos\/$OWNER\/$REPO\/collaborators\"<\/span>\ngh api \"\/repos\/$OWNER\/$REPO\/actions\/permissions\"<\/span>\ngh api \"\/repos\/$OWNER\/$REPO\/rulesets\"<\/span>\ngh api \"\/repos\/$OWNER\/$REPO\/environments\"<\/span>\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                                                              API access depends on token permissions and repository policy.<\/p>\n\n\n\n
                                                              \n\n\n\n
                                                              43. Knowledge Check<\/h2>\n\n\n\n
                                                                \n
                                                              1. Why can an admin be unable to change a repository setting?<\/li>\n\n\n\n
                                                              2. What is the difference between Write, Maintain, and Admin?<\/li>\n\n\n\n
                                                              3. Why are teams preferable to repeated direct grants?<\/li>\n\n\n\n
                                                              4. What can break when the default branch changes?<\/li>\n\n\n\n
                                                              5. When is squash merge useful?<\/li>\n\n\n\n
                                                              6. Why protect\u00a0main<\/code>?<\/li>\n\n\n\n
                                                              7. How do rulesets differ from legacy branch protection?<\/li>\n\n\n\n
                                                              8. Why can multiple protection layers make troubleshooting confusing?<\/li>\n\n\n\n
                                                              9. Why protect\u00a0.github\/workflows\/<\/code>\u00a0with CODEOWNERS\/review?<\/li>\n\n\n\n
                                                              10. What does\u00a0GITHUB_TOKEN<\/code>\u00a0represent?<\/li>\n\n\n\n
                                                              11. Why make workflow permissions explicit?<\/li>\n\n\n\n
                                                              12. Why are fork workflows a trust boundary?<\/li>\n\n\n\n
                                                              13. What is risky about privileged persistent self-hosted runners?<\/li>\n\n\n\n
                                                              14. What does an environment protect?<\/li>\n\n\n\n
                                                              15. How do environment secrets differ from repository secrets?<\/li>\n\n\n\n
                                                              16. Why prefer OIDC to long-lived cloud keys?<\/li>\n\n\n\n
                                                              17. How do secret scanning and push protection differ?<\/li>\n\n\n\n
                                                              18. Why is visibility change a governance event?<\/li>\n<\/ol>\n\n\n\n
                                                                Fast answers<\/h3>\n\n\n\n
                                                                  \n
                                                                1. Organization or enterprise policy may be more restrictive.<\/li>\n\n\n\n
                                                                2. Write supports development, Maintain adds repository operations, Admin provides full repository administration.<\/li>\n\n\n\n
                                                                3. Teams simplify onboarding, offboarding, review, and ownership.<\/li>\n\n\n\n
                                                                4. Workflows, rules, deployment policies, docs, and external integrations may still reference the old branch.<\/li>\n\n\n\n
                                                                5. When the team wants one clean commit per PR.<\/li>\n\n\n\n
                                                                6. To require controlled review and CI instead of direct unsafe changes.<\/li>\n\n\n\n
                                                                7. Rulesets provide more flexible targeting, layering, and visibility.<\/li>\n\n\n\n
                                                                8. All applicable rules can be enforced simultaneously.<\/li>\n\n\n\n
                                                                9. Workflow changes can change tokens, secrets, OIDC, and deployments.<\/li>\n\n\n\n
                                                                10. It is the repository-scoped token issued to Actions jobs.<\/li>\n\n\n\n
                                                                11. So the workflow receives only the authority it needs.<\/li>\n\n\n\n
                                                                12. External contributors may control code executed by CI.<\/li>\n\n\n\n
                                                                13. Untrusted code may access host files, credentials, or internal networks.<\/li>\n\n\n\n
                                                                14. It gates deployment using approvals, ref restrictions, protection rules, secrets, and variables.<\/li>\n\n\n\n
                                                                15. Environment secrets are available only to jobs using that environment after protections pass.<\/li>\n\n\n\n
                                                                16. OIDC provides short-lived identity-based credentials instead of stored permanent keys.<\/li>\n\n\n\n
                                                                17. Secret scanning detects committed secrets; push protection tries to block supported secrets before introduction.<\/li>\n\n\n\n
                                                                18. It can alter exposure of code, history, automation, forks, and related repository data.<\/li>\n<\/ol>\n\n\n\n
                                                                  \n\n\n\n
                                                                  44. What to Learn Next<\/h2>\n\n\n\n
                                                                  After this Essentials guide, continue with:<\/p>\n\n\n\n
                                                                    \n
                                                                  1. Advanced rulesets, tag rules, and push rules<\/li>\n\n\n\n
                                                                  2. Reusable workflows and Actions supply-chain hardening<\/li>\n\n\n\n
                                                                  3. OIDC trust design for AWS\/Azure\/GCP<\/li>\n\n\n\n
                                                                  4. Self-hosted runner security<\/li>\n\n\n\n
                                                                  5. Webhooks and GitHub Apps<\/li>\n\n\n\n
                                                                  6. Dependabot and dependency review<\/li>\n\n\n\n
                                                                  7. Code scanning\/security configurations<\/li>\n\n\n\n
                                                                  8. Release immutability and release-tag governance<\/li>\n\n\n\n
                                                                  9. GitHub Pages<\/li>\n\n\n\n
                                                                  10. Copilot\/MCP repository governance where used<\/li>\n\n\n\n
                                                                  11. REST\/GraphQL\/CLI automation<\/li>\n\n\n\n
                                                                  12. Terraform and Repository-as-Code<\/li>\n\n\n\n
                                                                  13. Organization\/enterprise policy architecture<\/li>\n<\/ol>\n\n\n\n
                                                                    \n\n\n\n
                                                                    45. Essential Production Baseline<\/h2>\n\n\n
                                                                    GitHub Repository\n|\n|-- General\n|   |-- Stable identity\n|   |-- Deliberate default<\/span> branch\n|   |-- Deliberate merge strategy\n|   `-- Only useful features enabled\n|\n|-- Access\n|   |-- Teams preferred\n|   |-- Least-privilege roles\n|   `<\/span>-- Admin rare\n|\n|-- Change protection\n|   |-- Ruleset on main\n|   |-- Pull request required\n|   |-- Review + meaningful CI\n|   |-- Force push blocked\n|   `-- Sensitive paths owned\n|\n|-- Actions\n|   |-- Approved Actions\/workflows\n|   |-- Restricted GITHUB_TOKEN\n|   |-- Trusted runner boundary\n|   `<\/span>-- OIDC \/ scoped secrets\n|\n|-- Environments\n|   |-- Production protected\n|   |-- Approved refs only\n|   `-- Production credentials scoped\n|\n|-- Security\n|   |-- Dependency protection\n|   |-- Code scanning where available\n|   |-- Secret scanning where available\n|   `<\/span>-- Push protection where available\n|\n`-- Lifecycle\n    |-- Visibility changes reviewed\n    |-- Archive before delete when practical\n    `<\/span>-- Destructive actions deliberate\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                                                                    The core principle is:<\/p>\n\n\n\n
                                                                    \n
                                                                    Access gives authority, rules constrain change, Actions automate authority, environments constrain deployment, security detects risk, and lifecycle controls protect the repository itself.<\/strong><\/p>\n<\/blockquote>\n\n\n\n
                                                                    \n\n\n\n
                                                                    Selected Official References<\/h2>\n\n\n\n