What Is a Fork in Git?
A complete, beginner-friendly walkthrough of forking — what it actually is, how it differs from cloning and branching, and why it's the backbone of open-source collaboration.
Imagine a popular recipe book at a public library. You can’t scribble your own changes into the library’s copy — that would ruin it for everyone else. Instead, you photocopy the entire book, take your personal copy home, and cross out or rewrite any recipe you like, however you like. Later, if you come up with an improvement the original author might want, you can mail them just that one page and ask if they’d like to include it in the next official edition. A “fork” in Git is exactly this photocopy — your own independent, fully-owned copy of someone else’s project that you’re free to change without asking anyone’s permission first.
1What Is a Fork?
Let’s start with a precise, plain-English definition before touching any mechanics.
The Simple Definition
A fork is a personal, independent copy of someone else’s repository, created under your own account on a hosting platform like GitHub, GitLab, or Bitbucket. It contains the entire history of the original project up to the moment you forked it, but from that point onward, the two copies live completely separate lives — changes in one do not automatically appear in the other.
Forking is like taking a photograph of a family tree and starting your own branch of the family from that snapshot. Your new branch shares the same ancestors as the original, but everything that happens to your branch from now on is entirely your own story.
Why This Concept Exists
Most public projects don’t let random strangers push changes directly into their official repository — that would be chaotic and unsafe. But open-source software depends on outside contributors improving the code. Forking solves this tension perfectly: anyone can copy the project into their own space, make whatever changes they want with zero risk to the original, and then formally propose those changes back through a reviewed process. The original maintainers stay in full control of what actually gets merged in.
Forking is fundamentally a permissions and ownership concept, not a Git command at all. It’s a feature offered by hosting platforms like GitHub — the underlying Git tool itself has no built-in “fork” operation.
2Where a Fork Lives
To understand a fork, it helps to see exactly which repositories exist and how they relate to one another.
Upstream Repository
The source project you forked from, typically owned by someone else or an organization. Conventionally nicknamed “upstream” once you’re working with your fork.
Forked Repository
The independent copy living under your own account on the hosting platform, which you fully own and can configure however you like.
Local Clone
The copy of your fork downloaded onto your own laptop, where you actually write and test code before sending changes back up.
Pull Request
A formal request you open asking the upstream project’s maintainers to review and merge specific changes from your fork into their official repository.
graph LR
U[(Upstream Repository
owned by the project)] -- fork --> F[(Your Forked Repository
owned by you)]
F -- clone --> L[Your Local Machine]
L -- push --> F
F -- pull request --> U
3How Forking Works Internally
Here’s what actually happens on the server the moment you click that “Fork” button.
The platform duplicates the repository
The hosting service creates a full copy of every commit, branch, and tag from the original project, and stores it as a brand-new repository under your account.
Ownership is reassigned
Unlike the original, this new repository’s settings, permissions, and write access belong entirely to you. You decide who else can contribute to your fork.
A link back to the original is remembered
The platform quietly records that your repository was forked from the original, which is what powers the “compare” and “pull request” features later on.
You clone your fork locally
From here, working with your fork is identical to working with any other repository — you clone it to your own machine, create branches, and make commits as usual.
You propose changes back
When your work is ready, you open a pull request comparing your fork’s branch against the upstream project’s branch, and the maintainers decide whether to accept it.
4Fork vs. Clone vs. Branch
These three terms are the ones beginners confuse most often, so let’s separate them clearly.
| Concept | What It Creates | Where It Lives | Who Owns It |
|---|---|---|---|
| Fork | A brand-new, independent repository | On the hosting platform, under your account | You |
| Clone | A local copy of an existing repository | On your own computer | Whoever owns the machine, but tied to the source repo |
| Branch | A new line of development within the same repository | Inside a single repository, local or remote | Shared with everyone who has access to that repository |
If the original project is a house, cloning is making a photograph of the house to study at home, branching is renovating one room while leaving the rest of the house untouched, and forking is buying an entirely separate plot of land and building your own copy of the house on it, free to renovate however you like.
Forking and branching solve a similar problem — letting you experiment safely — but at very different scopes. A branch is for changes you’ll likely bring back into the same project quickly; a fork is for a fully separate copy, often used when you don’t have write access to the original at all.
5Keeping a Fork Up to Date
Since a fork is a snapshot frozen at the moment of creation, the original project keeps moving without you unless you actively catch up.
Because your fork and the upstream repository are entirely separate after the initial copy, any new commits made to the original project will never automatically appear in your fork. If the upstream project is actively developed, your fork can quickly fall behind. To stay current, developers add the original repository as a second remote (conventionally named “upstream”) alongside their fork (“origin”), periodically fetch the latest changes from it, and merge those changes into their own fork’s branches.
A fork typically ends up tracking two remotes at once: “origin” (your own fork, where you push your work) and “upstream” (the original project, which you only ever pull from).
sequenceDiagram
participant Up as Upstream (original project)
participant Fork as Your Fork (origin)
participant Local as Your Local Clone
Up->>Up: New commits added by others
Local->>Up: git fetch upstream
Local->>Local: git merge upstream/main
Local->>Fork: git push origin
6Why Teams and Projects Use Forks
Forking shows up in a few distinct, recognizable situations. Here are the main ones.
Contributing to Open-Source Projects
The single most common reason to fork: you want to fix a bug or add a feature to a project you don’t have write access to, so you fork it, make your change, and submit a pull request.
Experimenting Freely
Developers sometimes fork a project purely to explore or modify it heavily for their own purposes, with no intention of ever contributing back to the original.
Company-Internal Safety Boundaries
Some teams require every developer to work from their own fork of an internal repository rather than pushing branches directly, as an extra layer of access control.
Preserving a Project’s History
If a project is abandoned by its original maintainers, someone can fork it to keep development alive under a new name — this is sometimes called a “hard fork” in open-source culture.
7Advantages and Trade-offs
Forking is powerful, but it isn’t automatically the right tool for every situation.
Advantages
- Lets anyone contribute to a project without needing direct write access to it.
- Keeps the original repository completely safe from experimental or risky changes.
- Gives contributors full ownership and control over their own copy.
- Enables clean, reviewable pull requests that maintainers can accept or reject.
- Preserves the full commit history of the original project at the time of forking.
Disadvantages / Trade-offs
- Requires manual effort to stay synchronized with an actively changing upstream project.
- Adds an extra layer of indirection compared to simply branching within one shared repository.
- Can lead to long-lived, drifting copies if never merged back or updated.
- Managing two remotes (origin and upstream) is an extra concept beginners must learn.
8Best Practices and Common Mistakes
A short checklist that separates smooth, welcome contributions from messy, hard-to-review ones.
Sync with upstream regularly
Pulling in the latest upstream changes often keeps your fork from drifting so far that your eventual pull request becomes difficult to merge.
Create a new branch per change
Making changes on a dedicated branch within your fork, rather than directly on your copy of the main branch, keeps your pull requests focused and easy to review.
Letting a fork go stale for years
An unmaintained fork that never syncs with upstream eventually diverges so much that merging becomes painful or impossible.
Mixing unrelated changes in one pull request
Bundling several unrelated fixes into a single proposal makes it much harder for maintainers to review and accept your work.
Problem
Beginners sometimes fork a repository, make lots of small commits directly on their copy of the main branch, and only afterward realize they want to open a pull request.
Why It’s Harmful
If upstream has moved forward in the meantime, this tangled history makes the pull request messy and hard for maintainers to review cleanly.
Correct Approach
Sync your fork with upstream first, then create a dedicated branch specifically for the change you intend to propose, keeping your main branch a clean mirror of upstream at all times.
9Real-World Examples
Forking sits at the heart of how much of the world’s open-source software actually gets built.
The Linux Kernel Ecosystem
Countless companies and individual developers maintain forks of the Linux kernel, some contributing patches back upstream and others maintaining specialized versions for their own hardware.
Popular Open-Source Libraries
Projects like React, Node.js, and Vue.js receive the vast majority of their outside contributions through the fork-and-pull-request workflow described in this post.
Cryptocurrency “Hard Forks”
The word “fork” entered mainstream tech news partly through cryptocurrency projects like Bitcoin Cash, which began as a fork of Bitcoin’s codebase that then evolved independently.
10Frequently Asked Questions
It’s a platform feature, offered by services like GitHub, GitLab, and Bitbucket. The underlying Git tool has no built-in “fork” command — you could achieve the same effect manually by cloning a repository and pushing it to a brand-new remote location.
No. Once created, a fork is completely independent. You must deliberately pull in upstream changes if you want your fork to stay current.
Only if you already have access to it. Forking copies the repository’s content, so hosting platforms require you to have at least read permission before you can create a fork.
A fork is the copy of the repository itself; a pull request is a separate, later step where you propose that specific changes from your fork be merged into the original project.
Yes — once your changes are accepted upstream, the fork has served its purpose and can be safely deleted, though many developers keep it around for future contributions.
11Summary and Key Takeaways
A fork is your own independent copy of someone else’s repository, created on a hosting platform so you can freely experiment or contribute without needing direct write access to the original. It starts as an exact snapshot of the upstream project but then lives entirely on its own, requiring deliberate effort to stay in sync. Understanding forking — and how it differs from cloning and branching — is essential for anyone who wants to contribute to open-source software or work safely within a permission-controlled team.
Key Takeaways
- A fork is a copy, not a command — it’s a platform feature, not something built into Git itself.
- Full ownership — your fork belongs entirely to you, separate from the original project’s permissions.
- Independent after creation — forks don’t auto-update; you must fetch and merge upstream changes yourself.
- Different from branching — a branch is a line of development inside one repository; a fork is a whole separate repository.
- The engine of open source — fork, change, and pull request is the standard workflow for outside contributions.
- Two remotes, one workflow — origin for your fork, upstream for the original, working together to keep you current.
- Keep pull requests clean — sync often and branch per change to make your contributions easy to review.