GitHub Repository Settings: Branch Rules, Collaborators, and Visibility

Beyond the initial creation decisions covered earlier in this module, GitHub offers an extensive settings panel for each repository, letting owners control exactly who can access and contribute to a project, and what safeguards apply to its most important branches. This lesson covers the three settings most relevant to a beginner starting to collaborate with others: branch protection rules, collaborator management, and changing visibility after the fact.

Learning Objectives

• Understand what branch protection rules do and why they're commonly applied to main.
• Add a collaborator to a repository, granting them access to contribute.
• Change a repository's visibility between public and private after creation.
• Recognize the practical implications of changing visibility on an existing repository.

Key Terms to Know Before Configuring GitHub Repository Settings

• Branch protection rule: A GitHub setting applied to a specific branch (commonly main) that enforces requirements — such as passing status checks or required reviews — before changes can be merged into it.
• Required reviews: A branch protection setting mandating that a pull request receive a specified number of approvals before it can be merged.
• Collaborator: A person explicitly granted access to contribute to a repository, with a specific permission level (such as read, write, or admin).
• Repository visibility: The public/private setting determining who can view a repository, changeable at any time after creation through repository settings.

How Key GitHub Repository Settings Actually Work

**Branch protection rules**, found under a repository's Settings > Branches, let an owner enforce specific requirements on important branches — most commonly `main` — before changes can be merged into them. Common protections include requiring that a pull request receive a minimum number of approving reviews before merging, requiring that automated status checks (such as a CI test suite) pass successfully, preventing direct pushes to the protected branch entirely (forcing all changes through a reviewed pull request instead), and preventing the branch from being deleted or having its history forcibly rewritten. These rules exist specifically to prevent both accidental mistakes (like an unreviewed, broken change reaching production) and to enforce a team's chosen code-review culture technically, rather than relying purely on convention or trust.

**Collaborators**, managed under Settings > Collaborators and teams, are people explicitly granted access to a repository. For a private repository, adding a collaborator is what grants them any visibility into the project at all. For both public and private repositories, a collaborator's specific **permission level** determines what they're allowed to do — common levels include Read (view and clone only), Triage (Read, plus managing issues and pull requests without code access), Write (can push directly, depending on branch protection rules, and merge pull requests), Maintain (Write, plus some repository management settings), and Admin (full control, including the ability to change settings, delete the repository, or manage other collaborators' access).

**Repository visibility** (public vs. private, from earlier in this module) is not a permanent, one-time decision — it can be changed at any point under Settings > General > Danger Zone. It's called the 'Danger Zone' for good reason: changing a private repository to public makes its entire history, including every past commit, instantly visible to anyone — a serious concern if any commit anywhere in that history contains something sensitive (a callback to Module 1 and 2's lessons on `.gitignore` and `git rm --cached`, since visibility changes don't retroactively clean history). Conversely, making a public repository private removes it from public search and browsing, though anyone who had already cloned it beforehand retains their own local copy of whatever history existed at that time, regardless of the visibility change.

GitHub Repository Settings: Visual Walkthrough

Draw a GitHub repository settings sidebar mockup with three highlighted tabs: 'Branches' (showing a rule card: 'main — Require pull request reviews before merging: ✓, Require status checks to pass: ✓'), 'Collaborators and teams' (showing a list: 'Asha Mehta — Write', 'Rohit Sharma — Admin', 'Meera Nair — Read'), and 'General > Danger Zone' (showing 'Change repository visibility' and 'Delete this repository' in a red-bordered warning box). Add a callout on the Danger Zone box: 'Making a private repo public exposes its FULL history instantly — .gitignore added afterward does not retroactively hide old commits.'

Key GitHub Repository Settings: Quick Reference Table

Setting	Location	Purpose
Branch protection rules	Settings > Branches	Enforce reviews/checks before merging into important branches like main
Collaborators	Settings > Collaborators and teams	Grant specific people access, with a defined permission level (Read/Write/Admin, etc.)
Repository visibility	Settings > General > Danger Zone	Switch between public and private after creation
Permission levels	Set per collaborator	Read, Triage, Write, Maintain, Admin — each granting progressively more access

Verifying Repository Settings Alongside Git Commands

# Repository settings are configured via GitHub's web interface, not Git commands directly,
# but their EFFECTS are visible through normal Git operations. For example:

# A direct push blocked by a branch protection rule requiring pull requests:
git push origin main
# ! [remote rejected] main -> main (protected branch hook declined)
# error: failed to push some refs...

# The correct approach once main is protected: push a feature branch and open a PR instead
git push -u origin feature/new-signup-flow
# Then open a Pull Request on GitHub's website, targeting main

Breaking Down the Repository Settings Example

This example shows how a repository setting — a branch protection rule requiring pull requests — manifests directly in the command line: attempting to push straight to a protected `main` branch is explicitly rejected by GitHub, even though the local commit and push mechanics are otherwise identical to any normal push. The correct path forward, shown in the second command, is pushing a feature branch to `origin` (as covered in earlier lessons this module) and then opening a pull request on GitHub's website — respecting the review process the branch protection rule was specifically configured to enforce.

How Repository Settings Are Used on Real Engineering Teams

• Virtually every professional engineering team protects its main (or production-representing) branch with required reviews and passing status checks, making direct pushes to that branch technically impossible regardless of individual developer habits.
• Open-source projects commonly grant 'Write' access only to a small, trusted set of maintainers, while accepting contributions from anyone via the fork-and-pull-request workflow (previous lesson) rather than direct collaborator access.
• Security incidents involving accidentally exposed private repositories have prompted many companies to adopt strict internal policies requiring a security review before any repository's visibility is changed from private to public.
• Larger organizations often use GitHub Teams (a related feature) to manage collaborator access at scale, granting permissions to entire teams of people at once rather than adding individuals one by one.

GitHub Repository Settings Interview Questions and Answers

Q1. What is a branch protection rule, and why would a team apply one to their main branch?

It's a GitHub setting that enforces specific requirements — such as required pull request reviews or passing status checks — before changes can be merged into a protected branch. Teams commonly apply this to main to prevent accidental, unreviewed, or broken changes from reaching their primary line of development, enforcing a code-review culture technically rather than just by convention.

Q2. What are the common permission levels a collaborator can be granted on a GitHub repository?

Common levels include Read (view and clone only), Triage (Read plus managing issues/PRs without code access), Write (can push and merge, subject to branch protections), Maintain (Write plus some repository management), and Admin (full control, including settings and deleting the repository).

Q3. Why is changing a repository's visibility from private to public referred to as being in a 'Danger Zone'?

Because making a private repository public instantly exposes its entire commit history to anyone, including any past commits that may contain sensitive information. Since visibility changes don't retroactively clean history, anything committed while private (including secrets not properly removed) becomes fully visible the moment the repository is made public.

GitHub Repository Settings Quiz: Test Your Understanding

1. What does a branch protection rule requiring pull request reviews prevent?

1. Cloning the repository
2. Direct pushes to the protected branch without going through a reviewed pull request
3. Creating new branches
4. Adding new collaborators

Answer: B. Direct pushes to the protected branch without going through a reviewed pull request

Explanation: Branch protection rules can specifically block direct pushes to a protected branch like main, requiring all changes to go through a pull request that meets the configured review requirements first.

2. Which collaborator permission level grants full control, including changing repository settings?

1. Read
2. Triage
3. Write
4. Admin

Answer: D. Admin

Explanation: Admin is the highest permission level, granting full control over the repository, including the ability to change settings, manage other collaborators, and even delete the repository.

3. What happens to a repository's commit history when it is changed from private to public?

1. The history is automatically cleaned of any sensitive commits
2. The entire existing history becomes instantly visible to anyone
3. Only the most recent commit becomes visible
4. A new, empty history is created

Answer: B. The entire existing history becomes instantly visible to anyone

Explanation: Changing visibility does not retroactively alter or clean a repository's history — the full existing commit history becomes immediately visible to the public the moment a repository is made public.

Common Mistakes With GitHub Repository Settings

• Assuming .gitignore or later cleanup retroactively protects secrets already committed to history if a repository is later made public — visibility changes expose the full existing history instantly.
• Granting Admin access to collaborators who only need Write (or a lower level), unnecessarily expanding who can change critical repository settings.
• Not setting up branch protection rules on important branches early, allowing accidental direct pushes that bypass a team's intended review process.
• Being surprised by a rejected push after a branch protection rule was added, without realizing this is the rule working exactly as intended.

GitHub Repository Settings: Exam-Ready Quick Notes

• Branch protection rules (Settings > Branches): can require PR reviews, passing status checks, and block direct pushes to protected branches.
• Collaborator permission levels (least to most access): Read, Triage, Write, Maintain, Admin.
• Repository visibility (Settings > General > Danger Zone): changeable anytime; making private → public exposes full existing history instantly.
• Visibility changes do NOT retroactively clean or protect already-committed sensitive data.

GitHub Repository Settings: Key Takeaways

• Branch protection rules let teams technically enforce their intended code-review process, rather than relying purely on convention.
• Collaborator permission levels provide fine-grained control over exactly what each person is allowed to do within a repository.
• Changing a repository's visibility is a serious, history-wide decision, not a superficial toggle — especially when going from private to public.

Frequently Asked Questions About GitHub Repository Settings

Q1. What is a branch protection rule on GitHub?

It's a setting applied to a specific branch, commonly main, that enforces requirements like required pull request reviews or passing automated checks before changes can be merged into it, often also blocking direct pushes to that branch entirely.

Q2. How do I add a collaborator to my GitHub repository?

Go to the repository's Settings, then Collaborators and teams, and add the person by their GitHub username or email, choosing an appropriate permission level such as Read, Write, or Admin depending on what access they need.

Q3. Can I change my repository from private to public after creating it?

Yes, this can be done anytime under Settings > General > Danger Zone. However, doing so instantly exposes the repository's entire existing commit history to the public, so it's important to be sure no sensitive information exists anywhere in that history first.

Q4. What are the different permission levels I can grant a collaborator?

Common levels, from least to most access, are Read (view/clone only), Triage (issue/PR management without code access), Write (can push and merge), Maintain (Write plus some settings access), and Admin (full control over the repository).

Q5. Does making a public repository private again hide its previous history from everyone?

It removes the repository from public search and browsing going forward, but anyone who already cloned it while it was public keeps their own local copy of whatever history existed at that time, regardless of the later visibility change.

Summary

Beyond initial creation decisions, GitHub's repository settings offer meaningful ongoing control. Branch protection rules (Settings > Branches) let a team enforce requirements like required pull request reviews and passing status checks before changes can be merged into important branches like `main`, technically preventing unreviewed or accidental direct pushes. Collaborator settings (Settings > Collaborators and teams) grant specific people access at a defined permission level — from Read up through Admin — controlling exactly what each person is allowed to do. Repository visibility, found under Settings > General's aptly named 'Danger Zone', can be changed between public and private at any time, but changing a private repository to public instantly exposes its entire existing commit history, since visibility changes never retroactively clean or hide already-committed content, however sensitive.