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

This is the Essentials 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.

The goal is not to memorize every item in the Settings sidebar. The goal is to understand the repository control path:

General behavior -> Access -> Change protection -> CI/CD authority
                 -> Deployment protection -> Security -> Lifecycle safety

flowchart LR
    G[General] --> A[Access]
    A --> R[Rulesets]
    R --> C[Actions]
    C --> E[Environments]
    E --> S[Security]
    S --> L[Lifecycle]
Code language: CSS (css)

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.

Important: 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.

1. Two-Hour Learning Plan

What is intentionally outside this 2-hour scope?

Use the complete reference guide later for:

• Detailed moderation and interaction limits
• Advanced tag and push rules
• Release immutability deep-dive
• Actions retention and cache tuning
• Advanced self-hosted runner architecture
• Webhook implementation and signature verification
• Copilot instructions, coding agent, and MCP
• GitHub Pages
• Code Quality and AI Scan administration
• Detailed deploy-key operations
• Codespaces and Dependabot secret administration
• REST, GraphQL, and Terraform automation
• Enterprise-scale repository governance

These are important, but they are not prerequisites for day-to-day repository administration.

Module 1 — Repository Settings Foundations

2. What Do Repository Settings Control?

Repository settings are the control plane for one repository.

They decide:

• Who can access the repository
• Which branch is the default
• How pull requests may be merged
• Whether unsafe changes are blocked
• Which GitHub Actions workflows may run
• What permissions workflows receive
• How production deployment is protected
• Where secrets and variables are stored
• Which security features are enabled
• Whether the repository can be exposed, transferred, archived, or deleted

Think of two planes:

Development plane
- Code
- Issues
- Pull requests
- Releases
- Workflows

Control plane
- Settings
- Access
- Rulesets
- Actions policy
- Environments
- Security

Developers spend most of their time in the development plane. Repository administrators must understand the control plane.

3. Repository Configuration Hierarchy

A repository does not operate in isolation.

flowchart TD
    E[Enterprise policy] --> O[Organization policy]
    O --> R[Repository settings]
    R --> B[Branch / tag rules]
    R --> A[Actions settings]
    R --> V[Environment protection]
    A --> W[Workflow permissions]
Code language: CSS (css)

A useful precedence model is:

Enterprise policy
        ↓
Organization policy
        ↓
Repository settings
        ↓
Environment protection
        ↓
Workflow / job permissions

For example, a repository cannot allow an Action that the organization has blocked.

Troubleshooting rule

When a setting is disabled or cannot be made more permissive, ask:

Is this control owned by the repository, organization, or enterprise?

4. Repository Roles

For organization repositories, the standard roles are:

Use the lowest role that enables the job.

Developer        -> Write
Repository lead  -> Maintain when sufficient
Repo admin       -> Admin only when required
Auditor          -> Read
Issue coordinator -> Triage

5. Training Repository Setup

Use a disposable test repository, for example:

acme-engineering/repository-settings-lab

Recommended prerequisites:

• Admin access to the test repository
• GitHub CLI installed
• Git installed
• GitHub Actions enabled
• A simple CI workflow

Authenticate:

gh auth login
gh auth status

Set reusable variables:

export OWNER="acme-engineering"
export REPO="repository-settings-lab"
Code language: JavaScript (javascript)

Verify access:

gh repo view "$OWNER/$REPO"
Code language: JavaScript (javascript)

Module 2 — General Settings That Matter

6. Repository Identity and Default Branch

Repository identity includes the name, owner, description, website, topics, and visibility.

A rename can affect:

• Clone URLs
• CI/CD references
• Documentation
• Badges
• Package configuration
• External integrations

GitHub commonly redirects old repository URLs, but integrations should be updated rather than relying on redirects indefinitely.

Update a local remote after a rename:

git remote set-url origin git@github.com:acme/payments-api.git
git remote -v
Code language: JavaScript (javascript)

Default branch

The default branch—commonly main—influences:

• New pull requests
• Repository landing view
• Branch comparisons
• Workflow assumptions
• Protection rules
• Deployment rules

A workflow may explicitly depend on it:

on:
  push:
    branches: [main]
Code language: CSS (css)

Changing the default branch does not automatically rewrite every workflow or external integration.

7. Repository Features

Common optional features include:

Enable what the team actually uses.

Example internal microservice:

Issues: Yes
Actions: Yes
Projects: Only if planning happens in GitHub
Discussions: Usually no
Wiki: Usually no if docs live elsewhere
Code language: HTTP (http)

8. Pull Request Merge Methods

GitHub supports three common strategies:

Simple decision model:

One commit per PR?           -> Squash
Keep complete branch history? -> Merge commit
Linear individual commits?    -> Rebase

The right method depends on how the team uses Git history.

9. Auto-Merge and Branch Cleanup

Auto-merge lets a pull request merge automatically after all required conditions pass.

flowchart LR
    PR[Pull request] --> RV[Review]
    RV --> CI[Required CI]
    CI --> Q{All rules pass?}
    Q -- No --> W[Wait]
    Q -- Yes --> M[Merge]

It works well when CI is reliable and protection rules are meaningful.

GitHub can also automatically delete the source branch after merge. This is useful for short-lived feature branches and keeps the repository clean.

Practical baseline

Default branch: main
Issues: Enabled
Actions: Enabled
Squash merge: Enabled
Auto-merge: Optional, when team uses it
Delete merged head branches: Enabled
Code language: PHP (php)

Module 3 — Access and Permissions

10. Repository Access Model

Access can come from multiple sources.

flowchart TD
    T[Team] --> E[Effective access]
    D[Direct collaborator] --> E
    O[Organization / base access] --> E
    E --> P[Repository protections still apply]
Code language: CSS (css)

Important distinction:

Permission determines what a user may attempt. Rules determine what changes GitHub will accept.

A developer may have Write access and still be blocked from pushing to main because a ruleset requires pull requests.

11. Team Access vs Direct Access

For organization repositories, prefer team-based access.

Alice ----+
Bob ------+--> payments-team --> payments repositories
Carol ----+

Benefits:

• Easier onboarding/offboarding
• Easier access review
• Better ownership model
• Works well with CODEOWNERS
• Less permission drift

Direct access is reasonable for exceptional or temporary cases, such as a contractor who needs one repository for a limited period.

12. Mixed Roles and Access Review

A user can receive access from multiple sources.

Example:

Alice
  -> engineering team: Write
  -> direct grant: Admin

Her effective access is more powerful than the team role suggests.

Use Settings -> Collaborators and teams to inspect people, teams, roles, and mixed access.

A simple review table:

Essential rule

Repository access should be explainable in one minute.

Module 4 — Rulesets and Protected Branches

13. Why Rulesets Matter

Rulesets control how users interact with branches, tags, and—on eligible plans—pushes.

The most important use case is protecting the default branch.

flowchart LR
    F[Feature branch] --> PR[Pull request]
    PR --> R[Review]
    R --> CI[Required checks]
    CI --> M[Merge]
    M --> MAIN[main]
Code language: CSS (css)

Without protection:

Developer -> direct push -> main

With a ruleset:

Developer -> PR -> review -> CI -> merge -> main

14. Rulesets vs Legacy Branch Protection

Both can protect branches.

Rulesets and legacy branch protection can apply at the same time. If a pull request is unexpectedly blocked, inspect both.

15. Essential Default-Branch Rules

For an important application repository, a practical starting baseline is:

• Require pull request before merge
• Require at least one approval
• Require meaningful status checks
• Require conversation resolution where useful
• Require CODEOWNER review for sensitive paths when needed
• Block force pushes
• Restrict deletion of the protected branch

Optional depending on policy:

• Signed commits
• Linear history
• Multiple approvals
• Required deployment before merge

Example:

Target: main
Require pull request: Yes
Approvals: 1
Required check: test
Block force push: Yes
Restrict deletion: Yes
Code language: PHP (php)

Start simple. A ruleset nobody understands becomes operational friction.

16. Required Status Checks

Required checks connect CI to merge governance.

Example:

name: CI

on:
  pull_request:

permissions:
  contents: read

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - run: echo "run tests"
Code language: PHP (php)

If the required check is renamed or the workflow no longer triggers, the pull request may remain blocked.

Troubleshoot in this order:

1. Did the workflow trigger?
2. Did the job run?
3. What is the exact check name?
4. Does the ruleset require that exact check?
5. Does another ruleset or branch protection rule also apply?

17. CODEOWNERS and Bypass

CODEOWNERS maps sensitive paths to responsible reviewers.

* @acme/platform
.github/workflows/ @acme/platform @acme/security
src/payments/ @acme/payments
infra/ @acme/platform
Code language: CSS (css)

A ruleset can require code-owner review.

This is valuable for workflow files because they may control:

• GITHUB_TOKEN
• Secrets
• OIDC cloud identity
• Production deployment

Bypass

Rulesets can allow approved users, teams, roles, or GitHub Apps to bypass rules.

Keep bypass narrow and documented.

Before adding bypass, ask:

What exact operational scenario requires it?

Module 5 — GitHub Actions Repository Settings

18. Why Actions Settings Are Security Settings

GitHub Actions can:

• Execute arbitrary code
• Read source code
• Use GITHUB_TOKEN
• Read secrets
• Request OIDC tokens
• Publish packages/releases
• Deploy applications
• Reach internal networks from self-hosted runners

Therefore:

Workflow authority is repository authority.

19. Five Essential Actions Controls

flowchart TD
    A[Actions enabled?] --> B[Which Actions are trusted?]
    B --> C[What may GITHUB_TOKEN do?]
    C --> D[Where does the job run?]
    D --> E[Which credentials can it access?]
Code language: CSS (css)

The five controls are:

1. Actions enablement
2. Allowed Actions and reusable workflows
3. Default GITHUB_TOKEN permissions
4. Runner trust boundary
5. Secrets / OIDC access

20. Allowed Actions and Reusable Workflows

Repository settings can disable Actions or restrict which actions and reusable workflows may run, subject to organization policy.

Treat third-party Actions as software dependencies.

- uses: vendor/action@v1

This means third-party code executes inside your CI/CD trust boundary.

Prefer:

GitHub-maintained Actions
Organization-maintained reusable workflows
Reviewed third-party Actions
Immutable SHA pinning for high-assurance workflows

21. GITHUB_TOKEN Permissions

GitHub Actions can receive a repository-scoped GITHUB_TOKEN.

Strong baseline:

Repository default: Restricted/read-oriented
Workflow: Request only the permission it needs
Code language: JavaScript (javascript)

CI example:

name: CI

on:
  push:
    branches: [main]
  pull_request:

permissions:
  contents: read

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - run: echo "test"
Code language: PHP (php)

A release workflow may need:

permissions:
  contents: write

OIDC-based cloud authentication commonly needs:

permissions:
  contents: read
  id-token: write

id-token: write permits requesting an OIDC token; the cloud trust policy still decides what cloud permissions are granted.

22. Fork Workflows and Runners

Fork pull requests are a trust boundary because an external contributor may control code executed by CI.

Ask:

• Does the workflow receive secrets?
• Is the token write-capable?
• Does it run on a self-hosted runner?
• Does it require approval first?

Runner types

• GitHub-hosted runners
• Repository self-hosted runners
• Organization runners
• Enterprise runners

A self-hosted runner executes repository-controlled code on infrastructure you operate.

Strong rule:

Do not run untrusted public pull-request code on a privileged, persistent self-hosted runner.

Actions baseline

Actions: Enabled when needed
Allowed Actions: Follow approved organization policy
Default GITHUB_TOKEN: Restricted
Workflow permissions: Explicit in YAML
Self-hosted runner: Only when justified
Cloud access: OIDC where practical
Code language: PHP (php)

Module 6 — Environments, Secrets, and Variables

23. What Is a GitHub Environment?

An environment represents a deployment target such as:

development
staging
production

A job can reference it:

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: production
    steps:
      - run: echo "deploying production"
Code language: PHP (php)

Depending on plan and repository visibility, an environment can provide:

• Required reviewers
• Wait timers
• Deployment branch/tag restrictions
• Custom protection rules
• Environment secrets
• Environment variables

24. Production Environment Flow

flowchart TD
    M[Code merged] --> W[Deployment workflow]
    W --> E[production environment]
    E --> A{Protection satisfied?}
    A -- No --> X[Wait / block]
    A -- Yes --> S[Environment secrets available]
    S --> P[Deploy]

Environment protection separates normal CI from production authority.

Useful controls include:

• Required reviewer
• Prevent self-review where supported
• Branch/tag restriction such as main or v*

An approval should represent a real control, not ceremony.

25. Secrets vs Variables

Repository secret:

env:
  API_TOKEN: ${{ secrets.API_TOKEN }}

Environment secret:

• Available only to jobs that reference the environment
• Released only after environment protections pass

For production credentials, environment scope is often better than broad repository scope.

Variable:

- run: echo "Region: ${{ vars.REGION }}"
Code language: PHP (php)

Never use variables as a password/token store.

26. Prefer OIDC for Cloud Credentials

Avoid long-lived cloud credentials when federation is practical.

Instead of:

AWS_ACCESS_KEY_ID -> GitHub secret
AWS_SECRET_ACCESS_KEY -> GitHub secret

Prefer:

GitHub workflow
   -> OIDC token
   -> cloud IAM trust policy
   -> short-lived cloud credential

Benefits:

• No permanent cloud key copied into GitHub
• Short-lived credentials
• Trust can be restricted by repository, branch, environment, or workflow identity

OIDC still requires least-privilege cloud IAM permissions.

Module 7 — Repository Security Essentials

27. Security Controls Mental Model

Dependencies -> Dependabot
Source code  -> Code scanning
Secrets      -> Secret scanning
New pushes   -> Push protection
Changes      -> Rulesets and reviews
Deployment   -> Environments
Code language: PHP (php)

Feature availability depends on plan, visibility, organization policy, and security-product licensing.

28. Dependency Security

The dependency graph helps GitHub understand packages used by the repository.

Dependabot can provide:

• Vulnerability alerts
• Security update pull requests
• Scheduled version update pull requests

Minimal example:

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
Code language: JavaScript (javascript)

Remember:

Dependabot alerts          -> tell you a dependency is vulnerable
Dependabot security update -> can open a remediation PR
Dependabot version update  -> keeps dependencies current on schedule

29. Code Scanning

Code scanning analyzes source code for vulnerabilities and coding errors. GitHub supports CodeQL and compatible SARIF integrations.

Sensible rollout:

1. Enable scanning.
2. Establish a baseline.
3. Fix meaningful existing findings.
4. Focus merge policy on important new findings.
5. Avoid blocking developers on an unexplained flood of legacy alerts.

Security gates work best when teams trust the signal.

30. Secret Scanning and Push Protection

Secret scanning detects supported credentials committed to the repository.

If a real credential is committed, removing the line from the latest commit is not enough; the credential may still exist in history.

Response:

Detect
-> revoke / rotate
-> remove from code/history as appropriate
-> review exposure
-> prevent recurrence
Code language: JavaScript (javascript)

Push protection attempts to stop supported secrets before they enter the repository.

Secret scanning -> detect committed secrets
Push protection -> prevent supported secrets from being introduced
Code language: JavaScript (javascript)

Essential security baseline

• [ ] Dependency visibility enabled/available as appropriate
• [ ] Dependabot alerts enabled where applicable
• [ ] Code scanning enabled where available and useful
• [ ] Secret scanning enabled where available
• [ ] Push protection enabled where available
• [ ] Default branch protected
• [ ] Workflow files protected through review/CODEOWNERS
• [ ] Production protected with environments

Module 8 — High-Risk Lifecycle Settings

31. Danger Zone

Repository Danger Zone actions include:

• Change repository visibility
• Transfer repository
• Archive repository
• Delete repository

Treat them as change-management events, not routine clicks.

32. Visibility Changes

Visibility may be public, private, or internal for eligible enterprise repositories.

A visibility change can affect more than source files, including:

• Fork relationships
• Actions history/exposure
• Security behavior
• Pages or packages
• Stars/watchers
• External access expectations

Safe procedure:

1. Confirm why the change is needed.
2. Review code, issues, PRs, Actions logs/artifacts, and integrations.
3. Review forks, packages, and publishing surfaces.
4. Confirm organization policy permits it.
5. Make the change.
6. Validate access afterward.

Never convert a private repository to public as a casual experiment.

33. Transfer, Archive, and Delete

Transfer

Before transfer, review:

• New owner permissions
• Automation/integrations
• Packages
• Fork relationships
• Secrets/deploy keys
• Organization policies that will change

Archive

Archiving makes a repository read-only while preserving it as reference.

Good for retired or superseded systems.

Delete

Deletion is destructive and can affect source code, issues, PRs, automation references, packages, and integrations.

Recommended lifecycle:

flowchart LR
    A[Active] --> D[Deprecated]
    D --> AR[Archived]
    AR --> X[Deleted only if justified]
Code language: CSS (css)

When practical:

Deprecate -> Archive -> Delete only after review

Module 9 — 10-Minute Hands-On Essentials Lab

34. Scenario

You administer:

acme-engineering/repository-settings-lab

The repository contains a small web service. Your goal is to create a safe baseline without over-engineering it.

35. Lab Step 1 — General and Access

Confirm:

Default branch: main
Issues: Enabled
Actions: Enabled
Squash merge: Enabled
Delete merged head branches: Enabled
Code language: PHP (php)

Then open:

Settings -> Collaborators and teams

Review:

• Who has Admin?
• Which teams have Write/Maintain?
• Are direct grants necessary?
• Are there stale collaborators or mixed roles?

Target model:

payments-dev -> Write
platform     -> Maintain
repo-admins  -> Admin only where necessary

36. Lab Step 2 — CI and Ruleset

Create .github/workflows/ci.yml:

name: CI

on:
  pull_request:
  push:
    branches: [main]

permissions:
  contents: read

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - name: Test
        run: echo "tests passed"
Code language: PHP (php)

Create a branch ruleset targeting main:

Require pull request: Yes
Required approvals: 1 when practical
Required status check: CI/test when stable
Block force push: Yes
Restrict deletion: Yes
Code language: PHP (php)

Test that GitHub explains which condition blocks a merge.

37. Lab Step 3 — Actions and Environment

Open:

Settings -> Actions -> General

Review:

• Allowed Actions/reusable workflows
• Default GITHUB_TOKEN permissions
• Fork workflow policy
• Runner configuration

Then create environment:

production

Where supported, configure:

• Required reviewer
• Prevent self-review
• Deployment branch restriction to main

Add non-sensitive variable:

REGION=ap-northeast-1

Example workflow:

name: Deploy

on:
  workflow_dispatch:

permissions:
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: production
    steps:
      - run: echo "Deploying to ${{ vars.REGION }}"
Code language: PHP (php)

38. Lab Step 4 — Security Review

Identify which controls are available in your repository:

• Dependency graph
• Dependabot alerts
• Dependabot security updates
• Code scanning
• Secret scanning
• Push protection

Do not enable licensed features in a production organization without confirming policy and licensing.

Expected learning outcome

You can explain this chain:

User access
-> repository role
-> pull request
-> ruleset
-> CI authority
-> environment gate
-> security controls

That chain is the core of GitHub Repository Settings administration.

5-Minute Review

39. Ten Rules to Remember

1. Learn the policy hierarchy. Organization and enterprise controls can restrict repository settings.
2. Keep Admin rare. Use Write or Maintain when sufficient.
3. Prefer teams. Direct grants are harder to review and revoke.
4. Protect the default branch. Important changes should flow through PR + review + CI.
5. Prefer rulesets for modern protection. They are visible, targetable, and layerable.
6. Treat workflows as privileged code. They can control tokens, secrets, OIDC, and deployment.
7. Keep GITHUB_TOKEN restrictive. Grant write permissions only where needed.
8. Protect production with environments. Separate CI authority from deployment authority.
9. Use secrets correctly and prefer OIDC for cloud access. Variables are not a credential store.
10. Treat Danger Zone actions as governance events. Visibility, transfer, archive, and delete can have broad side effects.

40. Common Anti-Patterns

41. Troubleshooting Essentials

Universal troubleshooting order:

1. What action is failing?
2. Which repository role does the actor have?
3. Which ruleset/protection applies?
4. Is there a higher-level policy?
5. Is the problem access, rules, Actions, environment, or security?
6. What exact unmet condition does GitHub show?

42. Quick Reference Cheat Sheet

Main settings locations

GitHub navigation changes over time. Learn the capability name and purpose, not only the sidebar position.

Essential CLI

gh auth status
gh repo view "$OWNER/$REPO"
gh api "/repos/$OWNER/$REPO"
gh api --paginate "/repos/$OWNER/$REPO/collaborators"
gh api "/repos/$OWNER/$REPO/actions/permissions"
gh api "/repos/$OWNER/$REPO/rulesets"
gh api "/repos/$OWNER/$REPO/environments"
Code language: JavaScript (javascript)

API access depends on token permissions and repository policy.

43. Knowledge Check

1. Why can an admin be unable to change a repository setting?
2. What is the difference between Write, Maintain, and Admin?
3. Why are teams preferable to repeated direct grants?
4. What can break when the default branch changes?
5. When is squash merge useful?
6. Why protect main?
7. How do rulesets differ from legacy branch protection?
8. Why can multiple protection layers make troubleshooting confusing?
9. Why protect .github/workflows/ with CODEOWNERS/review?
10. What does GITHUB_TOKEN represent?
11. Why make workflow permissions explicit?
12. Why are fork workflows a trust boundary?
13. What is risky about privileged persistent self-hosted runners?
14. What does an environment protect?
15. How do environment secrets differ from repository secrets?
16. Why prefer OIDC to long-lived cloud keys?
17. How do secret scanning and push protection differ?
18. Why is visibility change a governance event?

Fast answers

1. Organization or enterprise policy may be more restrictive.
2. Write supports development, Maintain adds repository operations, Admin provides full repository administration.
3. Teams simplify onboarding, offboarding, review, and ownership.
4. Workflows, rules, deployment policies, docs, and external integrations may still reference the old branch.
5. When the team wants one clean commit per PR.
6. To require controlled review and CI instead of direct unsafe changes.
7. Rulesets provide more flexible targeting, layering, and visibility.
8. All applicable rules can be enforced simultaneously.
9. Workflow changes can change tokens, secrets, OIDC, and deployments.
10. It is the repository-scoped token issued to Actions jobs.
11. So the workflow receives only the authority it needs.
12. External contributors may control code executed by CI.
13. Untrusted code may access host files, credentials, or internal networks.
14. It gates deployment using approvals, ref restrictions, protection rules, secrets, and variables.
15. Environment secrets are available only to jobs using that environment after protections pass.
16. OIDC provides short-lived identity-based credentials instead of stored permanent keys.
17. Secret scanning detects committed secrets; push protection tries to block supported secrets before introduction.
18. It can alter exposure of code, history, automation, forks, and related repository data.

44. What to Learn Next

After this Essentials guide, continue with:

1. Advanced rulesets, tag rules, and push rules
2. Reusable workflows and Actions supply-chain hardening
3. OIDC trust design for AWS/Azure/GCP
4. Self-hosted runner security
5. Webhooks and GitHub Apps
6. Dependabot and dependency review
7. Code scanning/security configurations
8. Release immutability and release-tag governance
9. GitHub Pages
10. Copilot/MCP repository governance where used
11. REST/GraphQL/CLI automation
12. Terraform and Repository-as-Code
13. Organization/enterprise policy architecture

45. Essential Production Baseline

GitHub Repository
|
|-- General
|   |-- Stable identity
|   |-- Deliberate default branch
|   |-- Deliberate merge strategy
|   `-- Only useful features enabled
|
|-- Access
|   |-- Teams preferred
|   |-- Least-privilege roles
|   `-- Admin rare
|
|-- Change protection
|   |-- Ruleset on main
|   |-- Pull request required
|   |-- Review + meaningful CI
|   |-- Force push blocked
|   `-- Sensitive paths owned
|
|-- Actions
|   |-- Approved Actions/workflows
|   |-- Restricted GITHUB_TOKEN
|   |-- Trusted runner boundary
|   `-- OIDC / scoped secrets
|
|-- Environments
|   |-- Production protected
|   |-- Approved refs only
|   `-- Production credentials scoped
|
|-- Security
|   |-- Dependency protection
|   |-- Code scanning where available
|   |-- Secret scanning where available
|   `-- Push protection where available
|
`-- Lifecycle
    |-- Visibility changes reviewed
    |-- Archive before delete when practical
    `-- Destructive actions deliberate
Code language: JavaScript (javascript)

The core principle is:

Access gives authority, rules constrain change, Actions automate authority, environments constrain deployment, security detects risk, and lifecycle controls protect the repository itself.

Selected Official References

• Managing repository settings
• Managing teams and people with access to your repository
• Configuring branches and merges
• About rulesets
• Available rules for rulesets
• Managing GitHub Actions settings for a repository
• Managing environments for deployment
• Managing security and analysis settings
• Quickstart for securing your repository

End of 2-Hour Essentials Tutorial

Recommended training principle: teach the repository operating model first. Students should leave able to answer six questions: Who has access? What protects main? What can workflows do? What protects production? Which security controls are active? What happens if the repository itself is renamed, exposed, archived, or deleted?

Rajesh Kumar

I’m Rajesh Kumar, a DevOps, SRE, DevSecOps, Cloud, and Platform Engineering expert passionate about sharing practical knowledge, real-world experiences, and industry best practices. I have worked at Cotocus and regularly write about technology, travel, investing, health, product reviews, and digital marketing through my various platforms.

I publish technical articles at DevOps School, travel stories at Holiday Landmark, stock market insights at Stocks Mantra, health and fitness guidance at My Medic Plus, product reviews at TrueReviewNow, and SEO and digital marketing strategies at Wizbrand.