Forking is how most people end up contributing to a project they don’t own. You get your own copy on GitHub, change whatever you want in it, and ask the maintainers to take the changes through a pull request. The copy stays tied to the original, which GitHub calls the upstream repository.
Contributors without write access use forks to fix bugs in open source projects, and developers also use them as a starting point for a new project.
The tie between the two repositories matters in ways people don’t expect. Deleting a private upstream deletes every private fork of it, while deleting a public upstream makes an active public fork the new upstream (GitHub Docs, 2026).
What Is a GitHub Fork?
When you fork on GitHub, you get a new repository under your account with the same code and history as the original. You own it. Push to it, break it, rewrite half of it, and the project you copied from never notices.
The original is the upstream repository, and the fork keeps a visible pointer to it. GitHub Docs says the upstream repository is indicated below the name of the fork, so a fork of github/docs shows “forked from github/docs” under its name.
Each fork is a full Git repository, so it carries its own branches, issues, pull requests, Actions, projects, tags, labels, wikis, members, and discussions. That independence is why forks suit contributors who have no write access to the original.
A fork isn’t a branch, since a branch lives inside one repository and a fork is a separate one. It isn’t a clone either. A clone sits on your computer, and a fork sits on GitHub. And it isn’t a detached duplicate, because it shares history with the upstream and stays connected to it, so changes can travel back through a pull request.
Forking belongs to the hosting platform, GitHub, not to Git itself, which has no fork command of its own.
How a Fork Stays Connected to the Upstream Repository
Shared commit history and membership in a repository network keep a fork tied to its upstream. The network is the group of repositories that all trace back to one original, and it’s what makes a pull request from the fork to the upstream possible.
Fork network and shared history
According to GitHub Docs, a repository network covers the upstream repository plus every fork and fork of a fork under it. A fork’s visibility follows the upstream’s, and if the upstream changes visibility, GitHub can split the forks into separate networks (covered in the table later in this article).
The fork starts out with the upstream’s commits, which is why the two can exchange changes cleanly. Commits made in any repository of the network can be reached from every other one, even after a fork is deleted.
Permissions are separate, though. The fork has its own, while owners of the upstream repository can read every fork in the network.
On your own machine the connection appears as the upstream remote. By convention your fork is origin and the original is upstream, and you add the second one yourself.
Visibility and who can fork
You cannot change the visibility of a fork by itself.
A fork of a public repository is always public. Private repositories follow stricter rules, which GitHub Docs lists as of October 2026:
| Source repository | Where it can be forked | Fork visibility and access |
|---|---|---|
| Public | Personal account or any organization where you can create repositories | Public, like the source; the fork owner controls access |
| Private (the owner must allow forking) | Personal account or an organization on GitHub Team where you can create repositories | Private; team permissions of the upstream carry over, individual permissions do not |
| Private | Organization on GitHub Free | Blocked |
Organizations and repository admins can also switch off forking for private repositories, and enterprise managed users face further limits.
Private forks inherit team permissions from the upstream. Public forks don’t.
Administrators tend to get caught by one thing in particular. When an organization changes its base permissions, existing private forks don’t pick up the change automatically.
How to Fork a Repository on GitHub
Open the repository, click Fork, choose an owner, and click Create fork. The same thing can be done from a terminal with GitHub CLI or from a script with the REST API.
Fork from the web interface
The Fork button is in the top-right corner of the repository page. The form that opens asks for an owner, which can be your personal account or any organization where you can create repositories.
The repository name defaults to the upstream name, so change it if you want to tell the two apart. There’s also a checkbox to copy the default branch only. It skips every other branch, and that’s enough for most open source contributions.
Leave the box unchecked and all branches come along. If you skipped some, they can be added later from the Branches page, per GitHub Docs.
GitHub’s own fork guide uses octocat/Spoon-Knife for practice, which is handy if you’d rather try forking and cloning, then setting an upstream remote, before touching a real project.
Desktop users get a shortcut. If you clone a repository you cannot write to in GitHub Desktop and push a branch, the app offers to create the fork for you (GitHub Docs, as of October 2026).
Fork with GitHub CLI
The command is gh repo fork owner/repo. The manual for GitHub CLI states that the new fork becomes your origin remote by default, and any existing origin gets renamed to upstream.
| Flag | Effect |
|---|---|
| –clone | Clones the fork after creating it |
| –org | Creates the fork in an organization |
| –fork-name | Renames the forked repository |
| –default-branch-only | Copies only the default branch |
Run it with no argument inside a local clone and it forks the current repository.
Fork with the REST API
A POST request to /repos/{owner}/{repo}/forks creates the fork, per the REST API reference (API version 2026-03-10). The body accepts optional organization and name parameters, plus default_branch_only if you want just the default branch.
The call returns 202 Accepted, because forking runs asynchronously. If the git objects are still unavailable after 5 minutes, the reference tells you to contact GitHub Support.
Fine-grained tokens need Administration write and Contents read permissions for this endpoint.
Whichever route you pick, forking creates the repository on GitHub only. Nothing reaches your machine until you clone the fork.
Fork vs Clone vs Branch: Which One Fits?
Without write access to a repository, fork it. With write access, branch. Either way, clone when you need the code on your machine. These solve different problems, which is why they often turn up in the same workflow.
| Attribute | Fork | Clone | Branch |
|---|---|---|---|
| Where it lives | GitHub, as a new repository | Your computer | Inside one repository |
| Owner | You | You (local copy) | The repository owner |
| Write access needed | No | Only to push back | Yes |
| Typical use | Contributing to someone else’s project | Working on code locally | Isolating a feature or fix |
| Where changes go | Pull request to the upstream | Push to the remote you cloned | Pull request or merge in the same repository |
Cloning a repository with git clone combines with a fork instead of competing with it. Fork first to get a copy you own, then clone the fork.
In practice it comes down to access. If you have write access, create a branch and open a pull request in the same repository. If you don’t, fork, clone the fork, and send the pull request to the upstream. Forking with write access only makes sense when you want independence, meaning your own settings, issues, and permissions.
A branch keeps work inside the repository where reviews and protections are already set up and CI already runs. That is why it is the default for teams, and it’s what I’d pick every time I had the access.
GitHub’s Octoverse 2025 found that 81.5% of contributions happened in private repositories. Those authors already have access, so a branch is their normal path and the fork is the exception for outsiders.
Forking inside a team you already belong to has a cost. Each fork is its own repository, so issues, settings, and pull requests split across two places (GitHub Docs).
Contributing Through a Fork: From Clone to Pull Request
Push a feature branch to your fork, then open a pull request from that branch into a branch of the upstream repository. You need the fork because you cannot push to the upstream directly.
- Fork the upstream repository.
- Clone your fork, so origin points to it.
- Create a feature branch.
- Commit your changes.
- Push the branch to origin.
- Open a pull request with the upstream branch as the base and your branch in the fork as the compare branch.
Clone your own fork, not the original. A guide on cloning a GitHub repository covers the URL and authentication choices.
Work on a feature branch instead of the default branch of your fork. That keeps the default branch identical to the upstream and easy to sync later.
After a push, GitHub shows a Compare & pull request banner on the upstream repository. The “compare across forks” link lets you pick the base and head by hand (GitHub Docs, as of October 2026).
Titles and descriptions work as in any pull request on GitHub, and so do reviewer requests. Many projects also document branch naming and commit style in a CONTRIBUTING file, along with their test requirements, so read it before you push.
A few options change how a fork pull request behaves. You can open it as a draft, which marks the work as not ready for review. “Allow edits from maintainers” lets anyone with push access to the upstream commit to your branch, and it’s available on user-owned forks. If your fork contains GitHub Actions workflows, “Allow edits and access to secrets by maintainers” replaces that option.
That last variant carries a risk. A maintainer can edit the fork’s workflows, which can reveal secret values and open access to other branches, according to GitHub Docs.
How to Keep a Fork in Sync With Its Upstream Repository
A fork never updates itself, so it falls behind with every new upstream commit. To catch up, open the Sync fork dropdown on the fork’s page and click Update branch, or fetch the upstream remote and merge it into your default branch locally.
Sync from the web interface
People with write access to the fork can sync it from the browser, per GitHub Docs.
- Open the main page of the fork.
- Select the Sync fork dropdown above the file list.
- Review the upstream commits, then click Update branch.
If the upstream changes conflict with commits in your fork, GitHub prompts you to open a pull request to settle them. Resolving conflicts in GitHub works the same way here as anywhere else.
Honestly, the button is easier than the command line for most people. The terminal route is there for when you’re already working locally.
Sync from the command line
This route needs an upstream remote pointing at the original repository. After that, the commands run in order:
- Fetch the upstream with
git fetch upstream. - Switch to your default branch using
git checkout main. - Run
git merge upstream/mainto bring the changes in. - Finish with
git push origin main.
The merge only updates your local copy. The push is what updates the fork on GitHub.
Running git fetch downloads upstream commits into local branches named upstream/BRANCH-NAME without touching your files. If your local branch has no unique commits, the merge is a fast-forward. Unique commits can produce conflicts you resolve by hand.
For a fork that lives only on GitHub, gh repo sync owner/fork -b BRANCH-NAME updates it from its parent. The command cannot sync when conflicts exist, and the --force flag overwrites the destination branch (GitHub Docs).
When a Fork Breaks or Does Not Fit
Most fork problems trace back to a few documented rules that tutorials tend to skip. They cover workflows that stop running, an upstream that changes or disappears, a detach that cannot be undone, and a second fork of the same repository.
Actions and workflows
Scheduled workflows are disabled by default when a public repository is forked, according to GitHub Docs. In a public repository they also switch off automatically after 60 days without repository activity.
Re-enable a workflow from the Actions tab of the fork. Until you do, a cron job copied along with the repository does not fire.
This is one reason a fork can behave differently from the project it came from. A passing GitHub Actions setup upstream says nothing about the same setup in your copy.
When the upstream changes or disappears
| Event | Effect on forks |
|---|---|
| Private upstream deleted | All its private forks are deleted |
| Public upstream deleted | An active public fork becomes the new upstream |
| Public upstream made private | Public forks split into a new network and stay public |
| Private upstream made public | Private forks stay private but disconnect into separate private networks |
| Access removed from a private upstream | That person’s forks of it are deleted |
The rules come from GitHub Docs as of October 2026. When someone loses access to a private repository, their local clones are retained, and they are responsible for removing any confidential material from them.
Detaching a fork
Leaving the fork network turns a fork into a standalone repository. It suits work that is heading in a different direction from the upstream.
The leave option only works on a public fork. It also has to be smaller than 1GB, with no child forks attached.
You lose issues, pull requests, wikis, stars, watchers, comments, and child forks. Commit metadata is preserved.
The action is permanent. The repository cannot rejoin the network afterward (GitHub Docs).
Forks that miss a condition take the manual route: bare clone the fork, delete it, create a new repository with the same name, and mirror-push the clone back. Deleting the fork permanently removes its pull requests and configuration, so check how deleting a repository in GitHub works before you start.
Forking the same repository twice
Until a GitHub update announced on 16 February 2023, an organization that already had a fork of a repository could not fork it again. The option was grayed out with a note that a fork already existed in the target organization.
The GitHub changelog entry for that date lifted the block, so you can now fork a repository into another organization more than once, as long as the extra fork gets a unique name. Older guides may still describe the earlier limit.
GitHub Fork FAQ
How is a fork different from a template repository?
A fork carries the entire commit history of the parent and stays linked to the upstream repository, so changes can travel back through a pull request. A template repository starts a new repository with a single commit and is meant as a fresh starting point.
Is a fork the same as a mirror?
No. Mirrors replicate a repository along with all its refs, and they’re meant to stay identical to the source.
Forks go the other way. You change them independently and sync only when you choose to.
Can you fork a repository into the organization that already owns it?
Yes. Since June 2022, a repository can be forked into the same organization as its parent, which suits teams that work inside one organization (GitHub changelog, 2022).
An internal repository can also be forked into another organization of the same enterprise, and the fork keeps its internal visibility.
Can you fork a fork?
Yes. A fork of a fork joins the same repository network as the original.
Visibility still follows the upstream, and you cannot change a fork’s visibility on its own, per GitHub Docs.
Do GitLab and Bitbucket have forks too?
Yes. Both platforms offer the same idea, a copy you own that stays linked to the original project.
Git itself has no fork command, so the feature lives in each hosting platform and the details differ between them.
What to Do First After Forking a Repository
Add the upstream remote first, then create a feature branch, then sync before you open the pull request.
The order follows dependency. No sync command runs without the remote, and a freshly synced base keeps conflicts out of the review.
Never skip the sync. A branch cut from a stale default branch is where conflicts start.
Once the pull request is open, the code review process decides what merges.
This sequence reflects GitHub Docs as verified in October 2026. A change to private fork permissions or organization forking policies would change which checks come first.
- VS Code Extensions That Are Actually Worth Installing - October 13, 2026
- Google Play App Signing Explained - October 11, 2026
- 5 Best NinjaOne Alternatives for Focused Endpoint Management - October 10, 2026
