What actually changes when a GitHub repository is switched from public to private?
answer
- Controls future reads, not past copies
- Forks live in other people's accounts
- Clones are complete copies of history
- Rotation, not concealment, is the fix
- Public runner minutes are billed differently
basics
~20 sAnonymous read stops and access falls back to organization base permission, teams and collaborators. Existing public forks are split into their own network and keep the code they already have, so anything published while the repository was public must be treated as permanently exposed.
solid answer
~50 sFlipping visibility changes **who may read from now on**, not what has already escaped. After the switch, unauthenticated users lose access and every remaining reader gets in through the organization's base permission, a team grant or a direct collaborator grant. The part candidates miss is the fork network: existing public forks are **detached into a separate network** and continue to exist with the code they already hold. Add ordinary clones, mirrors and third-party caches, and any commit that was ever pushed publicly should be assumed to be public forever. A credential exposed in that history must be **rotated**; making the repository private is not a remediation. Operationally, links from outside break, unauthenticated CI that cloned it fails, and Actions on a private repository now draws on the account's included minutes rather than running free as it does for public repositories. Changing visibility needs repository admin, and organizations can restrict it to owners.
go deeper
Know that public means anyone on the internet can read and clone, private means only people with a grant, and that changing this needs repository admin.
Explain the mechanics: who loses access, that existing forks are detached rather than deleted, and that unauthenticated integrations will need credentials afterwards.
Draw the line between controlling future access and undoing past disclosure, and be ready to say plainly that an exposed credential must be rotated regardless of what the visibility setting now says.
Own the policy: who is allowed to change visibility at all, what a pre-publication audit must cover, and how the organization sequences rotation, communication and integration migration around such a change.
## What the switch is Repository visibility on GitHub is a property of the repository: **public** (readable by anyone on the internet), **private** (readable only by principals with an explicit grant), and in organizations under an enterprise, **internal** (readable by enterprise members without a per-repository grant). Changing it requires repository admin, and an organization can withhold that lever from members so only owners may flip it. ## What genuinely changes **Anonymous read stops.** After the switch, access is decided entirely by the grant sources: organization base permission, team grants, direct collaborator grants, and organization ownership. Anyone who was reading purely because it was public is now out. **External integrations break in predictable ways.** Anything that cloned over unauthenticated HTTPS — a documentation build, a package fetched straight from the repository URL, a downstream CI job — now needs a credential. Deep links shared in issues, blog posts and Stack Overflow answers return not-found to logged-out visitors, which is indistinguishable from deletion for an outside reader. **Existing public forks are detached.** They are split off into their own network rather than being deleted; GitHub cannot un-publish a repository that lives in someone else's account. Those forks retain everything they had already fetched. **Actions billing changes.** Standard GitHub-hosted runners are free for public repositories; on a private repository, workflow runs draw on the account's included minutes. A busy repository quietly becomes a cost line the day it goes private. ## What does not change: the history is already out This is the senior point. Every clone anyone ever made is a complete copy of the history. Forks, mirrors, code search engines, package caches and scrapers all hold copies you do not control. Making the repository private stops *new* readers; it does nothing about the copies. The consequence is unambiguous: **if a secret was ever pushed to a public repository, rotate it.** Do not treat the visibility flip, a rewritten history or a deleted branch as remediation — all three change what your repository serves today and none of them reaches the copies. The same logic applies to source code you no longer want published: you can stop distributing it, but you cannot recall it. ## The other direction Going private-to-public is the higher-stakes move and deserves a checklist, because it publishes the **entire history**, not the current tree: every branch and tag, every deleted-but-still-reachable commit, every file that was committed and later removed. It also exposes the issue tracker and pull request discussions, which routinely contain internal hostnames, customer names and stack traces. Anyone who publishes a repository without auditing history and issues first is publishing more than they think. ## Doing it safely Before taking a repository public: scan the full history for credentials rather than the working tree, review issues and pull request bodies, confirm the licence and ownership story, and enable push protection so contributors do not commit a secret into what is now a public repository. Before taking one private: inventory who reads it anonymously today — external CI, docs pipelines, package consumers — and give each a credential or an alternative before the switch, rather than discovering them as broken builds. Communicate that outside links will die. And if the motive for going private is that something sensitive was published, sequence the work correctly: **rotate first**, flip visibility second, and treat the flip as reducing future exposure rather than undoing past exposure. ## What an interviewer is listening for A weak answer describes the setting. A strong one distinguishes *future access control* from *past disclosure*, names the fork network as the concrete reason the distinction exists, and arrives at rotation as the only real remediation for an exposed credential.
- A key was committed to a public repository last month. The team makes the repository private. Is the key safe?No. Clones, forks, mirrors and third-party caches already hold that history and none of them are affected by the visibility change. The only remediation is to rotate the credential and, ideally, to check for use of it in the interim. Removing the line, rewriting history or flipping visibility all change what your repository serves today and reach none of the copies.
- What should you check before taking a private GitHub repository public?Audit the whole history rather than the current tree — credentials, customer data and internal hostnames in deleted files still ship, because every branch, tag and reachable commit becomes visible. Review issue and pull request bodies too, since they leak internal detail. Confirm the licence and ownership, then enable push protection so future contributions are scanned before they land.
- Why can GitHub not simply delete existing forks when a repository goes private?A fork is a separate repository owned by someone else, with its own collaborators and history. GitHub detaches those forks into their own network rather than deleting other people's repositories. Practically this means the code stays available to whoever holds a fork, which is precisely why visibility changes are not a containment mechanism.
saying these in an interview costs you the question
- Treats going private as removing leaked secrets
- Thinks existing forks are deleted on the switch
- Assumes deleting a branch unpublishes its commits
- Publishes a repo without auditing full history
- Forgets unauthenticated CI clones will break