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

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

This guide follows a practical progression:

Concept → Why → How → Example → Practice → Real-world use case → Best practices → Troubleshooting

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

1. What Repository Settings Control

Repository settings cover five broad concerns:

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

A useful mental model is:

flowchart TD
    E[Enterprise Policy] --> O[Organization Policy]
    O --> R[Repository Settings]
    R --> B[Branch and Tag Rules]
    R --> A[Actions and Automation]
    R --> S[Security and Quality]
    R --> D[Deployment Environments]
    B --> C[Developer Contribution]
    A --> C
    S --> C
    D --> C

How to read the diagram: repository settings operate inside the boundaries created by enterprise and organization policies. Repository administrators can usually make a setting more restrictive, but they cannot bypass a higher-level restriction unless the higher-level policy explicitly permits it.

1.1 Repository configuration hierarchy

A practical precedence model is:

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

The lower layer cannot reliably be treated as more authoritative than the higher layer. For example, a repository cannot allow an Action that the organization has blocked.

1.2 Repository ownership models

GitHub repositories can be owned by:

A personal account
An organization

Organization repositories support richer access governance, including teams, outside collaborators, organization rulesets, custom repository roles, security managers, and enterprise policy inheritance.

1.3 Repository visibility

Visibility	Who can normally see it	Important note
Public	Anyone	Code, Actions history/logs, and public contribution surface are visible
Private	Explicitly authorized users and permitted organization members	Feature availability depends on plan
Internal	Enterprise members	Available for eligible enterprise-owned organizations

Internal repositories are not simply “private repositories with more users.” They are designed for enterprise-wide discoverability and may grant read access broadly inside the enterprise.

2. Prerequisites and Permissions

Before changing repository settings, identify your role and the policy layer that owns the control.

2.1 Common repository roles

For organization repositories, the standard repository roles are:

Role	Typical use	Can push code?	Administrative capability
Read	Viewers, auditors, non-code contributors	No	Minimal
Triage	Issue and PR coordinators	No	Manage issues/PRs without code write access
Write	Developers	Yes	Normal development operations
Maintain	Project/repository maintainers	Yes	Many management actions without destructive admin powers
Admin	Repository administrators	Yes	Full repository administration, subject to org/enterprise policy

Organizations can also define custom repository roles on eligible plans.

2.2 What you need for this tutorial

Recommended:

A GitHub organization test repository
Admin access to that repository
GitHub CLI installed and authenticated
Git installed locally
Optional: Terraform for GitHub provider examples
Optional: a webhook test endpoint you control
Optional: GitHub Actions enabled
Optional: GitHub Advanced Security / Code Security / Secret Protection / Code Quality entitlements where exercises require them

Authenticate GitHub CLI:

gh auth login

Confirm authentication:

gh auth status

Set reusable shell variables for later examples:

export OWNER="your-org"
export REPO="your-repo"

Verify repository access:

gh repo view "$OWNER/$REPO"

3. Repository Settings Navigation

Open a repository and select Settings. Depending on your plan and enabled products, common areas include:

Settings area	What you manage
General	Name, default branch, releases, merge behavior, features, archives, pushes, issues, danger zone
Collaborators and teams	Direct and team access
Moderation	Interaction and review restrictions
Rulesets	Branch, tag, push, security, quality rules
Custom properties	Organization-defined repository metadata
Branches	Default branch and legacy branch protection rules
Tags	Tag-related controls where exposed
Actions	Actions permissions, workflow permissions, retention, cache, runners
Webhooks	Event delivery to external systems
Copilot	Repository Copilot controls, code review, MCP configuration
Planning	Issue templates and planning-related behavior
Environments	Deployment approvals, branches/tags, secrets, variables
Pages	Static-site publishing
Advanced Security	Dependency, code, and secret security features
Code quality	GitHub Code Quality controls
Deploy keys	Repository-scoped SSH keys
Secrets and variables	Actions, Dependabot, Codespaces, agents where available
GitHub Apps	Apps with repository access
Email notifications	Push notification recipients

Important: GitHub periodically reorganizes settings navigation. Learn the underlying capability, not only the exact sidebar label.

Part I — General Repository Administration

4. Repository Identity

What is it?

Repository identity includes the repository name, owner, URL, description, website, topics, and social preview.

Why does it matter?

Repository identity affects:

Clone URLs
Documentation links
CI/CD references
Package and deployment references
Discovery and search
External documentation
Automation that hard-codes OWNER/REPO

4.1 Rename a repository

Typical UI flow:

Open the repository.
Select Settings.
Under General, locate the repository name.
Enter the new name.
Confirm the rename.
Update integrations that depend on the old path.

GitHub generally redirects old repository web URLs and Git operations, but do not use redirects as a permanent dependency strategy.

Update a local remote after a rename:

git remote set-url origin git@github.com:OWNER/NEW_REPO.git

Verify:

git remote -v

Best practices

Recommended

Use stable, descriptive repository names.
Keep naming conventions consistent across an organization.
Search CI/CD, IaC, docs, badges, deployment systems, and package metadata before renaming.
Update external consumers even when GitHub redirects continue to work.

Avoid

Renaming repositories as a routine cosmetic operation.
Depending indefinitely on old URLs.
Embedding owner/repository names in many unrelated scripts when a variable can be used.

5. Description, Website, Topics, and Social Preview

Repository metadata improves discoverability and gives users immediate context.

Example metadata standard

Field	Example
Repository	`payment-api`
Description	`Payments API for checkout and settlement services`
Website	`https://docs.example.com/payments`
Topics	`payments`, `golang`, `api`, `production`
Custom property	`service-tier=1`
Custom property	`owner=payments-platform`

Use the social preview image when repository links are frequently shared in chat, documentation, or social networks.

6. Template Repository

A template repository provides a reusable starting point for creating new repositories.

When to use it

Use a template when many repositories should start with the same structure:

.github/
  workflows/
  ISSUE_TEMPLATE/
CODEOWNERS
CONTRIBUTING.md
LICENSE
README.md
SECURITY.md
src/
tests/

Typical platform-engineering use cases:

Microservice bootstrap
Terraform module repository
Internal library
Documentation repository
Standardized application repository

Template vs fork

Template	Fork
Creates an independent repository	Preserves fork relationship
No shared commit history required	Shares history/network with upstream
Best for standardized starting structure	Best for contributing or maintaining a derivative

7. Default Branch

The default branch is GitHub’s primary branch for operations such as pull request targets and repository browsing.

Commonly:

main

Change the default branch

Create the target branch if it does not exist.
Open Settings → Branches or the current default-branch control.
Change the default branch.
Review branch protection/rulesets.
Update CI/CD triggers, deployment rules, and external integrations.
Update local clones if the branch was renamed.

After renaming master to main locally:

git branch -m master main
git fetch origin
git branch -u origin/main main
git remote set-head origin -a

What can break?

Workflows triggered only on the old branch
Branch rules targeting the old name
Pages publishing source
Build/deploy systems
Documentation links
Default comparison/base behavior in external systems

8. Releases and Release Immutability

GitHub Releases combine a Git tag, release metadata, notes, and optional binary assets.

8.1 Mutable release risk

Without immutability, changing a release tag or replacing release assets can undermine assumptions about provenance and artifact integrity.

8.2 Release immutability

GitHub now supports release immutability. When enabled, it applies to future releases and is intended to prevent changes to published release tags/assets that would make a release no longer represent a fixed artifact set.

Typical flow:

Open Settings → General.
Locate Releases.
Enable release immutability.
Publish releases only after validation is complete.

Recommended release flow

flowchart LR
    C[Commit] --> T[Create Tag]
    T --> B[Build Artifact]
    B --> S[Sign and Attest]
    S --> R[Publish Release]
    R --> I[Immutable Release]

Best practice

For production software, combine:

Protected release tags or tag rulesets
Release immutability
Artifact attestations where applicable
Pinned dependencies
Reproducible build practices

9. Repository Features

Repositories can expose optional collaboration features such as:

Issues
Wikis
Discussions
Projects integration
Actions

Feature availability can depend on plan and policy.

9.1 Wikis

Use a repository Wiki for repository-specific documentation when you want Git-backed pages managed separately from the primary code tree.

Prefer /docs or a dedicated documentation site when documentation must be versioned with application code, reviewed through pull requests, or published through a docs pipeline.

9.2 Issues

Issues support:

Bugs
Feature requests
Operational work
Tasks
Labels
Assignees
Milestones
Parent/sub-issue relationships where available
Project integration

9.3 Discussions

Use Discussions for conversations that should not immediately become tracked work:

Q&A
Design discussion
Community support
Announcements
Ideas

9.4 Projects

GitHub Projects can organize issues, pull requests, and draft items into views and workflows. Repository settings can expose or connect planning surfaces, while most Project configuration itself belongs to the Project rather than the repository.

10. Pull Request Merge Methods

GitHub commonly supports three merge strategies:

Method	Result	Best fit
Merge commit	Preserves branch commits plus merge commit	Teams that value branch history
Squash merge	Combines PR into one commit	Clean main-branch history
Rebase merge	Replays commits linearly	Teams that want individual commits without merge commits

10.1 Merge commit configuration

Repositories can control default merge commit title/message behavior.

10.2 Squash configuration

Repositories can choose how the squash commit title/message is generated from PR title, description, or commits.

10.3 Which should you choose?

A common service repository policy is:

Squash merge: enabled
Merge commit: disabled
Rebase merge: optional

This is not universally best. Libraries or repositories where individual commits carry meaningful history may prefer rebase or merge commits.

11. Pull Request Update Behavior

The repository can allow GitHub to suggest updating a pull request branch when the base branch advances.

This is useful when:

Required status checks must run against recent base changes
Merge requirements require the branch to be current
Teams want fewer manual git merge main operations

Do not confuse “suggest update branch” with a protection rule that requires branches to be up to date before merge.

12. Auto-Merge

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

Typical requirements:

Required reviews complete
Required status checks pass
Required deployments pass
Ruleset/branch-protection conditions satisfied
No unresolved blocking conditions

Use it to reduce waiting after a PR is already approved but still waiting for CI.

13. Automatic Head-Branch Deletion

Automatically deleting head branches after merge reduces stale branch clutter.

Recommended for most short-lived feature-branch workflows.

A deleted branch can often be restored from the merged pull request when GitHub still retains the relationship.

14. Source Archives and Git LFS

GitHub can generate source archives such as ZIP and tarball downloads.

Repositories that use Git LFS can control whether LFS objects are included in generated archives.

Decision

Requirement	Recommendation
Users expect a self-contained archive	Include required LFS objects
LFS assets are large and unnecessary for source review	Exclude them
Release requires deterministic binaries	Prefer explicit release artifacts rather than source archive behavior

15. Push Policy

Repository push policy can limit how many branches and tags are updated in a single push.

This is useful for reducing accidental large-scale ref updates and making unusually broad pushes more visible.

It is not a replacement for rulesets or branch protection.

16. Web Commit Signoff

GitHub can require users making commits through the web interface to sign off commits.

A signoff commonly adds a trailer similar to:

Signed-off-by: Developer Name <developer@example.com>

This is commonly used with Developer Certificate of Origin style contribution policies.

A signoff is not the same as cryptographic commit signing. A Signed-off-by trailer records an attestation statement; a signed commit uses GPG, SSH, or S/MIME verification.

17. Automatic Issue Closing

GitHub can automatically close issues when a linked pull request is merged and closing syntax/relationships are satisfied.

Common closing keywords include forms such as:

Fixes #123
Closes #123
Resolves #123

Repository settings can control whether linked issues are automatically closed when merged PRs complete.

Use explicit references in PR descriptions so issue lifecycle remains easy to audit.

18. Autolink References

Autolinks turn external identifiers into clickable links.

Example:

JIRA-142

can become a link to:

https://jira.example.com/browse/JIRA-142

Use cases

Jira
Zendesk
Internal change-management tickets
Incident IDs
Customer support references

Best practice

Use a distinctive prefix that does not collide with normal text.

Part II — Danger Zone and Repository Lifecycle Actions

19. Change Repository Visibility

Visibility changes can have major side effects.

Important consequences

Depending on the direction of the change, GitHub may change or remove:

Stars and watchers
Fork network relationships
Push rulesets
Pages behavior
Code scanning availability
Dependabot custom rules
Actions log visibility

For example, changing a private or internal repository to public exposes the code and Actions history/logs publicly and disables push rulesets that are limited to private/internal fork networks.

Safe change procedure

Inventory forks.
Inventory Pages/custom domains.
Review Actions logs for sensitive information.
Review security feature licensing impact.
Review organization/enterprise policy.
Communicate the change.
Change visibility.
Re-validate security controls.

20. Transfer a Repository

A repository can be transferred to another eligible user or organization.

Transferred content generally includes important repository resources such as:

Git history
Issues
Pull requests
Wiki
Releases
Stars/watchers
Webhooks
Secrets
Deploy keys

Package behavior can vary by package registry and permission model, so validate package ownership separately.

Transfer checklist

[ ] Destination allows repository creation/transfer
[ ] No destination name conflict
[ ] Teams/access model reviewed
[ ] Organization default permissions reviewed
[ ] Apps/integrations reviewed
[ ] Packages reviewed
[ ] Actions/reusable workflow access reviewed
[ ] Secrets and environment policies reviewed
[ ] External webhooks and allowlists reviewed

21. Archive a Repository

Archiving makes a repository read-only and signals that active maintenance has ended.

Before archiving:

Close or document open issues and pull requests.
Add a deprecation or successor notice to the README.
Disable or retire external automation where appropriate.
Document ownership.
Confirm downstream consumers have migrated.
Archive the repository.

Archived content becomes read-only. Secret scanning availability for archived repositories depends on enabled security products.

22. Delete and Restore a Repository

Deletion is destructive. Organization/enterprise policy can restrict who may delete repositories.

Key behavior

Deleting a private/internal repository deletes its forks.
Deleting a public repository does not necessarily delete public forks.
Team permissions are permanently deleted with the repository.
Some deleted repositories can be restored within 90 days.
Restoration has limitations for non-empty fork networks.

Production deletion checklist

[ ] Business owner approval
[ ] Repository archived/exported if required
[ ] Packages checked
[ ] Releases/artifacts backed up if required
[ ] Secrets revoked
[ ] Deploy keys revoked
[ ] Webhooks disabled
[ ] CI/CD dependencies mapped
[ ] Downstream code dependencies mapped
[ ] Fork impact reviewed
[ ] Retention/compliance requirement reviewed

Part III — Access Management and Moderation

23. Repository Access Model

Organization repositories may receive access from several paths:

flowchart TD
    U[User] --> D[Direct Repository Access]
    U --> T[Team Membership]
    T --> R[Repository Role]
    U --> O[Organization Base Permission]
    O --> R
    D --> R

A user can therefore have multiple routes to the same repository. Always troubleshoot effective access, not just direct access.

23.1 Direct access

Direct access is useful for exceptional cases but becomes hard to govern at scale.

23.2 Team access

Preferred for stable organizational access:

Team: payments-developers → Write
Team: payments-maintainers → Maintain
Team: security-reviewers → Read
Team: platform-admins → Admin

23.3 Outside collaborators

Outside collaborators can be granted repository access without organization membership. Treat them as a distinct lifecycle:

Sponsor required
Explicit expiration/review
Least privilege
2FA/identity requirements according to organization policy

24. Access Review Procedure

At least periodically:

Open Settings → Collaborators and teams.
Export or record people and teams with access where supported.
Identify direct collaborators.
Identify outside collaborators.
Check inherited/base access.
Validate team ownership.
Reduce over-privileged roles.
Remove stale access.

Access review table

Actor	Access source	Current role	Needed role	Action
`payments-dev`	Team	Write	Write	Keep
`alice`	Direct	Admin	Maintain	Reduce
`vendor-user`	Outside collaborator	Write	Read	Reduce

25. Moderation and Interaction Limits

Public repositories may need controls against spam or contribution floods.

GitHub interaction limits can temporarily restrict users based on categories such as:

Newer/existing-user status
Prior contribution history
Collaborator status

Common durations include temporary windows from one day through several months.

Current GitHub also supports controls that can limit the number of concurrent open pull requests from users without write access, with bypasses for trusted contributors.

When to use moderation controls

Spam wave
Coordinated abuse
Event-driven contribution spike
CI exhaustion caused by excessive PR creation

Avoid

Do not keep emergency interaction limits enabled forever without review. Long-lived governance should be handled with contribution policy, access controls, automation, and moderation processes.

26. Pull Request Review Restrictions

For applicable public-repository workflows, GitHub can restrict who may approve or request changes on pull requests.

Use this when review actions must come from trusted collaborators rather than any external participant.

Part IV — Rulesets, Branches, and Tags

27. Rulesets Fundamentals

Rulesets are GitHub’s modern policy mechanism for branches, tags, and pushes.

Rulesets improve on legacy branch protection in several ways:

Multiple rulesets can apply simultaneously.
Rules are aggregated.
Read users can inspect applicable active rules.
Organization-level rulesets can target multiple repositories.
Push rulesets can protect an entire private/internal fork network.
Rule insights can show pass, fail, and bypass activity.
Evaluate mode can test rules without blocking contributors where supported.

27.1 Ruleset targets

Ruleset type	Protects
Branch ruleset	Selected branches
Tag ruleset	Selected tags
Push ruleset	Push content across a private/internal repository fork network

27.2 Enforcement states

Common states are:

Active — enforce now
Evaluate — observe would-pass/would-fail behavior where available
Disabled — neither enforce nor evaluate

Availability of Evaluate can depend on ownership/plan.

28. Ruleset Targeting

Branch and tag rulesets support include/exclude targeting and pattern matching.

Examples:

main
release/*
releases/**/*
v*

GitHub uses fnmatch semantics for relevant branch/tag targeting controls.

Example policy

Include: default branch
Include: release/*
Exclude: release/sandbox/*

Keep patterns understandable. A policy nobody can reason about is difficult to audit.

29. Ruleset Bypass

A ruleset can grant bypass capability to eligible actors such as:

Repository admins / organization or enterprise owners where eligible
Selected repository roles
Teams
GitHub Apps
Dependabot in supported cases

GitHub can also support a pull-request-only bypass mode, which permits a trusted actor to bypass certain rules through PR flow without granting unrestricted direct push behavior.

Best practice

Treat bypass as break-glass access:

Small bypass group
        +
Auditable reason
        +
Rule Insights review
        +
Periodic access review

30. Branch and Tag Rules

Available rules vary, but important controls include:

Restrict creations
Restrict updates
Restrict deletions
Require pull requests before merging
Require approvals
Require code-owner review
Require status checks
Require deployments
Require conversation resolution as part of applicable PR rules
Require signed commits
Require linear history
Block force pushes
Require code scanning results
Require secret scanning resolution
Require Code Quality results
Restrict code coverage

Production default-branch baseline

A reasonable starting baseline for many teams is:

Target: default branch
Require pull request: yes
Required approvals: 1 or 2 based on risk
Require code owners: for sensitive paths
Dismiss stale approvals: based on risk
Require status checks: build + test + security
Require conversation resolution: yes
Block force push: yes
Restrict deletion: yes
Require signed commits: optional based on identity model
Require deployments: only when merge policy depends on staged validation

Do not blindly apply every control. Every requirement adds friction and should map to a real risk.

31. Push Rules

Push rulesets can block pushes based on content such as:

File paths
File path length
File extensions
File size

They apply to private/internal repositories and their fork networks where the feature is available.

Example uses

Block accidental binaries:

*.exe
*.dll
*.iso

Block sensitive local configuration:

.env
secrets/**

Protect CI definitions from broad unreviewed changes by combining path rules with branch/PR governance rather than relying on a single control.

32. Security and Quality Rules

Rulesets can make security/quality analysis part of merge governance.

32.1 Require code scanning results

Use when a required scanner such as CodeQL must complete and stay below a configured severity threshold.

32.2 Require secret scanning alerts resolved

Use to stop merging when relevant newly introduced secrets remain unresolved.

32.3 Require Code Quality results

Use to block pull requests when GitHub Code Quality exceeds a selected severity threshold.

32.4 Restrict code coverage

Use when coverage is collected and a defined coverage rule should be enforced.

33. Ruleset Administration

Typical lifecycle:

flowchart LR
    D[Design Rule] --> E[Evaluate]
    E --> I[Inspect Insights]
    I --> T[Tune Rule]
    T --> A[Activate]
    A --> M[Monitor Bypasses]

Recommended rollout

Document desired policy.
Create ruleset.
Use Evaluate mode where supported.
Review rule insights.
Fix workflows or unnecessary blockers.
Activate.
Review bypass and failure trends.

Rulesets can also be imported/exported and managed via REST/GraphQL APIs.

34. Custom Properties

Custom properties are organization-defined structured metadata attached to repositories.

Supported property types include:

Text
True/false
Single select
Multi select

Useful property schema

Property	Type	Example
`owner_team`	Single select	`payments`
`service_tier`	Single select	`tier-1`
`production`	Boolean	`true`
`data_classification`	Single select	`confidential`
`lifecycle`	Single select	`active`
`technology`	Multi select	`go`, `postgres`

Why properties matter

They can support:

Repository discovery
Ruleset targeting
Governance
Automation
Ownership reporting
Compliance inventory

A mature organization should prefer structured properties over encoding all metadata in repository names.

35. Branch Administration

Typical branch operations include:

Rename
Delete
Restore
Change default branch
View protection/rules

Branch naming example

feature/ABC-123-add-tax-rule
bugfix/ABC-456-fix-rounding
release/2026.09
hotfix/ABC-999-payment-timeout

Branch naming conventions should support humans and automation without becoming unnecessarily rigid.

36. Legacy Branch Protection vs Rulesets

Legacy branch protection remains supported, but rulesets provide a more composable governance model.

Branch protection	Rulesets
Only one matching branch-protection rule ultimately applies	Multiple rulesets can apply together
Older policy model	Newer policy model
Repository-focused	Repository and organization governance
Limited aggregate visibility	Better rule visibility and insights
No push-content ruleset model	Push rulesets available where eligible

GitHub provides conversion flows from branch protection to rulesets.

Migration approach

Identify existing branch protection.
Convert to ruleset.
Use Evaluate mode if available.
Compare behavior.
Delete the old protection only after validation.

Be aware that not every legacy setting maps one-to-one in every scenario.

37. Tags and Tag Rulesets

Tags frequently represent release boundaries, so tag mutation should be treated as a supply-chain concern.

A tag ruleset can restrict:

Tag creation
Tag updates
Tag deletion
Matching tag patterns

Example:

v*
release-*
prod-*

For production release tags, combine tag governance with release immutability.

Part V — GitHub Actions Repository Settings

38. Actions Permissions

Repository Actions settings control whether workflows can run and which Actions or reusable workflows they may call.

Common policy choices include:

Disable Actions entirely
Allow all actions and reusable workflows
Allow actions/reusable workflows owned by your organization
Allow selected actions/reusable workflows
Allow GitHub-owned actions
Allow verified Marketplace creators where policy permits

Higher-level organization or enterprise policy can restrict these options.

Why this matters

Every third-party Action is code executed inside your CI/CD trust boundary. Treat it like a software dependency.

Recommended model

Enterprise baseline
        ↓
Organization allowlist
        ↓
Repository-specific narrowing
        ↓
Workflow-level least privilege

Example allowlist philosophy

Allow:
- actions/checkout pinned to a trusted version or SHA
- actions/setup-node pinned
- actions/cache pinned
- organization-owned reusable workflows

Review before allowing:
- Unverified third-party actions
- Actions with broad token permissions
- Actions that download/execute remote scripts

39. Workflow Permissions and `GITHUB_TOKEN`

Every GitHub Actions job can receive a repository-scoped GITHUB_TOKEN.

Repository settings provide a default permission model, commonly either:

Restricted read access
Read/write access

Workflow YAML can then further reduce permissions.

Recommended pattern

Set a restrictive repository default, then grant only what a workflow requires.

name: CI

on:
  pull_request:
  push:
    branches:
      - main

permissions:
  contents: read

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - run: echo "Run tests here"

A release workflow may need more:

permissions:
  contents: write
  id-token: write

id-token: write is commonly used for OIDC federation to cloud providers. It does not by itself grant cloud permissions; the cloud trust policy decides what the issued identity may do.

Pull request creation/approval

Repository settings can also control whether GitHub Actions is allowed to create and approve pull requests with GITHUB_TOKEN.

Keep this disabled unless automation genuinely requires it.

40. Fork Pull Request Workflows

Workflows triggered from forks are a special security boundary because the contributor may control code executed by the workflow.

Key questions:

Does the workflow receive a write-capable token?
Are repository secrets available?
Does a maintainer need to approve the run?
Is the event pull_request or pull_request_target?

Safe principle

Treat code from an untrusted fork as untrusted input.

Never expose production credentials simply because a pull request needs CI.

41. Private Actions and Reusable Workflow Access

A private repository can contain:

Composite/Docker/JavaScript Actions
Reusable workflows

Repository settings can control whether other repositories in the same user/organization context can access them.

Real-world pattern

platform-workflows
  .github/workflows/build.yml
  .github/workflows/deploy.yml

service-a
  calls platform-workflows/build.yml

service-b
  calls platform-workflows/build.yml

Central reusable workflows reduce policy drift but create a shared dependency. Protect the reusable-workflow repository with stronger change control than an ordinary application repository.

42. Workflow, Check, Status, Artifact, and Log Retention

GitHub lets repository administrators configure retention for workflow-related data subject to organization/enterprise maximums.

Current September 2026 note

GitHub documentation states that beginning October 1, 2026, configured retention policies will also apply to checks, workflow runs, and commit statuses. Until that date, those objects may be retained for 400+ days even when a shorter retention setting is configured. Artifacts and logs already follow the configured retention behavior.

Typical configured ranges:

Repository type	Configurable retention
Public	1–90 days
Private/internal	1–400 days

The default is commonly 90 days, subject to higher-level policy.

Choosing retention

Repository	Example policy
Public OSS	30–90 days
Standard internal app	30–90 days
Regulated release pipeline	Align with audit evidence requirement
High-volume test repository	Shorter if compliance allows

Do not use Actions retention as your only long-term audit archive when legal or regulatory evidence must be preserved independently.

43. Actions Cache Settings

GitHub can configure repository cache retention and a total cache size eviction limit.

Current documented defaults include:

Cache retention: 7 days
Total cache size limit: 10 GB

For eligible plans, administrators can raise limits within GitHub and organization maximums. GitHub documentation currently describes up to 90 days for public repositories and 365 days for private/internal repositories, with repository cache-size limits up to higher account-specific maximums.

Cache is not artifact storage

Cache	Artifact
Speeds future workflow runs	Preserves workflow output
Eviction expected	Retained for configured evidence/output period
Key-based retrieval	Run-associated download
Should be reproducible	May contain release/test evidence

44. Repository Runners

A repository can use:

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

Repository-scoped self-hosted runner

Use only when the runner should be dedicated to one repository.

Organization runner

Prefer when multiple repositories need the same controlled execution environment.

Security rule

A self-hosted runner executes repository-controlled workflow code on infrastructure you operate. Protect it accordingly.

Recommended

Ephemeral runners for untrusted or high-risk workloads
Network segmentation
Minimal credentials
Short-lived OIDC credentials
Patch automation
Runner groups for scope control

Avoid

Long-lived cloud keys on the host
Shared production network access for arbitrary PR jobs
Reusing a dirty workspace for unrelated security domains

Part VI — Webhooks

45. Repository Webhooks

Webhooks send HTTP requests to external services when selected GitHub events occur.

Core settings

Payload URL
Content type
Secret
SSL verification
Event subscriptions
Active/inactive state

Typical events

push
pull_request
issues
release
deployment
workflow-related events
package events
repository events
security events where supported

Architecture

flowchart LR
    G[GitHub Event] --> W[Webhook Delivery]
    W --> A[Receiver API]
    A --> V[Verify Signature]
    V --> Q[Queue or Worker]
    Q --> B[Business Logic]

Do not perform expensive processing before validating the request.

46. Webhook Security

Use HTTPS and configure a strong webhook secret.

GitHub signs webhook payloads. The receiver should verify the signature from the X-Hub-Signature-256 header using HMAC SHA-256.

Python verification example

import hashlib
import hmac


def valid_signature(secret: bytes, body: bytes, header: str) -> bool:
    expected = "sha256=" + hmac.new(
        secret,
        body,
        hashlib.sha256,
    ).hexdigest()

    return hmac.compare_digest(expected, header)

Important controls

Verify the signature before parsing trusted fields.
Use constant-time comparison.
Keep the webhook secret out of source code.
Reject unexpected content types.
Consider idempotency/replay handling.
Log the GitHub delivery ID for troubleshooting.

47. Webhook Delivery Operations

GitHub provides delivery history that can show:

Request headers
Request payload
Response status
Response body
Delivery duration
Redelivery controls
Ping/test deliveries

Troubleshooting flow

flowchart TD
    F[Webhook Failed] --> D[Open Delivery]
    D --> S{HTTP Status}
    S -->|2xx| L[Inspect Receiver Logic]
    S -->|4xx| A[Check Auth or Payload]
    S -->|5xx| E[Check Server Error]
    S -->|Timeout| N[Check Network and Latency]

Part VII — Copilot Repository Settings

48. Copilot Repository Controls

Copilot repository settings are increasingly important because GitHub now supports repository-level behavior for code review and cloud agents.

Availability depends on:

Copilot plan
Organization/enterprise policy
Feature rollout
Repository eligibility

49. Copilot Code Review

Copilot code review can review pull requests and use repository-specific instructions.

Repository admins can control whether custom instructions are used for Copilot reviews.

Repository-wide instruction file

.github/copilot-instructions.md

Example:

# Repository review instructions

- Prefer small, backward-compatible changes.
- Flag SQL queries that do not use parameter binding.
- Require unit tests for new business logic.
- Do not suggest changing public API behavior without documenting migration impact.

Path-specific instructions

GitHub supports path-specific instruction files under patterns such as:

.github/instructions/*.instructions.md

Use these when different areas of a monorepo need different standards.

Agent instruction files

GitHub Copilot features can also consume agent-oriented repository context such as AGENTS.md, depending on the Copilot experience being used.

The source syllabus also lists CLAUDE.md and GEMINI.md; these are agent/tool-specific files rather than universal GitHub repository settings. Do not assume every GitHub Copilot surface consumes every third-party agent file. Verify support for the exact Copilot feature before standardizing around them.

50. Copilot MCP Servers

GitHub supports repository-level Model Context Protocol configuration for Copilot cloud agent and Copilot code review.

What MCP does

MCP allows Copilot to call approved tools exposed by configured MCP servers.

Examples:

Internal documentation search
Issue tracker lookup
Service catalog lookup
Test tools
Incident context

Security warning

Configured MCP tools can be invoked autonomously by supported Copilot agents. Treat an MCP server as privileged integration code.

Recommended

Allowlist specific tools
Prefer read-only tools for review use cases
Scope secrets narrowly
Validate tool output
Avoid broad filesystem/network access

GitHub currently documents built-in GitHub and Playwright MCP integrations in this area, and repository MCP configuration can be shared between Copilot cloud agent and code review.

Current limitation to understand

Support differs by Copilot surface. For example, code review applies safety constraints to tools and expects read-only semantics for supported MCP review tools.

51. Copilot Cloud Agent / Coding Agent

Repository configuration for cloud agents may include:

Repository access
Development environment setup
Agent instructions
Agent secrets
Agent variables
MCP configuration
Pull request creation behavior

Safe agent design

Read code
   ↓
Understand instructions
   ↓
Create isolated change
   ↓
Run tests
   ↓
Open pull request
   ↓
Human review + repository rules

Do not bypass branch governance just because a change was created by an AI agent.

Part VIII — Planning and Issue Configuration

52. Issue Templates

Issue templates improve input quality and reduce repeated clarification.

Markdown template example

---
name: Bug report
about: Report a reproducible defect
labels: bug
---

## What happened?

## Expected behavior

## Steps to reproduce

1.
2.
3.

## Environment

## Logs or screenshots

53. Issue Forms

Issue Forms provide structured YAML-driven input.

Example:

name: Bug report
description: Report a reproducible product defect
title: "[Bug]: "
labels:
  - bug
body:
  - type: markdown
    attributes:
      value: "Thanks for helping us improve the project."

  - type: textarea
    id: description
    attributes:
      label: What happened?
      description: Describe the problem.
    validations:
      required: true

  - type: input
    id: version
    attributes:
      label: Version
      placeholder: "v2.3.1"
    validations:
      required: true

  - type: dropdown
    id: environment
    attributes:
      label: Environment
      options:
        - Development
        - Staging
        - Production
    validations:
      required: true

Template chooser configuration

Use .github/ISSUE_TEMPLATE/config.yml for options such as blank-issue behavior and external contact links.

54. Issue Metadata

Repository planning commonly uses:

Labels
Assignees
Milestones
Issue types where available
Parent/sub-issue relationships
Project fields

Keep labels small and meaningful

Good:

kind/bug
kind/feature
priority/p1
priority/p2
area/api
area/frontend
status/blocked

Avoid hundreds of overlapping labels that nobody understands.

55. Automatic Planning Behavior

Repositories can connect work through:

Issue → Branch → Pull Request → Review → Merge → Issue closure → Project automation

Use consistent issue/PR relationships so reporting and automation have reliable signals.

Part IX — Deployment Environments

56. What Is a GitHub Environment?

An environment represents a deployment target such as:

development
staging
uat
production

An environment can provide:

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

A job references an environment:

jobs:
  deploy:
    environment: production
    runs-on: ubuntu-latest
    steps:
      - run: echo "Deploy production"

Protection rules are evaluated before the job gets access to the environment’s protected secrets.

57. Required Reviewers

Required reviewers create a human approval gate before deployment.

GitHub documentation currently supports selecting up to six users or teams as reviewers for an environment; only one approval is required for the deployment to proceed unless your broader process adds additional controls.

You can also prevent self-review.

Use case

Deployment initiated by developer
        ↓
Production environment gate
        ↓
SRE or release team approval
        ↓
Environment secrets released to job
        ↓
Deployment runs

58. Wait Timers

A wait timer delays a deployment for a configured period.

Use cases:

Observation window
Change freeze delay
Staged rollout
Manual cancellation opportunity

Current GitHub documentation allows wait timers from 1 minute up to 43,200 minutes (30 days) where the plan supports them.

59. Deployment Branches and Tags

Environment rules can restrict which refs may deploy.

Typical choices include:

No restriction
Protected branches only
Selected branch/tag patterns

Production example

Allowed:
main
v*

Denied:
feature/*

A release process can therefore require both:

Repository rule allows merge/tag operation.
Environment rule allows deployment from the resulting ref.

60. Custom Deployment Protection Rules

GitHub Apps can implement external deployment gates.

Examples:

Change-management ticket approved
Monitoring health acceptable
Security scan passed
Maintenance window open
External release orchestrator approved

This is a powerful extension point for enterprise release governance.

61. Environment Secrets

Environment secrets are only made available to jobs that reference the environment and satisfy its protection requirements.

Example access:

- name: Use deployment credential
  env:
    DEPLOY_TOKEN: ${{ secrets.DEPLOY_TOKEN }}
  run: ./deploy.sh

Prefer OIDC for cloud authentication where possible so long-lived cloud keys do not need to be stored as environment secrets.

62. Environment Variables

Environment variables are non-secret configuration values exposed through the vars context.

Example:

- run: echo "Deploying to ${{ vars.REGION }}"

Good uses:

Region
Environment name
Feature toggle defaults
Non-sensitive endpoint names

Do not place credentials in variables.

Part X — GitHub Pages

63. GitHub Pages

GitHub Pages publishes static websites from repository content.

Common uses:

Project documentation
Internal documentation on eligible enterprise configurations
Static product sites
Training material

Publishing methods

Deploy from a branch
Deploy with GitHub Actions

64. Branch Publishing Source

Branch publishing can use:

Repository root /
/docs directory

Example:

main
└── docs/
    ├── index.html
    └── assets/

Use branch publishing when you do not need a custom build pipeline.

65. GitHub Actions Pages Deployment

Use Actions when the site must be built first.

Typical flow:

flowchart LR
    P[Push] --> B[Build Site]
    B --> U[Upload Pages Artifact]
    U --> D[Deploy Pages]
    D --> W[Website]

GitHub’s Pages workflow typically uses a github-pages environment.

66. Custom Domains

A Pages site can use a custom domain.

Common DNS records:

CNAME for a subdomain
A/AAAA or DNS-provider-supported apex configuration for root domains

Critical security practice

Verify the domain and remove stale DNS when a Pages site or repository is retired. Abandoned DNS records can create domain takeover risk.

67. HTTPS

Use HTTPS enforcement when available.

GitHub provisions TLS certificates for supported Pages custom-domain configurations after DNS is correctly configured.

Troubleshoot HTTPS problems by checking:

DNS correctness
CAA restrictions
Existing conflicting records
Domain ownership/verification
Certificate provisioning delay

68. Pages Visibility

Do not assume a Pages site inherits repository visibility.

GitHub Pages behavior depends on plan and enterprise configuration. Public Pages can be internet-accessible even when the source repository is private. Eligible enterprise configurations can support privately published Pages.

Always verify the Pages site’s effective visibility independently from repository visibility.

Part XI — Advanced Security

69. Security and Analysis Overview

Repository security settings can include several distinct products and controls. GitHub’s 2026 terminology increasingly separates capabilities into products such as Code Security and Secret Protection, while the repository navigation still groups many controls under Advanced Security or Security and quality.

Think in layers:

flowchart TD
    D[Dependency Risk] --> DG[Dependency Graph and Dependabot]
    C[Code Risk] --> CS[Code Scanning and AI Scan]
    S[Secret Risk] --> SS[Secret Scanning and Push Protection]
    Q[Quality Risk] --> CQ[Code Quality]
    DG --> G[Merge Governance]
    CS --> G
    SS --> G
    CQ --> G

Do not assume all private repositories receive all advanced features automatically. Availability depends on visibility, plan, and the security products enabled for the organization/enterprise.

70. Dependency Graph

The dependency graph parses supported manifest and lock files to understand direct and transitive dependencies.

Examples include ecosystem files such as:

package.json
package-lock.json
pom.xml
build.gradle
requirements.txt
poetry.lock
Gemfile.lock
go.mod
Cargo.lock

The exact list varies by ecosystem and evolves over time.

Why it matters

The dependency graph is foundational for:

Dependabot alerts
Security updates
Dependency review
Dependency inventory
Supply-chain visibility

71. Dependabot Alerts

Dependabot alerts notify repository maintainers when a dependency is affected by a known vulnerability in GitHub’s advisory data.

Alert workflow

Manifest/lock file
      ↓
Dependency graph
      ↓
Known vulnerable version
      ↓
Dependabot alert
      ↓
Triage / upgrade / dismiss with reason

Best practices

Assign ownership for alerts.
Prioritize exploitable/runtime dependencies over blanket severity-only handling.
Record dismissal reasons.
Keep manifests and lock files committed where appropriate.

72. Dependabot Security Updates

Dependabot security updates can automatically open pull requests that upgrade vulnerable dependencies to a secure version where GitHub can determine an update path.

Use security updates together with normal CI and repository rules. Automation should not bypass tests or review.

73. Dependabot Version Updates

Version updates are configured with:

.github/dependabot.yml

Example:

version: 2
updates:
  - package-ecosystem: npm
    directory: "/"
    schedule:
      interval: weekly
    open-pull-requests-limit: 5

For private registries, use Dependabot-specific credentials rather than assuming Actions repository secrets are available.

74. Dependency Review

Dependency review analyzes dependency changes introduced by a pull request.

Useful checks include:

Newly introduced vulnerable dependency
Version change
License information
Dependency additions/removals

A mature PR policy asks not only “does the code compile?” but also “what new software supply-chain risk does this PR introduce?”

75. Code Scanning

Code scanning identifies potential vulnerabilities and coding errors.

Setup models

GitHub supports:

Default setup — low-maintenance CodeQL configuration
Advanced setup — workflow-driven, highly customizable scanning
Third-party SARIF upload — integrate supported scanners through SARIF

Recommended starting point

Use default setup unless you have a concrete reason to need advanced workflow customization.

SARIF

SARIF is a JSON-based static-analysis result format. GitHub currently supports the relevant subset of SARIF 2.1.0 for code scanning integrations.

Typical third-party flow:

flowchart LR
    C[Code] --> T[Third Party Scanner]
    T --> S[SARIF File]
    S --> G[GitHub Code Scanning]
    G --> A[Alert]

76. CodeQL Default Setup

Default setup is designed to minimize workflow maintenance.

It can scan supported languages on:

Pushes to the default/protected branches
Pull requests targeting relevant protected/default branches
Scheduled analysis according to GitHub behavior

Use the tool-status view when troubleshooting coverage or scan errors.

77. CodeQL Advanced Setup

Use advanced setup when you need capabilities beyond default setup, for example:

Custom build steps
Matrix behavior
More granular triggers
Custom query packs/suites
Complex generated-code handling
External CI orchestration

The tradeoff is more configuration and more long-term maintenance.

78. AI Scan for Pull Requests

As of September 2026, AI Scan for pull requests is in public preview.

Its purpose is to extend security detection to languages and frameworks that CodeQL does not cover well or at all.

Current important characteristics:

Runs on pull requests
Complements CodeQL rather than replacing it
Findings are PR-oriented rather than a full default-branch backlog equivalent
Requires code scanning to be enabled
As of the September 16, 2026 update, it no longer requires CodeQL default setup
Public preview availability currently depends on GitHub Advanced Security eligibility and Copilot licensing/AI-credit conditions described by GitHub
Not supported on GitHub Enterprise Server for this preview release

Treat preview behavior as subject to change.

79. Secret Scanning

Secret scanning detects credentials and secret-like values committed to supported GitHub surfaces.

Detection can include:

Provider patterns
Non-provider patterns
Custom patterns
Generic AI-assisted detection where available

Response lifecycle

Secret detected
    ↓
Determine validity
    ↓
Revoke / rotate credential
    ↓
Remove exposure if appropriate
    ↓
Close alert with reason

Removing a secret from the latest commit is not enough if the credential is still valid. Rotation/revocation is the primary response.

80. Push Protection

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

A contributor may be blocked when GitHub detects a secret in the push.

Organizations can define bypass workflows and, in some configurations, review bypass requests or exempt trusted actors.

Best practice

Keep bypass narrow and auditable. If a secret must be bypassed because it is a false positive, document the reason rather than teaching developers to bypass every block.

Part XII — GitHub Code Quality

81. What Is GitHub Code Quality?

GitHub Code Quality is a repository/organization feature that analyzes code for quality concerns such as maintainability and reliability and integrates findings into pull request and default-branch workflows.

As of September 2026, GitHub documents Code Quality for GitHub Team and GitHub Enterprise Cloud customers, subject to enterprise enablement and billing/licensing conditions.

GitHub’s current implementation combines deterministic CodeQL quality queries with AI-powered analysis in supported scenarios.

82. Enabling Code Quality

Typical repository flow:

Open Settings.
Open Code quality under the security/quality area.
Enable Code Quality.
Select supported languages if exposed.
Choose runner type if required.
Save.

GitHub Actions must be enabled because Code Quality analysis uses Actions execution.

83. Code Quality Pull Request Controls

Code Quality can feed rulesets.

A branch ruleset can enable Require code quality results and define the lowest result severity that must be resolved before merge.

Rollout model

Enable Code Quality
      ↓
Observe findings
      ↓
Tune team workflow
      ↓
Ruleset in Evaluate mode
      ↓
Set quality threshold
      ↓
Activate merge protection

Do not turn on a strict blocking threshold across hundreds of repositories before measuring the baseline.

84. Code Coverage

GitHub Code Quality can integrate code coverage into the repository quality experience and ruleset governance.

Use coverage to answer:

Which changed code is untested?
Is coverage decreasing?
Should a pull request be blocked below a defined threshold?

Coverage percentage is a signal, not proof of test quality. High coverage with weak assertions can still provide poor protection.

Part XIII — Deploy Keys, Secrets, and Variables

85. Deploy Keys

A deploy key is an SSH public key attached directly to one repository.

The corresponding private key normally lives on a machine or deployment system.

Deploy keys can be:

Read-only
Write-enabled

Common use case

A legacy deployment server needs to clone one private repository without acting as a human user.

Security characteristics

Advantages

Repository-scoped
Simple SSH model
No user account required for the key itself

Risks

Private key may be long-lived
Rotation is manual
Write access can be dangerous
Poor fit for dynamic multi-repository automation

Prefer GitHub Apps or OIDC-capable automation when you need scalable, short-lived, centrally governable authentication.

86. Deploy Key Rotation

Recommended procedure:

Generate a new SSH key pair.
Install the new public key as a deploy key.
Update the consumer with the new private key.
Verify access.
Remove the old deploy key.
Destroy the old private key.
Record rotation evidence.

Example key generation:

ssh-keygen -t ed25519 -C "deploy-payment-api" -f ./payment-api-deploy

Protect the private key with appropriate host and secret-management controls.

87. Actions Repository Secrets

Repository secrets are encrypted values intended for workflow use.

Create with GitHub CLI:

gh secret set API_TOKEN --repo "$OWNER/$REPO"

List secret names:

gh secret list --repo "$OWNER/$REPO"

GitHub does not return secret plaintext after storage.

Best practice

Use secret scope deliberately:

Scope	Use
Organization	Shared secret across selected repositories
Repository	Secret applies to whole repository
Environment	Secret only for a deployment environment

Prefer the narrowest practical scope.

88. Actions Variables

Variables are for non-sensitive configuration.

Create:

gh variable set REGION --body "ap-northeast-1" --repo "$OWNER/$REPO"

Use in workflow:

- run: echo "Region is ${{ vars.REGION }}"

Never rely on a variable being masked as a secret.

89. Dependabot Secrets

Dependabot uses its own secret store for authentication to private package registries and related update operations.

This separation matters because Dependabot-triggered workflows do not automatically receive normal Actions secrets in the same way as trusted Actions events.

90. Codespaces Secrets

Codespaces can use repository/user/organization scoped secrets for development environments.

Use them for development-time credentials that should not be committed to the repository.

Do not turn Codespaces secrets into a substitute for production deployment credential management.

91. Copilot / Agent Secrets and Variables

GitHub’s current repository settings may expose secrets and variables for cloud agents and MCP-related use cases.

Treat these credentials as privileged automation credentials:

Scope them to the smallest system surface
Prefer read-only access where practical
Rotate them
Avoid sharing production credentials with agent tooling unless the use case is explicitly designed and reviewed for it

92. OIDC Instead of Long-Lived Cloud Secrets

For cloud deployments, prefer OpenID Connect where the cloud provider supports it.

Workflow:

flowchart LR
    W[GitHub Workflow] --> O[OIDC Token]
    O --> C[Cloud Identity Provider]
    C --> R[Short Lived Role]
    R --> D[Deploy]

Minimal permission block:

permissions:
  contents: read
  id-token: write

Then constrain the cloud trust policy by repository, branch, environment, or other supported claims.

Part XIV — GitHub Apps and Email Notifications

93. Installed GitHub Apps

A GitHub App can be installed on an account and granted access to:

All repositories
Selected repositories

The app receives only the repository and organization permissions it requests and the installation grants.

Repository settings can show Apps that currently have access to the repository, but changing an installation may redirect you to the owning account’s app installation configuration because app access is managed at installation scope.

Review checklist

[ ] Is this app still needed?
[ ] Does it need all repositories?
[ ] Are requested permissions justified?
[ ] Can write/admin permissions be reduced?
[ ] Is the publisher trusted?
[ ] Is there an owner for the integration?

94. GitHub App Permissions

Repository permissions can cover areas such as:

Contents
Issues
Pull requests
Actions
Checks
Deployments
Environments
Metadata
Security events

The exact permission set evolves. Review the app’s requested permissions at installation time and during periodic audits.

GitHub App vs PAT

GitHub App	Personal access token
App identity	User identity
Installation-scoped	User/account-scoped
Fine-grained permissions	Depends on token type
Short-lived installation tokens	PAT often longer-lived
Better for platform integrations	Useful for user-driven tooling

For service automation, GitHub Apps are generally easier to govern at scale than a shared human PAT.

95. Push Email Notifications

Repository administrators can configure email notifications for pushes.

Current GitHub documentation supports up to two destination addresses directly. A group mailbox can be used when more recipients are needed.

Push emails include useful metadata such as:

Repository
Branch
Commit SHA
Author
Commit message
Changed files/diff links

GitHub also supports an approved header value that a receiving system can use as an additional trust signal.

Part XV — Policy Inheritance and Governance Architecture

96. Organization Policy Overrides

Organization-level controls can affect repository behavior for areas including:

Actions
Rulesets
Security configurations
Custom properties
Base repository permissions
Copilot policy
GitHub App policy
Repository visibility and lifecycle operations

A repository admin may therefore encounter a locked setting with an explanation that organization policy controls it.

97. Enterprise Policy Overrides

Enterprise controls can add another policy layer for:

Actions
Identity
Repository visibility
Security products
Network controls
Apps/integrations
Copilot

Troubleshooting rule

When a repository setting appears impossible to change, inspect policy from the top down:

Enterprise → Organization → Repository → Environment → Workflow

98. Repository Governance Architecture

A scalable repository model separates concerns:

flowchart TD
    I[Identity and Access] --> R[Repository]
    P[Policy and Rulesets] --> R
    S[Security Configuration] --> R
    A[Actions Standards] --> R
    R --> C[Code Change]
    C --> T[Tests and Scans]
    T --> M[Merge]
    M --> E[Environment Gate]
    E --> D[Deployment]

Access model

Prefer:

Organization membership
      ↓
Team membership
      ↓
Repository role

Use direct collaborators as exceptions, not the normal architecture.

Security model

Layer:

Rulesets
CODEOWNERS
Required checks
Code scanning
Secret scanning
Push protection
Code Quality
Protected environments
Deployment approvals

No single control replaces the others.

99. CI/CD Governance Model

A strong repository pipeline uses multiple enforcement points:

Action allowlist
      ↓
Minimal GITHUB_TOKEN
      ↓
Pinned dependencies/actions
      ↓
Protected default branch
      ↓
Required CI checks
      ↓
OIDC authentication
      ↓
Protected environment
      ↓
Deployment approval

Supply-chain baseline

Pin critical third-party Actions to immutable commits where practical.
Review action source and maintainer trust.
Prefer organization-owned reusable workflows.
Use artifact attestations/provenance where appropriate.
Protect workflow files through CODEOWNERS and rules.

Part XVI — Repository APIs and CLI Administration

100. REST API Fundamentals

GitHub’s REST API is versioned. As of this guide, current documentation examples use:

X-GitHub-Api-Version: 2026-03-10

When using gh api, GitHub CLI handles authentication for you.

Read repository configuration

gh api \
  -H "X-GitHub-Api-Version: 2026-03-10" \
  "/repos/$OWNER/$REPO"

Extract selected values:

gh api \
  -H "X-GitHub-Api-Version: 2026-03-10" \
  "/repos/$OWNER/$REPO" \
  --jq '{name,visibility,default_branch,archived,has_issues,has_wiki}'

101. Update Repository Settings with REST

Many General settings are exposed through the repository update endpoint.

Example:

gh api \
  --method PATCH \
  -H "X-GitHub-Api-Version: 2026-03-10" \
  "/repos/$OWNER/$REPO" \
  -f has_wiki=false \
  -f delete_branch_on_merge=true

Before scripting a setting at scale, confirm the current REST field and plan requirements in GitHub’s endpoint documentation.

102. Collaborators API

List collaborators:

gh api \
  -H "X-GitHub-Api-Version: 2026-03-10" \
  "/repos/$OWNER/$REPO/collaborators"

Check a specific user’s permission with the appropriate collaborators-permission endpoint when building access audits.

For organization repositories, remember that direct-collaborator data is only part of the effective-access picture; teams and base permissions matter too.

103. Rulesets API

List repository rulesets:

gh api \
  -H "X-GitHub-Api-Version: 2026-03-10" \
  "/repos/$OWNER/$REPO/rulesets"

Use API automation for:

Repository bootstrap
Policy drift detection
Ruleset inventory
Migration reporting
Rule insights/rule suite analysis

Keep desired-state policy in version control rather than constructing large JSON bodies manually in shell history.

104. Actions Administration API

Repository Actions APIs can manage or inspect areas such as:

Actions permissions
Workflow permissions
Runners
Caches
Artifacts
Secrets metadata
Variables

Example: inspect repository Actions permissions:

gh api \
  -H "X-GitHub-Api-Version: 2026-03-10" \
  "/repos/$OWNER/$REPO/actions/permissions"

105. Environment API

REST endpoints support creating/configuring deployment environments and associated protection/deployment policies.

Use APIs when environments must be standardized across many repositories.

Typical desired state:

{
  "environment": "production",
  "prevent_self_review": true,
  "allowed_refs": ["main", "v*"]
}

The JSON above is conceptual; use the current GitHub REST schema for actual API requests because reviewer and deployment-policy payloads have specific endpoint structures.

106. Webhooks API

Repository webhook APIs support:

Create
Update
Delete
List hooks
Inspect deliveries
Redeliver supported deliveries

Automating webhooks is useful when every service repository must integrate with the same platform system.

107. AI Scan API

As of September 2026, GitHub has public-preview REST endpoints to inspect and update AI Scan enablement at organization and repository scope.

Example read path documented by GitHub:

/repos/{owner}/{repo}/code-scanning/ai-scan

Because this endpoint is preview functionality, verify the current API contract immediately before production automation.

108. GitHub CLI Administration

Useful command families include:

gh repo view
gh repo edit
gh repo archive
gh repo delete
gh secret list
gh secret set
gh variable list
gh variable set
gh api

Example repository edit

gh repo edit "$OWNER/$REPO" --delete-branch-on-merge

Use gh api when a setting is not exposed by a first-class CLI subcommand.

109. GraphQL Administration

GitHub GraphQL is useful for querying connected repository metadata in fewer round trips.

Typical uses:

Repository inventory
Branch protection data
Collaborator/permission relationships
Deployments
Projects
Security-related reporting where fields are exposed

GraphQL and REST do not have identical feature coverage. Choose the API that exposes the capability cleanly rather than forcing all automation into one style.

Part XVII — Infrastructure as Code

110. Terraform GitHub Provider

The official community-supported integrations/github Terraform provider can manage many repository controls.

As of September 2026, Terraform Registry shows provider version 6.13.0 as the latest published version in the retrieved provider index. Always verify the current version before pinning.

Common resources include:

github_repository
github_branch_default
github_repository_ruleset
github_team_repository
github_repository_collaborator
github_repository_collaborators
github_actions_repository_permissions
github_actions_secret
github_actions_variable
github_repository_environment
github_repository_environment_deployment_policy
github_actions_environment_secret
github_actions_environment_variable
github_dependabot_secret
github_repository_webhook
github_repository_deploy_key
github_repository_pages

111. Terraform Repository Example

terraform {
  required_providers {
    github = {
      source  = "integrations/github"
      version = "~> 6.13"
    }
  }
}

provider "github" {
  owner = var.github_owner
}

resource "github_repository" "app" {
  name                   = "payment-api"
  description            = "Payment service API"
  visibility             = "private"
  has_issues             = true
  has_wiki               = false
  delete_branch_on_merge = true

  allow_merge_commit = false
  allow_squash_merge = true
  allow_rebase_merge = false
}

Pin a provider range intentionally and review provider release notes before major upgrades.

112. Terraform Actions Permissions

resource "github_actions_repository_permissions" "app" {
  repository      = github_repository.app.name
  enabled         = true
  allowed_actions = "selected"

  allowed_actions_config {
    github_owned_allowed = true
    verified_allowed     = false
    patterns_allowed = [
      "actions/checkout@*",
      "actions/cache@*",
    ]
  }
}

For high-assurance supply-chain policy, consider whether your organization should require SHA pinning instead of broad tag patterns.

113. Terraform Ruleset Example

resource "github_repository_ruleset" "main" {
  name        = "protect-main"
  repository  = github_repository.app.name
  target      = "branch"
  enforcement = "active"

  conditions {
    ref_name {
      include = ["~DEFAULT_BRANCH"]
      exclude = []
    }
  }

  rules {
    deletion                = true
    non_fast_forward        = true
    required_linear_history = true

    pull_request {
      required_approving_review_count = 1
      require_code_owner_review       = true
      required_review_thread_resolution = true
    }
  }
}

Provider schemas evolve. Validate nested rule names against the pinned provider version before applying production configuration.

114. Terraform Environment Example

resource "github_repository_environment" "production" {
  repository  = github_repository.app.name
  environment = "production"

  prevent_self_review = true

  deployment_branch_policy {
    protected_branches     = false
    custom_branch_policies = true
  }
}

resource "github_repository_environment_deployment_policy" "main" {
  repository     = github_repository.app.name
  environment    = github_repository_environment.production.environment
  branch_pattern = "main"
}

115. Terraform Secret Warning

Terraform can manage GitHub secrets, but secret values can still become sensitive Terraform state data depending on how they are provided.

Treat state as a secret-bearing system.

Recommended

Encrypted remote state
Strict state access
Avoid plaintext secrets in .tf files
Prefer external secret injection or encrypted values where practical
Rotate credentials if state exposure occurs

116. Repository as Code

A mature organization can standardize repository provisioning:

Repository request
      ↓
Approved metadata
      ↓
Terraform module
      ↓
Repository + teams
      ↓
Rulesets
      ↓
Actions policy
      ↓
Environments
      ↓
Security configuration
      ↓
Continuous drift check

What belongs in desired state

Name/description/visibility
Topics/custom properties
Teams and permissions
Rulesets
Actions policy
Environments
Webhooks
Pages when applicable
Security configuration where provider/API coverage exists

Not every GitHub feature has immediate Terraform-provider parity. Use APIs only where needed and track the gap explicitly.

Part XVIII — Repository Standardization

117. Repository Templates and Standard Structure

A standardized repository should make common expectations obvious before a developer reads internal documentation.

Example:

.github/
  CODEOWNERS
  ISSUE_TEMPLATE/
  workflows/
  copilot-instructions.md
CODE_OF_CONDUCT.md
CONTRIBUTING.md
LICENSE
README.md
SECURITY.md
src/
tests/

Not every repository needs every file. Use the minimum set that supports the repository’s users and risk profile.

Recommended baseline files

File	Purpose
`README.md`	What the repository is and how to use it
`CONTRIBUTING.md`	Contribution workflow
`SECURITY.md`	Vulnerability reporting policy
`CODEOWNERS`	Review ownership for sensitive paths
`LICENSE`	Reuse/legal terms where appropriate
`.github/ISSUE_TEMPLATE/*`	Structured issue intake
`.github/workflows/*`	CI/CD automation

118. CODEOWNERS

CODEOWNERS maps file paths to responsible reviewers.

Example:

# Default owners
* @example/platform

# Security-sensitive workflows
.github/workflows/ @example/platform-security

# Payments domain
src/payments/ @example/payments-team

# Infrastructure
terraform/ @example/cloud-platform

CODEOWNERS alone does not force a review. Pair it with a branch/ruleset rule that requires code-owner review.

119. Repository Metadata Standards

A platform team should standardize metadata just as it standardizes CI.

Example minimum:

Metadata	Required?	Example
Description	Yes	`Customer profile API`
Owner team	Yes	`identity-platform`
Service tier	Yes for services	`tier-1`
Data classification	Yes where relevant	`confidential`
Lifecycle	Yes	`active`
Documentation URL	Recommended	Internal docs URL
Topics	Recommended	`go`, `api`, `production`

Custom properties are preferable to free-form README metadata when the information must drive automation.

120. Repository Protection Standard

Example baseline for a production service:

Default branch protected by ruleset
Pull request required
1-2 approvals based on risk
Code owner review for sensitive paths
Required CI checks
Code/secret scanning gate where licensed
Force push blocked
Deletion restricted
Auto-delete merged branches enabled
Production deployment through protected environment

Keep stronger profiles for critical repositories and lighter profiles for prototypes.

Part XIX — Repository Security Hardening

121. Least Privilege

Apply least privilege to every actor:

Human users
Teams
GitHub Apps
GITHUB_TOKEN
Deploy keys
PATs
CI runners
Environment credentials
MCP/agent tools

Practical hierarchy

Read < Triage < Write < Maintain < Admin

Do not grant Admin simply because someone needs one administrative operation. Use custom roles or controlled workflows where available.

122. Credential Hardening

Recommended order for automation identity:

OIDC federation for cloud credentials
GitHub App installation token for GitHub automation
Fine-grained PAT when a user identity is genuinely required
Deploy key for narrow SSH repository access
Classic PAT only when no better mechanism fits

Rotate these regularly

Deploy keys
PATs
Webhook secrets
External registry credentials
App private keys
Long-lived repository/environment secrets

123. Supply-Chain Security

A strong repository baseline combines:

Dependency graph
Dependabot alerts
Dependabot security updates
Dependency review
Code scanning
Secret scanning
Push protection
Release immutability
Artifact attestations where relevant
SHA-pinned third-party Actions for high-assurance workflows

Threat flow

flowchart LR
    D[Dependency] --> B[Build]
    A[Action] --> B
    C[Source Code] --> B
    B --> X[Artifact]
    X --> R[Release]
    R --> P[Production]

A compromise at any upstream point can reach production. Repository settings should therefore protect both source and automation.

124. Workflow File Protection

Workflow files are privileged code because they can access tokens, runners, OIDC, secrets, and deployment environments.

Protect:

.github/workflows/**

with:

CODEOWNERS
Required code-owner review
Rulesets
Minimal Actions permissions
Controlled reusable workflows

125. Self-Hosted Runner Hardening

If self-hosted runners are used:

Keep runner scope as narrow as practical.
Prefer ephemeral runners.
Separate trusted and untrusted workloads.
Restrict network paths.
Patch the host image frequently.
Do not persist cloud credentials.
Destroy workspaces after jobs.
Monitor runner registration and usage.

Public-repository pull requests and long-lived privileged runners are a particularly risky combination.

Part XX — Repository Lifecycle

126. Creation Phase

A new repository should not spend weeks in an insecure default state.

Creation checklist

[ ] Correct owner and visibility
[ ] Description and metadata
[ ] Owner team
[ ] Default branch
[ ] Merge strategy
[ ] Ruleset/protection
[ ] Actions policy
[ ] Security configuration
[ ] CODEOWNERS
[ ] CI workflow
[ ] Environment controls
[ ] Dependabot configuration
[ ] Documentation

Automate this baseline with templates/IaC where possible.

127. Active Operations Phase

Regular repository operations should include:

Access review
Ruleset review
CI health review
Runner review
Dependency maintenance
Security alert triage
Secret rotation
App/integration review
Environment reviewer review
Metadata ownership validation

128. Deprecation Phase

A repository that is no longer strategic should move through a controlled deprecation stage rather than disappearing suddenly.

Recommended:

Add a deprecation notice.
Name the replacement repository/service.
Stop feature development.
Migrate consumers.
Retire deployment automation.
Revoke unused credentials.
Close remaining issues/PRs.
Archive when dependencies are gone.

129. Archival Phase

When archiving:

Record the owning team.
Record the replacement/successor.
Keep a useful README.
Verify package/deployment dependencies.
Preserve compliance evidence externally if required.
Review whether security scanning on the archived code is required.

130. Deletion Phase

Deletion should be exceptional for business repositories.

Use approval and evidence:

Owner approval
Security/compliance check
Dependency check
Backup/export decision
Credential revocation
Deletion
Post-delete verification

Part XXI — Troubleshooting Guide

131. Access Troubleshooting

Problem	Likely cause	Diagnose	Solution
User cannot clone private repo	No effective Read access	Check direct, team, base access	Add appropriate team/role
User has more access than expected	Multiple access paths	Review teams and base permissions	Remove excess path
Cannot add outside collaborator	Org/enterprise policy	Check organization policy	Use approved invitation path
User cannot change setting	Higher-level enforcement	Check org/enterprise policy	Change policy at owning layer
Collaborator invitation pending	Not accepted / identity policy	Check access page	Reinvite or satisfy identity requirement

Debug principle

Do not ask only “what role does the user have?” Ask:

What are all paths that grant this user access?

132. Ruleset Troubleshooting

Problem	Likely cause	Diagnose	Solution
Push blocked unexpectedly	Branch/tag/push ruleset	Open repository rules / rule insights	Identify matching rule
Merge blocked	Required review/check/deployment	Check PR merge box	Complete missing condition
Required check missing	Job renamed or workflow not triggered	Inspect Actions run and ruleset check name	Restore check or update rule
Admin cannot bypass	No bypass or rule applies to admins	Inspect bypass list	Add approved bypass actor
Fork push blocked	Root push ruleset	Inspect source repository rules	Change root policy if justified
Conversion behaves differently	Legacy rule not 1:1 mapped	Compare branch protection and ruleset	Tune converted ruleset

Rule debugging order

1. Which ref is targeted?
2. Which rulesets match?
3. Is legacy branch protection also active?
4. Which rule is most restrictive?
5. Is an organization ruleset layered on top?
6. Is bypass actually granted to this actor?

133. Actions Settings Troubleshooting

Problem	Likely cause	Diagnose	Solution
Workflow never starts	Actions disabled	Settings → Actions	Enable if policy permits
Action denied	Allowlist policy	Check failure message and Actions policy	Allow approved action
`GITHUB_TOKEN` permission denied	Token too restricted	Inspect workflow `permissions`	Grant minimal required scope
Reusable workflow inaccessible	Private workflow access not granted	Check source repo Actions access	Grant org/repo access
Cache constantly evicted	Cache limit too small	Inspect cache usage	Increase limit or improve keys
Runner offline	Host/registration/network failure	Runner settings and host logs	Restore or re-register runner
Secret empty	Event or scope restriction	Check event and secret scope	Use correct environment/repo secret

Example permissions failure

If a workflow tries to create a release with:

permissions:
  contents: read

it will not have the required write capability. Grant only the needed permission:

permissions:
  contents: write

134. Environment Troubleshooting

Problem	Likely cause	Diagnose	Solution
Deployment waits indefinitely	Required reviewer	Open deployment review UI	Approve with eligible reviewer
Initiator cannot approve	Prevent self-review enabled	Check environment protection	Use another reviewer
Branch cannot deploy	Branch/tag restriction	Compare ref with environment rule	Update ref or approved policy
Secret not available	Job not using environment	Inspect workflow job	Add `environment:`
Protection App blocks deployment	External gate failed	Inspect protection rule response	Fix external condition

135. Advanced Security Troubleshooting

Problem	Likely cause	Diagnose	Solution
Code scanning option unavailable	Visibility/license/product issue	Check plan and security configuration	Enable required product
Default setup cannot enable	Actions disabled or unsupported repo	Check prerequisites	Enable Actions / use eligible repository
Secret scanning missing	Product/policy not enabled	Check Advanced Security config	Enable Secret Protection/eligible feature
Dependabot alerts absent	Dependency graph unavailable/disabled	Check dependency graph	Enable and commit supported manifests
AI Scan not available	Preview eligibility/licensing	Check GHAS/Copilot/policy	Enable only if eligible
Code Quality unavailable	Plan/enterprise policy	Check entitlement and policy	Enable where supported

136. Pages Troubleshooting

Problem	Likely cause	Diagnose	Solution
Site not publishing	Wrong source	Pages settings / Actions	Correct branch or workflow
404	Missing index or wrong path	Inspect published artifact	Add valid site root
Custom domain fails	DNS wrong	DNS lookup + Pages settings	Correct record
HTTPS unavailable	DNS/CAA/certificate issue	Check domain and certificate state	Fix DNS/CAA and retry
Old domain points to deleted site	Stale DNS	DNS audit	Remove/update record immediately

137. Webhook Troubleshooting

Symptom	Likely cause	What to inspect
401/403	Signature/auth failure	Secret and signature verification
404	Wrong endpoint	Payload URL
5xx	Receiver application error	Server logs
Timeout	Receiver slow/unreachable	Network and processing time
Duplicate processing	Redelivery/retry/idempotency issue	Delivery ID and idempotency key
Missing event	Event not subscribed	Webhook event settings

Part XXII — Best Practices

138. Access Best Practices

Recommended

Grant access through teams.
Use least privilege.
Minimize direct collaborators.
Review outside collaborators.
Keep Admin role rare.
Audit access periodically.

Avoid

Permanent admin access “just in case.”
Shared GitHub accounts.
Stale contractor access.
Making every team a direct collaborator on every repository.

139. Branch and Ruleset Best Practices

Recommended

Protect the default branch.
Require pull requests.
Require meaningful CI checks.
Require code-owner reviews for sensitive paths.
Block force pushes to protected production branches.
Use Evaluate mode before broad ruleset rollout.
Review bypass events.

Avoid

Rules nobody can explain.
Dozens of overlapping status checks.
Broad bypass groups.
Keeping legacy protections and new rulesets indefinitely without understanding their combined effect.

140. CI/CD Best Practices

Recommended

Restrictive default GITHUB_TOKEN.
Explicit workflow permissions.
OIDC for cloud access.
Protected environments.
SHA-pinned critical third-party Actions.
Organization reusable workflows.
Ephemeral runners for sensitive workloads.

Avoid

Long-lived cloud keys in repository secrets.
write-all permissions by default.
Unreviewed third-party Actions.
Production deployment from arbitrary feature branches.

141. Security Best Practices

Use defense in depth:

Dependencies → Dependabot + Dependency Review
Source       → Code Scanning + AI Scan where eligible
Secrets      → Secret Scanning + Push Protection
Quality      → Code Quality + Coverage
Changes      → Rulesets + Reviews + CODEOWNERS
Releases     → Protected Tags + Immutability
Deployments  → Environments + OIDC + Approvals

142. Lifecycle Best Practices

Assign an owner to every repository.
Record lifecycle status.
Deprecate before archiving.
Archive before deleting when practical.
Revoke credentials during retirement.
Maintain a documented deletion policy.
Back up only what the organization actually needs to retain.

Part XXIII — Common Mistakes

143. Common Repository Administration Mistakes

Mistake	Why it happens	Impact	Better approach
Giving Admin to all developers	Convenience	Excess destructive power	Write/Maintain + controlled admin
Protecting only `main` with old branch rule	Legacy setup	Weak coverage and hard-to-see overlap	Migrate thoughtfully to rulesets
Requiring too many checks	“More is safer”	Slow PRs, flaky merges	Require only policy-critical checks
Storing cloud keys in secrets forever	Easy initial setup	Credential exposure risk	OIDC federation
Allowing every Marketplace Action	Convenience	Supply-chain exposure	Allowlist and pin
Unprotected workflow files	Forgotten privilege boundary	CI credential compromise	CODEOWNERS + rules
Using variables for secrets	Misunderstanding	Secret disclosure	Use secrets
Using repository secret for prod without environment	Simplicity	Broader credential access	Production environment secret
No access review	Access only grows	Stale privilege	Periodic review
Deleting instead of archiving	Cleanup pressure	Loss of reference/history	Deprecate → archive → delete if justified
Ignoring visibility-change side effects	UI looks simple	Fork/log/security surprises	Pre-change checklist
Treating preview features as stable	New feature excitement	Automation breakage	Pin expectations and monitor changelog

Part XXIV — Beginner → Intermediate → Advanced Learning Map

144. Learning Levels

Level	What to learn
Beginner	General settings, default branch, Issues, PR merge options, collaborators, basic branch protection
Intermediate	Rulesets, Actions permissions, environments, webhooks, Pages, Dependabot, secrets/variables
Advanced	Organization/enterprise inheritance, security merge gates, Code Quality, AI Scan, APIs, Terraform, governance architecture

Suggested progression

Repository basics
    ↓
Access + pull requests
    ↓
Rulesets
    ↓
Actions
    ↓
Environments
    ↓
Security
    ↓
Automation/IaC
    ↓
Organization-scale governance

Part XXV — Quick Reference / Cheat Sheet

145. High-Value UI Paths

Task	Common path
Rename repo	Settings → General
Change visibility	Settings → General → Danger Zone
Manage access	Settings → Collaborators and teams
Create ruleset	Settings → Rulesets / Rules
Legacy branch protection	Settings → Branches
Actions permissions	Settings → Actions → General
Runners	Settings → Actions → Runners
Webhooks	Settings → Webhooks
Environments	Settings → Environments
Pages	Settings → Pages
Advanced Security	Settings → Advanced Security
Code Quality	Settings → Code quality
Deploy keys	Settings → Deploy keys
Actions secrets	Settings → Secrets and variables → Actions
GitHub Apps	Settings → GitHub Apps
Push email	Settings → Email notifications

UI names can vary as GitHub reorganizes navigation.

146. High-Value GitHub CLI Commands

# View repository
gh repo view OWNER/REPO

# Edit common settings
gh repo edit OWNER/REPO --delete-branch-on-merge

# List secrets
gh secret list --repo OWNER/REPO

# Create/update secret
gh secret set TOKEN --repo OWNER/REPO

# List variables
gh variable list --repo OWNER/REPO

# Create/update variable
gh variable set REGION --body "ap-northeast-1" --repo OWNER/REPO

# Query REST API
gh api /repos/OWNER/REPO

# List rulesets
gh api /repos/OWNER/REPO/rulesets

# Inspect Actions permission policy
gh api /repos/OWNER/REPO/actions/permissions

147. Permission Reminders

Human access:
Read → Triage → Write → Maintain → Admin

Workflow security:
Repository default → Workflow permissions → Job behavior

Policy hierarchy:
Enterprise → Organization → Repository → Environment → Workflow

148. Repository Security Baseline Cheat Sheet

[ ] Team-based access
[ ] Protected default branch
[ ] Pull request required
[ ] Required CI checks
[ ] CODEOWNERS for sensitive paths
[ ] Minimal GITHUB_TOKEN
[ ] Trusted/pinned Actions
[ ] Dependency graph + Dependabot
[ ] Code scanning where eligible
[ ] Secret scanning + push protection where eligible
[ ] Protected production environment
[ ] OIDC for cloud access
[ ] Release/tag integrity controls
[ ] Periodic app/access review

Part XXVI — Hands-On Exercises

149. Exercise 1 — Beginner: Configure a Safe Development Repository

Objective

Configure basic repository behavior for a small development team.

Tasks

Create or choose a test repository.
Set a clear description.
Enable Issues.
Disable Wiki if the team does not use it.
Set main as the default branch.
Enable squash merge.
Enable automatic deletion of merged branches.
Add a teammate with Write access through a team if using an organization.
Create a simple branch protection/ruleset requiring a pull request.

Expected outcome

Developers cannot casually push unreviewed changes to the protected default branch, and merged feature branches are cleaned up automatically.

Verification

Create a test branch and attempt to merge without the required condition.

150. Exercise 2 — Intermediate: Secure a CI Workflow

Objective

Create a CI workflow with minimal token permissions.

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 "Replace with real tests"

Tasks

Commit the workflow.
Confirm Actions is enabled.
Set the repository’s default workflow permission to restricted/read.
Create a ruleset that requires the CI check before merge.
Open a pull request.
Confirm the check runs.
Confirm merge is blocked until the check succeeds.

Expected outcome

CI is mandatory, but the workflow itself does not have unnecessary write permissions.

151. Exercise 3 — Intermediate: Protect Production Deployment

Objective

Use an environment to control production deployment.

Workflow:

name: Deploy

on:
  workflow_dispatch:

permissions:
  contents: read
  id-token: write

jobs:
  deploy:
    environment: production
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - run: echo "Deploy production"

Tasks

Create the production environment.
Add a required reviewer where your plan supports it.
Prevent self-review where available.
Restrict deployment to main.
Add a non-secret variable such as REGION.
If testing with a cloud provider, use OIDC instead of a static credential.
Run the workflow manually.

Expected outcome

The job pauses at the environment gate before executing deployment steps.

152. Exercise 4 — Advanced: Create a Repository Ruleset

Objective

Build a realistic default-branch ruleset.

Policy

Target: default branch
Require pull request: yes
Approvals: 1
Code owner review: yes
Required check: CI
Block force pushes: yes
Restrict deletion: yes

Tasks

Create a CODEOWNERS file.
Create the ruleset in Evaluate mode if available.
Open a pull request without approval.
Review Rule Insights.
Approve the PR and let CI pass.
Activate the ruleset.
Test again.

Expected outcome

You understand the difference between observing rule impact and actively enforcing it.

153. Exercise 5 — Advanced: Automate Repository Inventory

Objective

Use GitHub CLI and REST to inventory key repository settings.

Example:

gh api \
  -H "X-GitHub-Api-Version: 2026-03-10" \
  "/repos/$OWNER/$REPO" \
  --jq '{
    name,
    visibility,
    default_branch,
    archived,
    has_issues,
    has_wiki,
    delete_branch_on_merge
  }'

Then inspect rulesets:

gh api \
  -H "X-GitHub-Api-Version: 2026-03-10" \
  "/repos/$OWNER/$REPO/rulesets" \
  --jq '.[] | {name,enforcement,target}'

Challenge

Create a script that checks 10 repositories and reports:

Visibility
Default branch
Whether merged branches are deleted
Number of rulesets

Do not mutate production repositories during the exercise.

Part XXVII — Complete Practical Project

154. Project — Build a Production-Ready Repository Baseline

Requirement

A platform team needs a secure standard for new production services.

The repository must support:

Team-based access
Pull-request-only default branch
CI requirement
Dependency/security controls
Protected production deployment
GitHub Actions least privilege
Repository metadata
IaC management

Architecture

flowchart TD
    DEV[Developer] --> PR[Pull Request]
    PR --> CI[CI Checks]
    CI --> SEC[Security and Quality Checks]
    SEC --> REV[Review and CODEOWNERS]
    REV --> M[Merge to Main]
    M --> ENV[Production Environment]
    ENV --> APP[Deployment Approval]
    APP --> OIDC[OIDC Cloud Role]
    OIDC --> PROD[Production]

Step 1 — Repository metadata

Set:

Name: payment-api
Visibility: private
Description: Payment service API
Owner team: payments-platform
Service tier: tier-1
Lifecycle: active

Step 2 — Access

payments-developers → Write
payments-maintainers → Maintain
platform-admins → Admin
security-reviewers → Read

Avoid individual direct collaborators unless justified.

Step 3 — Merge model

Squash merge: enabled
Merge commit: disabled
Rebase merge: disabled
Delete merged branch: enabled

Step 4 — CODEOWNERS

* @example/payments-maintainers
.github/workflows/ @example/platform-security
terraform/ @example/cloud-platform

Step 5 — Ruleset

Protect the default branch with:

Pull request required
1 approval
Code owner review required
CI required
Conversation resolution required
Force push blocked
Deletion restricted

Step 6 — Actions policy

Keep GITHUB_TOKEN read-only by default.
Allow only approved actions.
Use reusable organization workflows where practical.
Pin sensitive third-party actions.

Step 7 — Security

Enable eligible controls:

Dependency graph
Dependabot alerts
Dependabot security updates
Code scanning
Secret scanning
Push protection
Code Quality if licensed and adopted

Evaluate AI Scan separately because it is currently preview functionality.

Step 8 — Environment

Create production:

Required reviewer: release/platform team
Prevent self-review: enabled where supported
Allowed branch: main
Secrets: minimal
Cloud auth: OIDC

Step 9 — IaC

Manage the baseline with Terraform or a platform provisioning system.

Store desired state in a dedicated governance repository and review changes through pull requests.

Step 10 — Validation

Test all of the following:

[ ] Direct push to main blocked
[ ] PR without review blocked
[ ] PR without CI blocked
[ ] Workflow cannot write with read-only token
[ ] Production job pauses for approval
[ ] Feature branch cannot deploy to production
[ ] Secret push is blocked where enabled
[ ] Unauthorized Action is denied
[ ] Ruleset bypass is logged

Improvement ideas

Organization-level rulesets
Repository custom-property policy
Automated repository scorecard
GitHub App based drift remediation
Artifact attestations
Central reusable workflows
Periodic access review automation

Part XXVIII — Interview and Knowledge-Check Questions

155. Conceptual Questions

What is the difference between Read, Triage, Write, Maintain, and Admin?
How does an organization policy affect repository settings?
What is the difference between branch protection and rulesets?
Why are multiple matching rulesets easier to reason about than multiple legacy branch rules?
What is the purpose of a push ruleset?
Why should GITHUB_TOKEN use least privilege?
What is the difference between a secret and a variable?
Why are environment secrets stronger than broad repository secrets for production?
What is the difference between CodeQL default setup and advanced setup?
What problem does release immutability solve?
Why is a webhook secret necessary?
What is the difference between a deploy key and a GitHub App?
Why should workflow files be protected with CODEOWNERS?
What does OIDC improve compared with static cloud credentials?
How do custom properties help repository governance?

156. Scenario Questions

Scenario 1

A developer has Write access but GitHub says the repository is read-only.

Think about: is the repository archived?

Scenario 2

An admin cannot merge a PR even though they normally bypass branch protection.

Think about: ruleset bypass configuration, organization rulesets, and “apply to admins”/bypass behavior.

Scenario 3

A workflow can read code but cannot create a release.

Think about: GITHUB_TOKEN contents permission.

Scenario 4

A production secret is empty during a deployment job.

Think about: whether the job references the environment and has passed its protection rules.

Scenario 5

A private repository is changed to public and a push-content rule disappears.

Think about: push rulesets are intended for private/internal repositories and fork networks.

Scenario 6

Code scanning is available in one repository but not another in the same organization.

Think about: visibility, security-product enablement, organization configuration, and plan eligibility.

Scenario 7

A Copilot code review can access an internal tool through MCP.

Think about: allowlisted tools, read-only constraints, MCP credentials, and autonomous invocation risk.

Part XXIX — FAQ

157. Should we use rulesets or branch protection?

For new governance designs, rulesets are generally the more scalable model because they layer, expose insights, support organization governance, and include push rulesets. Legacy branch protection remains valid and may continue to exist during migration.

158. Can repository admins override organization rules?

Not when the organization or enterprise policy is enforced in a way that prevents the repository from loosening it. Repository admins operate inside the higher-level policy boundary.

159. Should every developer have Admin?

No. Most developers need Write. Maintainers who manage repository behavior may need Maintain. Admin should be limited to people who genuinely administer the repository.

160. Should we use repository secrets for AWS/Azure/GCP credentials?

Prefer OIDC federation when the cloud provider supports it. Use stored secrets only for credentials that cannot be replaced with short-lived identity.

161. Is squash merge always best?

No. It is a common default because it keeps main history compact, but repositories that value individual commit history may prefer rebase or merge commits.

162. Is a `Signed-off-by` line a cryptographic signature?

No. Commit signoff and verified commit signing are different mechanisms.

163. Does a private repository always produce a private GitHub Pages site?

No. Pages visibility depends on plan and Pages configuration. Verify the site visibility independently.

164. Does deleting a repository permanently remove it immediately?

GitHub can restore some deleted repositories within 90 days, subject to fork-network and other restoration constraints. Do not treat restoration as a backup strategy.

165. Is AI Scan a replacement for CodeQL?

No. As of September 2026 it is a public-preview, pull-request-focused feature intended to extend coverage for languages/frameworks beyond CodeQL. It complements code scanning.

166. Does enabling Code Quality automatically block bad pull requests?

No. Analysis and enforcement are separate. Use a ruleset with the appropriate Code Quality rule/threshold if you want merge blocking.

167. Can a repository setting be different from the organization default?

Often yes, when the higher-level policy allows local choice. If the organization or enterprise enforces a setting, the repository cannot loosen it.

168. Should we manage repositories with Terraform?

Use IaC when you need repeatable multi-repository governance. For a handful of simple repositories, UI/API management may be enough. The important requirement is consistent, reviewable desired state.

Part XXX — Reference Architecture for Enterprise Repository Governance

169. Recommended Layering

flowchart TD
    EP[Enterprise Policy] --> OP[Organization Policy]
    OP --> CP[Custom Properties]
    CP --> OR[Organization Rulesets]
    OR --> RR[Repository Rulesets]
    RR --> CI[Required CI]
    CI --> SQ[Security and Quality]
    SQ --> ENV[Protected Environment]
    ENV --> OIDC[OIDC Deployment]

Enterprise layer

Use for broad guardrails:

Identity
Actions policy
Security-product policy
App policy
Visibility policy

Organization layer

Use for portfolio governance:

Teams
Base permissions
Custom properties
Organization rulesets
Security configurations
Runner groups
Reusable workflows

Repository layer

Use for service-specific behavior:

Merge model
Repository rulesets
Environment configuration
Webhooks
Repository-specific secrets/variables
Pages
Repo-specific Apps

Part XXXI — Repository Administration Operating Model

170. Who Should Own What?

Control	Suggested owner
Repository metadata	Service owner / platform
Team access	Engineering manager / platform
Admin access	Platform / repository owner
Rulesets	Platform + service team
Actions allowlist	Platform/security
Reusable workflows	Platform/DevOps
Code scanning	Security/platform
Secret scanning	Security/platform
Code Quality	Engineering/platform
Environments	Platform/release engineering
Production reviewers	Service/release owner
GitHub Apps	Platform/security
Webhooks	Platform/integration owner
Repository retirement	Business + service owner

The exact organization model varies, but ambiguous ownership is itself a governance risk.

Part XXXII — Complete Settings Coverage Map

The following map connects the supplied 151-topic syllabus to the chapters in this guide.

171. Basic and General Settings Coverage

Syllabus topic	Covered in
1. GitHub Repository Administration	Sections 1–3
2. Repository Settings Navigation	Section 3
3. Repository Identity	Sections 4–5
4. Template Repository	Section 6
5. Default Branch	Section 7
6. Releases	Section 8
7. Social Preview	Section 5
8. Wikis	Section 9
9. Issues	Sections 9, 52–55
10. Pull Requests	Sections 10–13
11. Discussions	Section 9
12. GitHub Projects	Sections 9, 54–55
13. Merge Methods	Section 10
14. Merge Commit Configuration	Section 10
15. Squash Merge Configuration	Section 10
16. Pull Request Update Behavior	Section 11
17. Auto-Merge	Section 12
18. Head Branch Cleanup	Section 13
19. Source Archives	Section 14
20. Git LFS in Archives	Section 14
21. Push Policy	Section 15
22. Web Commit Signoff	Section 16
23. Automatic Issue Closing	Section 17
24. Autolink References	Section 18
25. Repository Visibility	Section 19
26. Repository Transfer	Section 20
27. Repository Archive	Sections 21, 129
28. Repository Deletion	Sections 22, 130

172. Access, Moderation, Rules, Branches, Tags Coverage

Syllabus topic	Covered in
29. Repository Access Management	Sections 23–24
30. Repository Roles	Sections 2, 23
31. Collaborator Management	Sections 23–24
32. Team Management	Sections 23–24
33. Repository Moderation	Section 25
34. Interaction Limits	Section 25
35. Contribution Moderation	Section 25
36. Pull Request Review Restrictions	Section 26
37. Rulesets Fundamentals	Section 27
38. Ruleset Status	Section 27
39. Ruleset Targeting	Section 28
40. Ruleset Bypass	Section 29
41. Branch and Tag Rules	Section 30
42. Push Rules	Section 31
43. Security and Quality Rules	Section 32
44. Ruleset Administration	Section 33
45. Repository Custom Properties	Section 34
46. Custom Property Use Cases	Section 34
47. Custom Properties and Governance	Sections 34, 118–119
48. Branch Administration	Section 35
49. Branch Protection Rules	Sections 30, 36
50. Branch Protection vs Rulesets	Section 36
51. Tag Administration	Section 37
52. Tag Rulesets	Section 37
53. Immutable Release Tags	Sections 8, 37

173. Actions and Webhooks Coverage

Syllabus topic	Covered in
54. Actions Permissions	Section 38
55. Workflow Permissions	Section 39
56. Fork Pull Request Workflows	Section 40
57. Reusable Workflow and Action Access	Section 41
58. Workflow Retention	Section 42
59. Actions Cache Settings	Section 43
60. Repository Runners	Section 44
61. Repository Webhooks	Section 45
62. Webhook Events	Section 45
63. Webhook Operations	Section 47
64. Webhook Security	Section 46

174. Copilot and Planning Coverage

Syllabus topic	Covered in
65. GitHub Copilot Repository Controls	Section 48
66. Copilot Code Review	Section 49
67. Repository Custom Instructions	Section 49
68. Copilot MCP Servers	Section 50
69. Copilot Coding Agent	Section 51
70. Repository Planning Features	Sections 52–55
71. Issue Templates	Section 52
72. Issue Metadata	Section 54
73. Automatic Planning Behavior	Section 55

175. Environments and Pages Coverage

Syllabus topic	Covered in
74. Deployment Environments	Section 56
75. Required Reviewers	Section 57
76. Wait Timers	Section 58
77. Deployment Branches and Tags	Section 59
78. Custom Deployment Protection Rules	Section 60
79. Environment Secrets	Section 61
80. Environment Variables	Section 62
81. GitHub Pages	Section 63
82. Pages Branch Source	Section 64
83. Custom Domains	Section 66
84. HTTPS	Section 67
85. Pages Visibility	Section 68

176. Security and Quality Coverage

Syllabus topic	Covered in
86. Security and Analysis	Section 69
87. Dependency Graph	Section 70
88. Dependabot Alerts	Section 71
89. Dependabot Security Updates	Section 72
90. Dependabot Version Updates	Section 73
91. Dependency Review	Section 74
92. Code Scanning	Sections 75–77
93. AI Scan	Section 78
94. Secret Scanning	Section 79
95. Push Protection	Section 80
96. GitHub Code Quality	Sections 81–84
97. Code Quality Pull Request Controls	Section 83
98. Code Coverage	Section 84

177. Keys, Secrets, Apps, Notifications Coverage

Syllabus topic	Covered in
99. Deploy Keys	Section 85
100. Deploy Key Security	Section 86
101. Actions Secrets	Section 87
102. Actions Variables	Section 88
103. Dependabot Secrets	Section 89
104. Codespaces Secrets	Section 90
105. Copilot/Agents Secrets and Variables	Section 91
106. Installed GitHub Apps	Section 93
107. GitHub App Repository Permissions	Section 94
108. GitHub App Administration	Sections 93–94
109. Push Email Notifications	Section 95

178. Policy, Governance, API, CLI, IaC Coverage

Syllabus topic	Covered in
110. Organization Policy Overrides	Section 96
111. Enterprise Policy Overrides	Section 97
112. Configuration Precedence	Sections 1, 97
113. Repository Access Model	Sections 23, 98
114. Repository Security Model	Sections 98, 121–125
115. Repository CI/CD Governance	Section 99
116. Repositories REST API	Sections 100–101
117. Collaborators API	Section 102
118. Rules API	Section 103
119. Actions Administration API	Section 104
120. Environment API	Section 105
121. Webhooks API	Section 106
122. GraphQL Repository Administration	Section 109
123. GitHub CLI	Section 108
124. Terraform GitHub Provider	Sections 110–115
125. Repository as Code	Section 116

179. Standardization, Security, Lifecycle, Troubleshooting Coverage

Syllabus topic	Covered in
126. Repository Templates	Section 117
127. Repository Metadata Standards	Sections 118–119
128. Repository Protection Standards	Section 120
129. Least Privilege	Section 121
130. Credential Hardening	Section 122
131. Supply Chain Security	Sections 123–125
132. Repository Creation	Section 126
133. Active Repository Operations	Section 127
134. Repository Deprecation	Section 128
135. Repository Archival	Section 129
136. Repository Deletion	Section 130
137. Access Troubleshooting	Section 131
138. Ruleset Troubleshooting	Section 132
139. Actions Settings Troubleshooting	Section 133
140. Environment Troubleshooting	Section 134
141. Security Troubleshooting	Section 135
142. Access Best Practices	Section 138
143. Branch Governance Best Practices	Section 139
144. CI/CD Best Practices	Section 140
145. Security Best Practices	Section 141
146. Repository Lifecycle Best Practices	Section 142

180. Exact Settings Areas Coverage

Syllabus topic	Covered in
147. General	Parts I–II
148. Access	Part III
149. Code, Planning, and Automation	Parts IV–X
150. Security and Quality	Parts XI–XIII
151. Integrations	Part XIV

Part XXXIII — Summary

181. What You Should Remember

GitHub Repository Settings are not a collection of unrelated toggles. They form a layered repository control system.

The most important mental model is:

Who can access?
      ↓
How may code change?
      ↓
What automation may execute?
      ↓
What security/quality evidence is required?
      ↓
Who may deploy?
      ↓
How is the repository governed through its lifecycle?

For most production repositories, prioritize these controls first:

Team-based least-privilege access
Protected default branch using rulesets
Required pull request and CI checks
Minimal GITHUB_TOKEN
Trusted/pinned Actions and reusable workflows
Dependency, code, and secret security controls
Protected deployment environments
OIDC for cloud access
Repository metadata and ownership
Automation/IaC for repeatable governance

GitHub changes quickly. Re-check plan availability, preview status, API versions, and organization/enterprise policy before rolling a setting out broadly.

References

The following authoritative sources were used to verify the current behavior described in this guide.

Repository settings and lifecycle

GitHub Docs — Managing your repository’s settings and features
https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features
GitHub Docs — Managing repository settings
https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings
GitHub Docs — Setting repository visibility
https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/setting-repository-visibility
GitHub Docs — Transferring a repository
https://docs.github.com/en/repositories/creating-and-managing-repositories/transferring-a-repository
GitHub Docs — Deleting a repository
https://docs.github.com/en/repositories/creating-and-managing-repositories/deleting-a-repository
GitHub Docs — Restoring a deleted repository
https://docs.github.com/en/repositories/creating-and-managing-repositories/restoring-a-deleted-repository
GitHub Docs — Preventing changes to your releases
https://docs.github.com/en/code-security/how-tos/secure-your-supply-chain/establish-provenance-and-integrity/prevent-release-changes

Access, branches, and rulesets

GitHub Docs — Managing repository roles
https://docs.github.com/en/organizations/managing-user-access-to-your-organizations-repositories/managing-repository-roles
GitHub Docs — Limiting interactions in your repository
https://docs.github.com/en/communities/moderating-comments-and-conversations/limiting-interactions-in-your-repository
GitHub Docs — About rulesets
https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets
GitHub Docs — Creating rulesets for a repository
https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/creating-rulesets-for-a-repository
GitHub Docs — Available rules for rulesets
https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/available-rules-for-rulesets
GitHub Docs — Converting branch protections to rulesets
https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/converting-branch-protections-to-rulesets
GitHub Docs — About protected branches
https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches

Actions and deployments

GitHub Docs — Managing GitHub Actions settings for a repository
https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository
GitHub Docs — Managing environments for deployment
https://docs.github.com/en/actions/how-tos/deploy/configure-and-manage-deployments/manage-environments
GitHub Docs — Deployments and environments
https://docs.github.com/en/actions/reference/workflows-and-actions/deployments-and-environments
GitHub Docs — Using secrets in GitHub Actions
https://docs.github.com/en/actions/how-tos/write-workflows/choose-what-workflows-do/use-secrets

Copilot

GitHub Docs — Adding repository custom instructions for GitHub Copilot
https://docs.github.com/en/copilot/how-tos/copilot-on-github/customize-copilot/add-custom-instructions/add-repository-instructions
GitHub Docs — Configure MCP servers for your repository
https://docs.github.com/en/copilot/how-tos/copilot-on-github/customize-copilot/configure-mcp-servers
GitHub Docs — About GitHub Copilot code review
https://docs.github.com/en/copilot/concepts/agents/code-review

Security and quality

GitHub Docs — Quickstart for securing your repository
https://docs.github.com/en/code-security/getting-started/quickstart-for-securing-your-repository
GitHub Docs — About setup types for code scanning
https://docs.github.com/en/code-security/concepts/code-scanning/setup-types
GitHub Docs — Configuring advanced setup for code scanning
https://docs.github.com/en/code-security/how-tos/find-and-fix-code-vulnerabilities/configure-code-scanning/configuring-advanced-setup-for-code-scanning
GitHub Docs — About SARIF files for code scanning
https://docs.github.com/en/code-security/concepts/code-scanning/sarif-files
GitHub Docs — AI Scan for pull requests
https://docs.github.com/en/code-security/concepts/code-scanning/ai-powered-security-detections
GitHub Changelog — Code scanning AI Scan no longer requires CodeQL default setup, September 16, 2026
https://github.blog/changelog/2026-09-16-code-scanning-ai-scan-no-longer-requires-codeql-default-setup/
GitHub Docs — Enabling push protection for your repository
https://docs.github.com/en/code-security/how-tos/secure-your-secrets/prevent-future-leaks/enable-push-protection
GitHub Docs — Enabling GitHub Code Quality
https://docs.github.com/en/code-security/how-tos/maintain-quality-code/enable-code-quality
GitHub Docs — Setting code quality thresholds for pull requests
https://docs.github.com/en/code-security/how-tos/maintain-quality-code/set-pr-thresholds
GitHub Docs — GitHub security and quality AI features application card
https://docs.github.com/en/code-security/responsible-use/security-and-quality-ai-features

GitHub Apps and custom properties

GitHub Docs — Reviewing and modifying installed GitHub Apps
https://docs.github.com/en/apps/using-github-apps/reviewing-and-modifying-installed-github-apps
GitHub Docs — Managing custom properties for repositories in your organization
https://docs.github.com/en/organizations/managing-organization-settings/managing-custom-properties-for-repositories-in-your-organization
GitHub Docs — About email notifications for pushes
https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/about-email-notifications-for-pushes-to-your-repository

APIs and Terraform

GitHub Docs — REST API
https://docs.github.com/en/rest
GitHub Docs — REST API endpoints for deployment environments
https://docs.github.com/en/rest/deployments/environments
GitHub Docs — REST API endpoints for deploy keys
https://docs.github.com/en/rest/deploy-keys/deploy-keys
GitHub Docs — REST API endpoints for custom properties
https://docs.github.com/en/rest/repos/custom-properties
Terraform Registry — integrations/github provider
https://registry.terraform.io/providers/integrations/github/latest/docs

Final operational principle: configure repositories so that the safe path is the easiest path. Good repository governance should prevent common mistakes automatically while keeping normal developer work fast and understandable.

rajeshkumar