13.1 Privacy, Visibility, and Branch Protection
Key Takeaways
- Public repositories are visible to anyone on the internet; private repositories are limited to people you share with; internal visibility exists only on GitHub Enterprise Cloud for organizations owned by an enterprise account and grants read access to every enterprise member for InnerSource.
- People with admin permissions can change repository visibility from Settings → Danger Zone; organization owners can restrict that ability to owners only.
- A classic branch protection rule disables force pushes and branch deletion by default; people with admin permissions (and custom roles with bypass) can skip the restrictions unless “Do not allow bypassing the above settings” is enabled.
- Required status checks are strict when “Require branches to be up to date before merging” is checked (the default) and loose when that checkbox is cleared; only one classic branch protection rule applies to a branch at a time.
- Rulesets can layer on the same branch, including alongside a classic rule; when the same rule is defined more than once, the most restrictive version applies.
Why GH-900 pairs visibility with branch protection
Domain 6 of GitHub Foundations (GH-900) is 10–15% of the exam. After accounts, repository roles, and Enterprise Managed Users, the January 2026 outline asks you to describe repository privacy options, visibility settings, and branch protection rules. Visibility answers who can even see the Git history. Branch protection answers who can rewrite the default branch after they can see it. A stem that says “InnerSource across the company” is a visibility question. A stem that says “nobody force-pushes main” is a protection question. Do not mix the two.
Three visibilities, not two
A repository is GitHub’s basic unit: files, history, issues, and pull requests. Visibility is the switch that restricts who may view that unit. GitHub Docs name three settings:
| Visibility | Who can see it | Where it exists | Typical GH-900 use |
|---|---|---|---|
| Public | Anyone on the internet | Personal accounts and organizations (unless policy or Enterprise Managed Users block public creation) | Open source, public docs, community projects |
| Private | You, people you explicitly share with, and—on org repos—members who have a role or inherit base permissions | All plans | Proprietary work, customer data, secrets-adjacent code |
| Internal | All enterprise members (read), including people in other organizations in the same enterprise | GitHub Enterprise Cloud organizations owned by an enterprise account only | InnerSource: open-source practices without a public leak |
Public repositories are accessible to everyone on the internet. Private repositories are accessible only to the owner, people granted access, and (for organization repositories) certain organization members. Organization owners always have access to every repository created in the organization—visibility never hides an org repo from its owners.
Internal is the exam discriminator. You can create an internal repository only if you use GitHub Enterprise Cloud with an enterprise account. An enterprise account is a separate account type that centrally manages multiple organizations. GitHub documents internal repositories as the way to practice InnerSource: enterprise members collaborate with open-source methods without publishing proprietary code. Organization members have read permissions to all internal repositories in the enterprise, including repositories in organizations they are not a member of. Internal repositories are not visible to people outside the enterprise, including outside collaborators on organization repositories. Internal is the default visibility for new repositories in an organization owned by an enterprise account.
If the account is an Enterprise Managed User (EMU), GitHub further restricts the menu: managed users may set personal-account repositories to private only, and repositories in the enterprise’s organizations may be private or internal—not public. Do not tell the exam that “Enterprise always has public, private, and internal.” EMU and enterprise visibility policies can hide Public.
Who may change visibility
People with admin permissions for a repository can change an existing repository’s visibility (Settings → Danger Zone → Change visibility). That includes the personal-account owner and anyone with the organization Admin repository role. Organization owners can restrict visibility changes to owners only; if a repository admin cannot find the control, the org policy is the documented reason.
Visibility changes have consequences GitHub wants you to anticipate:
- Public → private: GitHub detaches public forks and puts them in a new network. Public forks are not made private. Stars and watchers are erased. On GitHub Free, some private-repo features disappear; a published GitHub Pages site is unpublished.
- Private → public: The code is visible to anyone on GitHub.com; anyone can fork it; Actions history and logs become visible; push rulesets are disabled; stars and watchers are erased.
- Private or public → internal: All enterprise members receive read access. Outside collaborators can no longer be added to forks unless they are added to the root repository.
- Internal → private: Enterprise-wide automatic read ends. GitHub removes forks for people who would lose access.
Changing visibility is not a quiet metadata edit. If a stem mentions “we made the repo private and the community forks are still public,” that is documented behavior, not a bug.
Branch protection rules and rulesets
What a classic protected branch actually blocks
You enforce a workflow on a branch by creating a branch protection rule. The rule can target a specific branch (main), all branches, or any name that matches an fnmatch pattern (for example *release*). By default, each branch protection rule disables force pushes to the matching branches and prevents those branches from being deleted. You can later allow force pushes or deletions, but GH-900 treats “protected = no force-push, no delete” as the starting point.
Protected-branch features on private repositories sit on paid plans: GitHub documents protected branches, required reviewers, and code owners for private repos on GitHub Pro, GitHub Team, and GitHub Enterprise. Public repositories on GitHub Free keep the full collaboration feature set. If a stem is about a Free organization private repo that cannot require reviews, plan limits—not a missing checkbox—are the answer.
Settings GitHub lists on each classic rule, and the exam meaning of each:
| Setting | What it requires or blocks | Exam note |
|---|---|---|
| Require pull request reviews before merging | A set number of approving reviews from people with write permission (or from designated code owners) | Collaborators can push to the protected branch only through an approved pull request. An admin who clicks Request changes must later approve, or someone with write can dismiss the blocking review. |
| Require reviews from CODEOWNERS | Any pull request that touches code with an owner in CODEOWNERS must be approved by that owner | CODEOWNERS is a file; this checkbox is what enforces it on the protected branch. |
| Require status checks before merging | Required checks must be successful, skipped, or neutral | Strict (default): “Require branches to be up to date before merging” is checked—the head must match the base, which can mean extra CI runs. Loose: the checkbox is cleared—the head need not be up to date, so you risk merging incompatible history. Disabled: no status-check merge restriction. |
| Require conversation resolution before merging | All pull request comments must be resolved | Review threads cannot be left hanging. |
| Require signed commits | Only signed and verified commits may be pushed | An unsigned commit has to be rewritten (rebase) and force-pushed; force-push is still blocked unless you allowed it. |
| Require linear history | No merge commits; pull requests must squash or rebase | The repository must already allow squash or rebase merging. |
| Do not allow bypassing the above settings | Applies the rule to admins and custom roles with bypass branch protections | Default: admins are not bound. This checkbox is how you stop an admin merge that skips reviews. |
| Restrict who can push | Only listed users, teams, or apps may push | Available on public repositories owned by a GitHub Free organization and on all repositories for GitHub Team or GitHub Enterprise Cloud. People with push permission still need a pull request if reviews are required, and still cannot merge if required checks fail. |
| Allow force pushes / Allow deletions | Turns the defaults off | Force-push can drop commits others based work on. A locked branch cannot be deleted even if deletion is allowed. |
Optional review extras that show up in “gotcha” stems: dismiss stale approvals when new commits change the diff; require approval of the most recent reviewable push so the last person to push cannot be the sole approver. Either extra can make a handmade merge commit fail unless it matches GitHub’s own merge.
Actors may be added to bypass lists only when the repository belongs to an organization. Personal-account repos do not get the same org-style bypass roster.
Classic rules versus rulesets
GitHub’s warning is the line to memorize: only a single branch protection rule can apply at a time, so overlapping classic rules (for example main and *) make it hard to know which rule wins. This restriction does not apply to rulesets.
A ruleset is a named list of rules for branches, tags, or pushes. GitHub Team and GitHub Enterprise plans can use rulesets (up to 75 per repository and 75 organization-wide). Compared with classic protection:
- Multiple rulesets can apply to the same branch at the same time; classic allows only one.
- Rulesets have an enforcement status (Active or Disabled) you can flip without deleting the ruleset.
- Anyone with read access can view active rulesets, which helps contributors and auditors who are not admins.
- Organization-level rulesets that target many repositories are a GitHub Enterprise capability.
- Push rulesets can block pushes to a private or internal repository and its entire fork network by file path, path length, extension, or size.
Rulesets do not have a priority. If several rulesets (and a classic protection rule) target the same branch, GitHub aggregates them. If the same rule is defined more than once, the most restrictive version applies. Example from GitHub Docs: a ruleset that needs signed commits and three reviews plus a classic rule that needs linear history and two reviews means the branch needs signed commits, linear history, and three reviews.
Exam traps for D6.4
- Internal ≠ private. Private is an access list. Internal is enterprise-wide read on Enterprise Cloud, built for InnerSource.
- Internal is not on GitHub Team or Free. It requires an enterprise account on Enterprise Cloud.
- Admin can change visibility unless the org locked the control to owners.
- Public forks stay public when you privatize the upstream.
- Force-push and delete are off by default on a protection rule; you opt in to allow them.
- Admins bypass by default. “Do not allow bypassing the above settings” is the lock.
- Strict versus loose is only about whether the head must be up to date with the base, not about whether checks exist.
- CODEOWNERS does nothing on merge until the protection rule (or a ruleset) requires code-owner reviews.
- One classic rule at a time. If the stem complains that two classic patterns fight, the product answer is rulesets (or convert the classic rule).
A company on GitHub Enterprise Cloud wants engineers in every organization under the enterprise account to read a shared library using open-source-style collaboration, without publishing the code on the public internet. Which visibility matches that InnerSource goal?
A branch protection rule requires status checks before merging. The team wants GitHub to refuse the merge until the pull request branch includes the latest commits from the base branch. Which required-status-check mode is that?
A repository administrator merges a pull request into protected main even though required reviews are incomplete. What does GitHub document as the default, and how do you stop that bypass?