Two settings decide how far code can travel inside your enterprise, and how far it can travel out of it.
They are usually configured once, by whoever set up the enterprise, based on an instinct about risk rather than a model of it — and then they quietly shape how every team collaborates for the next five years.
The short answer
Section titled “The short answer”Visibility policy controls which visibilities exist and who may change them. At the enterprise level: whether members may create repositories at all, which visibilities they may choose, and whether repository admins or only organisation owners may change visibility.
Forking policy controls whether private and internal repositories may be forked. The options are to allow forking, never allow it, or delegate the decision to organisation owners.
Both are available as enterprise policies, applying enterprise-wide, and as targeted repository policies which GitHub documents as being in public preview.
The trade-off is the same in both cases: restriction reduces the surface over which code can spread, and it removes the collaboration paths that make an enterprise more than a collection of teams.
What forking actually does
Section titled “What forking actually does”Precision here prevents most bad policy decisions.
A fork is a copy of a repository with a recorded relationship to its parent. The relationship is what enables the pull request back, and what makes the fork network a thing GitHub reasons about.
A fork of a private or internal repository inherits that visibility. A fork of an internal repository is internal; it cannot be made public while the parent is not.
Enterprise members may fork internal repositories into any organisation where they can create repositories, and organisation owners can additionally permit forks owned by user accounts.
Push rulesets apply to the entire fork network. A file-size or path restriction on a repository reaches its forks, which is what makes push rules a durable control rather than one bypassable by forking.
A fork is a full copy of history. Everything in the parent’s history exists in the fork, including anything sensitive that was removed from the tip but remains in old commits.
The case for allowing forks
Section titled “The case for allowing forks”Forking is the innersource contribution path. Someone in another team fixes a bug in your library by forking, changing, and opening a pull request. No permission grant, no ticket, no waiting.
The alternative is worse. Without forking, contributing requires push access to a branch in the repository — a much stronger grant than the ability to propose a change. Disallowing forks pushes organisations toward handing out Write access, which is the opposite of what the policy intended.
It is how open source works, and innersource is the same pattern. The whole point of internal visibility is to enable this, and disabling forks removes most of the benefit.
Experiments need somewhere to live. A developer trying an approach they may abandon should not be creating branches in a shared repository.
The case for restricting forks
Section titled “The case for restricting forks”Sprawl. Forks accumulate. A repository forked eighty times has eighty stale copies of its history, most abandoned, all counting toward organisation repository counts and all appearing in search.
Divergence. A fork that lives for a year is a parallel codebase. People find it, use it, and are surprised it is out of date.
Persistence past access. A fork in somebody’s user account survives changes to their team membership. It does not survive them leaving the enterprise under managed users — but under other configurations, the boundaries are worth checking rather than assuming.
Governance gaps. A fork inherits push rules through the fork network, but not everything else. Rulesets targeting the parent by property do not automatically apply to a fork in another organisation with different properties.
These are real and they are mostly manageable. Stale forks can be reported and cleaned up; divergence is a documentation problem; the persistence question is an offboarding one. Disabling forking is a large hammer for problems that mostly have smaller ones.
The recommended position
Section titled “The recommended position”Allow forking of internal repositories within the enterprise. This is what internal visibility is for, and blocking it makes innersource unavailable while pushing teams toward broader write grants.
Restrict forks owned by user accounts if you want forks to be discoverable and governed. Organisation-owned forks are visible in the organisation and subject to its policies; personal forks are neither.
Be more careful with private repositories. A private repository has a deliberately restricted audience, and a fork copies it into another location where the audience may differ. Delegating this to organisation owners is reasonable, since they know their repositories.
Report on forks rather than preventing them. A monthly list of forks with no activity in six months, sent to their owners, addresses the sprawl problem without removing the contribution path.
And separate the two questions. “Should people be able to propose changes to other teams’ code” and “should stale copies accumulate” are different problems with different answers, and a single forking policy conflates them.
Outside collaborators and the outer boundary
Section titled “Outside collaborators and the outer boundary”Forking policy governs movement inside the enterprise. Outside collaborator policy governs the boundary itself, and the two are usually set independently when they should be considered together.
Who may invite outside collaborators is an enterprise policy with four positions: members, organisation owners, enterprise owners only, or delegated.
Allowing members to invite is the permissive default, and it means any member can grant repository access to any GitHub account. That is a real boundary decision, not an administrative detail — the person invited becomes able to read and possibly write a repository, and nothing in the identity provider knows about them.
This is the gap in most enterprise identity models. SCIM provisions and deprovisions members; outside collaborators are invited directly and are not in that flow. When the contractor’s engagement ends, the identity provider removes nothing, because it never knew.
Which makes outside collaborators the population that needs a review process most, and usually has one least. See access reviews and offboarding.
They cannot read internal repositories, which is the one structural protection. Whatever else an outside collaborator is granted, internal visibility does not reach them.
Under Enterprise Managed Users the boundary is much harder. Managed accounts cannot collaborate outside the enterprise, and the outside-collaborator model works differently. If your enterprise depends on external collaboration, verify how that works under EMU before adopting it — this is one of the constraints that most often surprises enterprises mid-migration.
Visibility policy
Section titled “Visibility policy”The enterprise can specify which visibilities members may create — public, private, internal — and whether members may create repositories at all.
Restricting public creation is the common posture for enterprises that are not deliberately publishing. Making something public is the only truly irreversible action here, because clones and forks made during the window persist regardless of what happens next.
Restricting visibility changes to organisation owners is the second control, and it is the more important one. Creating a public repository is usually deliberate; changing an existing internal repository to public is the accident.
Under Enterprise Managed Users the question is partly settled for you. GitHub documents that “Managed user accounts cannot create public content or collaborate outside your enterprise”, and that only private and internal repositories can be created in enterprise-owned organisations. See Enterprise Managed Users.
“For security reasons, you cannot change the visibility of a fork.”
Section titled ““For security reasons, you cannot change the visibility of a fork.””This is the message GitHub’s repository settings show when someone tries to make a fork public or private. A fork shares its parent’s object storage and belongs to the parent’s fork network; its visibility follows the parent’s, and GitHub will not let the two diverge, because a private parent’s objects could become reachable through a public fork.
The practical consequences for policy:
- A private repository’s forks stay private, and a public one’s stay public. Restricting forking is therefore about where copies live, not about whether they can leak visibility.
- To publish work that started as a fork, create a new repository and push the history to it
(
git push --mirrorfrom a fresh clone), rather than trying to change the fork’s setting. GitHub’s documentation on fork visibility describes the same constraint. - Detaching a fork from its network — turning it into a standalone repository — is a GitHub Support request, not a setting. Plan for it if a fork is expected to outlive its parent.
Managing fork sprawl without prohibition
Section titled “Managing fork sprawl without prohibition”If you allow forking — and you should — the sprawl is real and worth managing actively.
Inventory the forks. The API exposes a repository’s forks, and a fleet-wide sweep produces the picture. Most enterprises have never looked, and the number is usually larger than expected.
Classify them. A fork with an open pull request is doing its job. A fork with commits ahead of the parent and no pull request is either abandoned work or a divergent copy somebody is using. A fork with no commits at all is a clone somebody made and forgot.
The last category is the majority, and it is the easiest to address: a report to the owner asking whether they still need it resolves most of them.
Watch for forks that diverge and persist. A fork with a hundred commits ahead of the parent, six months old, is a parallel codebase. Somebody is depending on it. That is a conversation, not a cleanup — and it usually reveals that the parent rejected or ignored a contribution.
Which is the useful diagnostic. Long-lived divergent forks are a symptom of an innersource process that does not work. If contributions were reviewed and merged, the forks would be short-lived. Fixing the review latency does more for fork sprawl than any policy.
Deleting a fork is the owner’s call, and it should be. A central team deleting forks it does not understand will delete something somebody needed, once, and never be trusted again.
Forks and CI
Section titled “Forks and CI”An operational consequence that catches enterprises out.
Workflows triggered by pull requests from forks run with restricted permissions by default, and do not have access to repository secrets. This is deliberate and correct — otherwise anybody who can fork could exfiltrate every secret in the repository by opening a pull request.
Which means innersource contributions may not pass CI if the CI requires secrets. The pull request is blocked by a failing check that has nothing to do with the change.
The common workarounds and their trade-offs:
- Split the workflow. Tests that need no secrets run on fork pull requests; tests that do run after a maintainer’s approval or on merge. This is the correct answer and it takes work.
- Approval-gated workflow runs. A maintainer approves the run for a first-time contributor. Reasonable, and it adds latency to exactly the contributions you were trying to encourage.
- Running privileged workflows against fork code. Do not. This is the pattern that turns a fork pull request into arbitrary code execution with your secrets, and it is one of the best-known CI vulnerabilities.
Plan for this before enabling innersource broadly, or the first wave of external contributions will all fail CI and everybody will conclude the model does not work. See Actions governance.
Designing a publishing path
Section titled “Designing a publishing path”If your enterprise does publish, the policy should route it rather than block it.
A deliberate path beats a prohibition. Teams that need to publish will find a way — a personal account, a different platform — and a path you control is better than one you do not.
-
Restrict public creation and visibility changes to a small group, or to a delegated approval flow.
-
Define what review is required. Full-history secret scan, licence check, legal or export review where applicable, and a named owner for the published repository.
-
Make the request easy. A form or an issue template, with a stated turnaround.
-
Publish into a designated organisation rather than wherever the code happens to live. Public repositories need different settings — different branch protections, a code of conduct, a security policy, an issue triage process.
-
Record the decision. What was published, when, approved by whom.
-
Review published repositories periodically. An abandoned public repository under the company name is a reputational and a security problem.
Going the other way: archiving and unpublishing
Section titled “Going the other way: archiving and unpublishing”The reverse operations are less discussed and worth understanding, because the asymmetry is severe.
Making a public repository private is not an undo. Clones and forks made while it was public persist. Search engines may have indexed it. Package registries may have cached artifacts built from it. The content is out.
Which means the correct response to an accidental publication is not “make it private and move on.” It is: assess what was exposed including full history, rotate any credentials found, follow your incident process, and only then change the visibility. The visibility change stops further spread; it does not undo what happened.
Archiving is different from unpublishing. An archived repository is read-only but still visible at its current visibility. It is the right end state for a repository that should be preserved but not changed, and it is covered in repository lifecycle.
Deleting a public repository leaves forks behind. The fork network survives its parent. A fork can be promoted, and the code continues to exist under somebody else’s account.
Which is worth knowing before deletion is proposed as a remedy. Deleting rarely removes anything; it mostly removes your ability to see and govern what remains.
Plan the exit at publication time. Who owns this if the team disbands, what happens when it is no longer maintained, and what the archive criteria are. A public repository with no exit plan becomes an abandoned one under your organisation’s name.
What to actually configure
Section titled “What to actually configure”A summary position, for an enterprise that has not decided.
| Setting | Recommended | Why |
|---|---|---|
| Repository creation | Members may create | A queue gets bypassed; govern creation instead |
| Visibilities members may create | Private and internal | Public should be a deliberate, reviewed act |
| Visibility changes | Organisation owners, or delegated approval | Widening access is the accident to prevent |
| Forking internal repositories | Allowed within the enterprise | This is what internal visibility is for |
| Forks owned by user accounts | Restricted | Keeps forks discoverable and governed |
| Forking private repositories | Delegated to organisation owners | They know their repositories |
| Public repositories | In a designated organisation | Different settings, different attention |
Every one of these is defensible in a different direction for an enterprise with a different risk posture. What is not defensible is having them set to whatever they were on the day the enterprise was created, with nobody able to say why.
Write down the reason for each. That document is worth more than any particular configuration, because it is what lets the next administrator change a setting deliberately rather than being afraid to touch it.
Common mistakes
Section titled “Common mistakes”Disabling forking to prevent code spread. It pushes teams toward broader write access instead.
Treating forking as the disclosure risk. The person forking could already read it; the risks are persistence and history propagation.
Allowing visibility changes by repository admins. Widening access should be deliberate.
Changing to public without a full-history scan. The tip is not the exposure surface.
No publishing path. Teams publish anyway, through channels you do not control.
Publishing from the same organisation as internal work. Public repositories need different settings and different attention.
Never reviewing forks. Sprawl is real even when forking is the right policy.
Assuming forks inherit all governance. Push rules follow the fork network; property-targeted rulesets do not automatically.
Auditing the current position
Section titled “Auditing the current position”Before changing anything, find out what you actually have. Most of this is a day’s work and it routinely produces surprises.
Count repositories by visibility, per organisation. The ratio tells you what your enterprise’s real default is, regardless of what the policy says.
List every public repository. For each: does it have a named owner, has it had activity this year, and was it published deliberately? An abandoned public repository under the company name is both a reputational and a security exposure.
Search the audit log for visibility changes. Every widening — private to internal, internal to public — in the retention window. Each one should have a reason, and the ones that do not are the finding.
Count forks, and count how many are owned by user accounts versus organisations.
List outside collaborators across the enterprise, with what they can access and when they were invited. This is the list that is most often stale, and the exercise of producing it is frequently the argument for changing the invitation policy.
Check what a new repository gets by default. Create one in a sandbox organisation and record the visibility, the forking setting and the permissions. That is what most repositories in your enterprise actually have, because most were created without anybody choosing.
Compare all of it to the policy you believe you have. The gap between the configured policy and the observed estate is the honest measure of how well governance is working, and it is almost always wider than expected.
Mental model
Section titled “Mental model”Visibility decides the audience; forking decides how code moves within it. Restricting forks does not keep code contained — it redirects collaboration into broader permission grants. The genuine risks of forking are stale copies and history propagation, and both have smaller remedies than prohibition.
What you learned
Section titled “What you learned”- Enterprise policy controls which visibilities members may create and who may change visibility
- Forking policy allows, forbids, or delegates forking of private and internal repositories
- Forks inherit the parent’s visibility and cannot be made public while the parent is not
- Push rulesets apply to the entire fork network, which makes push rules resistant to fork-based bypass
- A fork copies the full history, including anything removed from the tip
- Disabling forking removes the innersource contribution path and pushes teams toward write grants
- Restricting user-account-owned forks keeps forks discoverable and governed
- Visibility changes to public expose the entire history, so a full-history scan must precede them
- A deliberate publishing path is better governance than a prohibition
Exercise
Section titled “Exercise”Use an enterprise you administer.
-
Find your current forking policy for private and internal repositories. Predict: did you know what it was?
-
Find who can change repository visibility. Repository admins, or organisation owners?
-
List forks of your most-used internal repository. How many have had activity in the last six months?
-
Pick one fork with no recent activity. Work out whether it should still exist.
-
Search the audit log for visibility changes in the last year. Were any of them to public?
-
If your enterprise has public repositories, check whether each has a named owner and recent activity.
-
Design the publishing path you would want, including who approves and what they check.
-
Decide whether your forking policy is the one you would choose today, and write down why.