Fork networks share Git data, even after a fork is deleted

Repositories in the same fork network share Git data. GitHub's documentation warns that data from any repository in a network may be accessed from any other repository in it, including the upstream, and that this continues even after a fork is deleted. Treat commits pushed to a forked repository as possibly shared.

What GitHub documents

The relevant page covers what happens to forks when a repository is deleted or changes visibility. Three points matter:

• If a public upstream is deleted, one active public fork is promoted to become the new upstream of the network.
• If a public repository is made private, its existing public forks stay public, in a separate network no longer connected to it.
• Git data is shared across the network, and the warning about access from any repository in the network holds after a fork is deleted.

Why this matters

People assume that deleting a fork or flipping a repo to private erases what was in it. The documentation says not to assume that. If a secret was committed to any repository in a network, rotating it is the real fix, as the guidance on removing secrets from history also stresses.

Habits that help

1. Never commit a secret, even to a private fork. A private fork of a public project can share a network with public data.
2. Rotate on exposure. Once a credential has been pushed anywhere in a network, rotate it.
3. Know your network. Before making a repository private or public, read GitHub's page on visibility changes and consider stars, watchers, dependency graph and alerts, which the page says can be affected.
4. Prefer internal forks to personal ones for company code, so ownership is clear and offboarding covers them.
5. Review old forks. Fork lists are an inventory of copies of your code.

For maintainers of public projects

Assume anything that was ever pushed to your public repository, or to a fork of it, may remain reachable by its commit hash. Do your rotation first, then ask GitHub Support about cleanup, as their guidance describes.

When you offboard a developer, include their forks in the checklist. A personal fork of a private company repository can hold the full history, and it belongs to an account you may not control after they leave. Ask the person to delete or transfer it, and check the organization's list of forks. If a fork held anything sensitive, treat that as exposure and rotate, rather than relying on the deletion alone.

Quick check

Safeguard asset discovery can help you list repositories and copies you own across providers, and the free scan at gold.safeguard.sh/scan shows dependency risk quickly.

Sources

• What happens to forks when a repository is deleted or changes visibility, GitHub Docs
• Removing sensitive data from a repository, GitHub Docs

Last reviewed: 19 October 2026.