Forking a repository on GitHub is one of the most powerful and beginner-friendly features in modern software development. Whether you’re contributing to open-source projects, experimenting with someone else’s code, or starting your own variation of an existing tool, forking gives you the freedom to build without limits. In this guide, you’ll learn exactly how to fork a repository step by step, why it matters, and how to work with your fork effectively.
TLDR: Forking a repository on GitHub creates your own copy of someone else’s project under your account. This allows you to experiment, make changes, and contribute back without affecting the original repository. Simply click the Fork button on the repository page, clone your fork locally, and start working. When ready, you can submit a pull request to propose changes to the original project.
What Does It Mean to Fork a Repository?
When you fork a repository, you create your own copy of someone else’s project within your GitHub account. Think of it as duplicating a project into your own workspace. This gives you complete control over your version while keeping a connection to the original repository (often called the upstream repository).
Forking is especially useful in open-source development because:
- You don’t need direct write access to the original project.
- You can freely experiment without breaking production code.
- You can propose improvements through pull requests.
- You maintain your own customizable version of the project.
In short, forking promotes collaboration without sacrificing project stability.
Why Fork Instead of Clone?
A common beginner question is: Why not just clone the repository?
Cloning downloads a repository to your local machine. However, cloning alone does not create a copy under your GitHub account. Forking does.
Here’s the difference:
| Feature | Fork | Clone |
|---|---|---|
| Creates copy on GitHub account | Yes | No |
| Allows pull requests to original repo | Yes | No (unless forked) |
| Creates local working copy | No (cloud copy) | Yes |
| Used for contributing to open source | Yes | Partially |
Most developers fork first, then clone.
Step-by-Step: How to Fork a Repository on GitHub
Step 1: Log In to Your GitHub Account
Visit github.com and sign in to your account. If you don’t already have one, creating an account is free and only takes a few minutes.
Step 2: Find the Repository You Want to Fork
Use GitHub’s search bar to locate the repository you’re interested in. This could be:
- An open-source project
- A template repository
- A tutorial project
- A colleague’s repository
Once you’re on the repository’s main page, you’ll see project files, commit history, and other metadata.
Step 3: Click the “Fork” Button
In the top-right corner of the repository page, locate the Fork button. Click it.
GitHub may ask you:
- Where to fork (your personal account or an organization)
- Whether to change the repository name (optional)
After confirming, GitHub will create a copy of the repository under your account. This usually takes just a few seconds.
Step 4: Verify Your Fork
Once the process completes, you’ll be redirected to your forked repository. You can confirm it’s a fork by looking beneath the repository name. It will say something like:
“Forked from originalowner/repository-name”
This label indicates that your repository is linked to the upstream project.
Step 5: Clone Your Fork to Your Local Machine
Now that you have your fork on GitHub, it’s time to work on it locally.
Click the green Code button and copy the repository URL (HTTPS or SSH).
Then open your terminal and run:
git clone https://github.com/yourusername/repository-name.git
This downloads your forked version to your computer.
Step 6: Set Up the Upstream Remote (Highly Recommended)
To stay updated with changes made to the original repository, configure an upstream remote.
Navigate into your project folder:
cd repository-name
Add the original repository as upstream:
git remote add upstream https://github.com/originalowner/repository-name.git
Verify it:
git remote -v
You should now see:
- origin → your fork
- upstream → original repository
This setup allows you to pull updates from the main project.
Making Changes to Your Fork
Now that your fork is ready, you can:
- Create new branches
- Edit files
- Add new features
- Fix bugs
Create a new branch before making changes:
git checkout -b new-feature
After editing files:
git add .
git commit -m "Add new feature"
git push origin new-feature
Your changes are now pushed to your GitHub fork.
Submitting a Pull Request
If you want your improvements added to the original project, you’ll submit a pull request (PR).
Here’s how:
- Go to your fork on GitHub.
- Click Compare & pull request.
- Review your changes.
- Add a descriptive title and explanation.
- Click Create pull request.
The repository maintainers will review your submission. They may:
- Approve and merge it
- Request changes
- Start a discussion
This collaborative review process is the core of open-source development.
Keeping Your Fork Updated
Original repositories often change. To keep your fork up to date:
git fetch upstream
git checkout main
git merge upstream/main
git push origin main
This syncs your fork with the latest updates.
Working on an outdated fork can lead to merge conflicts, so regular syncing is a good habit.
Common Forking Mistakes to Avoid
1. Working directly on the main branch
Always create feature branches. It keeps your work clean and organized.
2. Forgetting to set upstream
Without upstream configured, syncing becomes confusing.
3. Making pull requests too large
Small, focused pull requests are easier to review and more likely to be accepted.
4. Ignoring contribution guidelines
Many repositories have a CONTRIBUTING.md file. Read it carefully.
When Should You Fork a Repository?
You should fork when:
- You want to contribute to a project you don’t own.
- You need to experiment without risking the original codebase.
- You want to create a personal variation of an existing tool.
- You are studying the code and testing modifications safely.
If you already have write access to the repository, you typically don’t need to fork — you can create branches directly.
Forking for Learning and Innovation
Forking isn’t just for professional developers. It’s an incredible learning strategy.
You can:
- Study how experienced developers structure code.
- Modify small parts and observe what breaks.
- Add experimental features.
- Build portfolio projects from adapted repositories.
Many startups and side projects began as forks of existing ideas, customized and improved over time.
Final Thoughts
Forking a repository on GitHub is more than just a button click — it’s a gateway to collaboration, experimentation, and open-source contribution. By creating your own independent copy of a project, you gain the freedom to innovate while maintaining a respectful link to the original creator.
The complete workflow looks like this:
- Fork the repository on GitHub.
- Clone your fork locally.
- Create branches for changes.
- Commit and push updates to your fork.
- Submit pull requests when ready.
- Sync with upstream regularly.
Once you’ve done it a few times, the process becomes second nature. Forking empowers you to participate in the global developer community — whether you’re fixing a typo in documentation or building the next major feature in a widely used library.
Now that you understand the process step by step, you’re ready to explore GitHub not just as a spectator, but as a contributor.