Every open source contribution on GitHub starts with a single action: forking a repository. But what is a fork in GitHub, and why does it matter for your development workflow?
A fork creates a personal copy of someone else’s repository under your own account. It’s how millions of developers propose changes, experiment with code, and contribute to projects they don’t own.
If you’ve ever wondered how the fork-and-pull request model actually works, or how forking differs from cloning and branching, this guide breaks it all down. You’ll learn the mechanics behind forking, when to use it, how to keep your fork in sync, and the mistakes that trip up even experienced developers.
What Is a Fork in GitHub
A fork in GitHub is a personal copy of someone else’s repository that lives under your own GitHub account. It duplicates the entire codebase, including all files, branches, and commit history, into a separate repository you fully control.
The original repository stays untouched. Your fork operates independently, but it keeps a link back to the upstream source.
That connection is what makes forking different from just downloading a ZIP file. You can pull in updates from the original project whenever you want. You can also send your changes back through a pull request.
Forking is a GitHub platform feature, not a core Git command. The git command-line tool doesn’t have a “fork” operation built in. GitHub added this as a one-click feature to make open source contribution faster and more accessible.
Gitnux research found that 100 million new repositories were forked in 2023, a 20% jump from the prior year. Forks made up 25% of all new repository creations on the platform that year.
The GitHub Octoverse 2025 report puts the platform at over 180 million developers and 630 million total repositories. A big share of that growth comes directly from forking activity.
Look, a fork is basically your sandbox. You get full commit access, you can create branches, delete things, experiment wildly. None of it touches the original project. And if you build something the maintainers like, you submit a pull request to merge it back.
That’s the whole model. Fork, change, propose. The original owner decides what gets merged.
How Forking Works on GitHub
Click the “Fork” button on any public repository page. GitHub copies the repo, full history included, into your account. Takes a few seconds.
What carries over: all branches, all commits, all code files. What doesn’t: stars, watchers, issues, and wiki content. Your fork starts clean in those areas.
GitHub automatically sets the original repository as the “upstream” source. This relationship is visible on your fork’s page, right below the repository name. You’ll see a small “forked from [owner/repo]” label.
Fork vs. Clone
People mix these up constantly. Here’s the actual difference.
| Action | Where It Lives | What It Does |
|---|---|---|
| Fork | Your GitHub account (remote) | Creates an independent copy of a repository on GitHub |
| Clone | Your local machine | Downloads a repository to your computer for local development |
A clone is a local Git operation. You run git clone and get the files on your machine. A fork is a GitHub operation that happens on the server side.
Most developers do both. Fork the repo first, then clone their fork locally. That way they have a remote copy they own and a local copy they can work in.
You can clone without forking. But if you don’t have write access to the original repo (which you won’t on most open source projects), you’ll have no way to push changes back. That’s where the fork comes in.
Why Developers Fork Repositories
The primary reason is open source contribution. You find a bug in someone’s project, or you want to add a feature. You don’t have write access. So you fork, make the fix, and open a pull request.
The 2024 Open Source Software Funding Report from GitHub, the Linux Foundation, and Harvard University found that organizations globally contribute over $7.7 billion annually to open source. The fork-and-pull model is the backbone of that contribution pipeline.
But contributing upstream isn’t the only reason people fork. Here are the others:
- Experimentation: testing changes without risk to the original project
- Starting a new project: using an existing repo as a foundation for something different
- Maintaining abandoned projects: keeping a dead project alive when the original maintainer walks away
- Custom versions: running a modified build for specific needs that don’t align with the upstream direction
That last one is more common than you’d think. A CMU research study on GitHub forks found that “hard forks” (permanent divergences from the original) account for a real chunk of forking activity across the platform’s tens of millions of forks.
Google’s 2024 open source report noted that Alphabet employees interacted with more than 19,000 public repositories on GitHub that year. Many of those interactions start with a fork.
Forking and Pull Requests
Forking and pull requests are joined at the hip. You almost never see one without the other in the open source world.
The workflow goes like this:
- Fork the repository
- Clone your fork locally
- Create a new branch for your changes
- Make your edits, commit them
- Push the branch to your fork
- Open a pull request from your fork to the upstream repository
The Octoverse 2025 report showed monthly pull request merges averaging 43.2 million, a 23% year-over-year increase. A large percentage of those PRs originate from forked repositories, especially in open source.
One thing that trips people up: always create a feature branch on your fork before making changes. Don’t commit directly to main. Took me longer than I’d like to admit to learn that. If you commit to main, you’ll have a messy time syncing with upstream later, and your pull request will include unrelated commits.
After you submit the PR, the project maintainer reviews it. They might request changes, approve it, or close it. Your fork stays intact either way.
The whole software development process for open source projects depends on this fork-and-pull model working well. It’s how strangers on the internet build software together without stepping on each other’s code.
How to Keep a Fork in Sync with the Upstream Repository
Your fork falls behind the moment the original repository gets new commits. This happens fast on active projects.
Two ways to sync:
Option 1: GitHub’s web UI. GitHub added a “Sync fork” button directly on your fork’s page. Click it, and your default branch pulls in the latest changes from upstream. Quick and painless for simple cases.
Option 2: Git CLI. This gives you more control and works better when you have local changes to manage.
“ git remote add upstream https://github.com/original-owner/original-repo.git git fetch upstream git checkout main git merge upstream/main `
Some developers prefer git rebase over git merge here. Rebasing keeps your commit history linear, which makes the log cleaner. But it rewrites history, so don't rebase commits you've already shared with others.
How often should you sync? On projects where the Octoverse data shows nearly 1 billion commits pushed in 2025, active repos can change daily. Sync before starting any new work on your fork. Always.
Failing to sync is the #1 cause of merge conflicts when submitting pull requests. Your fork drifts further from upstream every day you don’t update it, and eventually your changes won’t merge cleanly.
Fork vs. Branch
This is probably the most common confusion around version control on GitHub, especially for newer developers.
| Feature | Fork | Branch |
|---|---|---|
| Creates | A whole new repository | A new line of development within a repo |
| Requires write access | No | Yes |
| Lives on | Your GitHub account (separate repo) | The original repository |
| Best for | External contributors | Internal team collaboration |
Branches exist inside a single repository. Everyone with write access can create them. They’re cheap, fast, and ideal for internal team collaboration.
Forks create entirely separate repositories. Anyone can fork a public repo, no permissions needed. That’s why open source projects rely on forks for outside contributions.
Most organizations actually use both. Internal developers work on branches within the main repo. External contributors fork the repo, make their changes, and submit pull requests back. With 92% of Fortune 100 companies now using GitHub according to CoinLaw, this mixed model is the standard approach for software development teams.
A Git workflow like Gitflow or trunk-based development typically uses branches for internal work. The fork-and-pull model handles everything coming from outside the core team.
Quick rule of thumb: if you have push access, branch. If you don’t, fork.
Forking Private Repositories
Public repos can be forked by anyone. Private repos are a different story.
By default, GitHub disables forking for private repositories at the organization level. The owner has to explicitly turn it on through the organization’s “Member privileges” settings. Even then, they can control it per repository.
According to GitHub Docs, private forks inherit the permissions structure of the upstream repository. Team permissions carry over, but individual permissions do not. This means if the upstream gives read/write access to a specific team, that same team automatically gets access to the fork.
A few rules that catch people off guard:
- Forks of private repos always stay private. You can’t change their visibility.
- You can’t fork a private repo to an organization using GitHub Free
- External collaborators don’t get access to forks of org-owned private repos (unless explicitly added)
- When a collaborator loses access to the original, their private fork gets deleted
GitHub Enterprise adds another layer. Enterprise owners can enforce fork policies across all organizations they manage. A team-level admin might want to allow forking, but the enterprise policy can override that.
Security matters here. The GitGuardian State of Secrets Sprawl 2025 report found that 35% of private repositories contained plaintext secrets, with hardcoded passwords appearing 3x more often in private repos than public ones. Forking a private repo doesn’t automatically protect sensitive data inside it.
For teams working under strict software compliance requirements, the fork policy configuration is one of the first things to lock down.
Common Mistakes When Working with Forks
Forks are simple to create. Working with them cleanly over time is where things get messy.
Committing Directly to Main
The most common beginner mistake. You fork a repo, clone it, and start making changes right on the main branch.
The problem shows up later. When you try to sync with the upstream, your personal commits collide with incoming changes. Your pull request picks up unrelated commits. Everything gets tangled.
Always create a new branch before touching any code. Keep main clean and reserved for syncing with upstream.
Forgetting to Sync Before New Work
Active open source projects move fast. The Octoverse 2025 report showed developers pushed nearly 1 billion commits across GitHub that year.
If you start a feature on a stale fork, your branch diverges immediately. The longer you wait to sync, the worse the merge conflicts get.
Run git fetch upstream and merge before creating any new branch. Every time. No exceptions.
Pushing Sensitive Data to a Public Fork
GitHub’s own data shows more than 39 million secrets were leaked across the platform in 2024 alone. API keys, database credentials, authentication tokens, all accidentally committed and pushed.
Forks of public repos are public. That’s not going to change. If you push an API key to your fork, it’s immediately exposed.
| Mistake | Risk Level | Fix |
|---|---|---|
| Committing to main | Medium | Always use feature branches |
| Stale fork | Medium | Sync before starting new work |
| Exposed secrets | Critical | Use .gitignore and environment variables |
| Wrong remote | Low | Verify remotes using git remote -v |
Use a .gitignore file to exclude config files that hold secrets. Better yet, store credentials in environment variables or a secrets manager. The code review process should catch these before they reach production, but prevention beats detection.
Confusing Origin and Upstream
origin: your fork on GitHub (the remote you cloned from).
upstream: the original repository you forked.
Mixing these up means pushing code to the wrong place or pulling from the wrong source. Run git remote -v to see exactly where your remotes point. If upstream isn't listed, you need to add it manually.
Forking Etiquette in Open Source
Forking is a right, not a privilege, on public repositories. But there are unwritten rules the community takes seriously.
Respecting the License
The Black Duck 2024 OSSRA report found that 53% of audited codebases contained open source with license conflicts. When you fork a project, you inherit its license. You can’t just swap it for something else.
MIT, Apache 2.0, and GPL are the most common licenses on GitHub. Each has different requirements around attribution, redistribution, and derivative works.
- MIT: keep the copyright notice, use the code however you want
- Apache 2.0: include the license, state changes made, respect patent grants
- GPL: any derivative must also be open sourced under the same terms
The Open Source Guides from GitHub itself clarify that a public repo without a license doesn’t mean free-for-all. GitHub’s Terms of Service allow viewing and forking, but not using the code in your own projects without explicit permission.
Credit and Attribution
GitHub shows a “forked from” label on every fork. That label connects your repo back to the original.
Don’t remove it or try to obscure where the code came from. If you’re building on someone’s work, the community expects you to be upfront about it. Passing off a fork as wholly original work burns trust fast.
Write clear documentation in your README that explains what you changed and why you forked.
When to Maintain a Long-lived Fork
Most forks should be temporary. You make a change, submit a pull request, and eventually delete the fork once it’s merged or rejected.
But some forks live on for years. This makes sense when the original project is abandoned, or when you need the project to go in a direction the maintainers won’t support. The CMU research on GitHub forking found that permanent divergences (hard forks) happen regularly, sometimes producing successful independent projects.
If you go this route, keep contributing fixes back upstream when possible. The open source ecosystem works because people give back, not just take. Organizations investing in collaboration between development and operations teams already understand this. The same principle applies to the broader open source community.
FAQ on What Is a Fork in GitHub
What does forking a repository mean?
Forking creates a personal copy of someone else’s repository under your GitHub account. The copy includes all files, branches, and commit history. You get full control without affecting the original project.
Is a fork the same as a clone?
No. A fork lives on GitHub as a separate remote repository. A clone downloads a repo to your local machine. Most developers fork first, then clone their fork to work locally.
Can I fork a private repository?
Only if the repository owner or organization allows it. By default, GitHub disables forking on private repos. Forks of private repositories always stay private and inherit team permissions from the original.
How do I keep my fork updated?
Add the original repo as an upstream remote using Git CLI, then run git fetch upstream and merge. GitHub also offers a "Sync fork" button on your fork's page for quick updates.
What is the difference between a fork and a branch?
A branch exists inside a single repository. A fork creates an entirely separate repository. Use branches for internal team work. Use forks when you don’t have write access to the original project.
Do I need permission to fork a public repository?
No. Anyone with a GitHub account can fork any public repository without asking. That’s by design. It’s how open source contribution works on the platform.
What happens to my fork if the original repo is deleted?
Your fork stays intact. It becomes a standalone repository with its own network. You lose the ability to sync with upstream, but all your code and commit history remain.
Can I submit changes from my fork back to the original?
Yes. Open a pull request from your fork to the upstream repository. The project maintainer reviews your changes and decides whether to merge them. This is the standard open source contribution workflow.
Does forking copy issues and stars?
No. A fork copies the codebase, branches, and commit history only. Issues, stars, watchers, and wiki content do not carry over. Your fork starts fresh in those areas.
When should I fork instead of cloning directly?
Fork when you want to contribute to a project you don’t own, or when you need an independent copy on GitHub. Clone directly when you already have write access and just need local files.
Conclusion
Understanding what is a fork in GitHub comes down to one idea: it gives you a safe, independent copy of any public repository so you can build, test, and contribute without risk to the original project.
The fork-and-pull request workflow is how the open source community operates at scale. Millions of pull requests get merged every month through this model. It works because it separates ownership from contribution.
Keep your fork synced with the upstream repository. Use feature branches instead of committing to main. Watch for exposed secrets. Respect the project’s license.
Whether you’re fixing a bug in someone else’s code or spinning up a completely new project from an existing source control setup, forking is the starting point. Learn the mechanics, follow the etiquette, and you’ll contribute with confidence.
Many of his resources are available on various design marketplaces and for free on Codepen.
Over the years, he's worked with a range of clients and contributed to design publications like Design Your Way, Designmodo, WebDesignerDepot, WPDean, Speckyboy, and Slider Revolution among others.
- Tailwind CSS Cheat Sheet - June 9, 2026
- The Stuff Nobody Tells You About Hiring Web Design Services - June 9, 2026
- How to Create a Pull Request in GitHub Easily - June 8, 2026
