GitHub Fork: Contributing to Someone Else's Project 🍴

A fork is your personal copy of someone else’s repository on GitHub. It’s the key tool in open source development and the way to contribute to a project without having write access to it.

Fork vs Clone: What’s the Difference?

Typical flow: Fork → Clone the fork → work → PR to original.

Why You Need a Fork

When you’re not a member of the repository

Want to add a feature to a popular library? You don’t have permission to push directly. Solution:

Original (someone else's)      Your fork
github.com/facebook/react  →  github.com/your-username/react
     no permissions                   full permissions
                                            ↓
                                  Work locally
                                            ↓
                                  PR to original

Experiment without risk

Fork any project and experiment freely — the original won’t be affected.

Take it as a base

You like a project and want to develop it in your own direction — fork it and maintain it separately.

How to Fork

On GitHub

1. Open the repository you want to fork
2. Click the Fork button (top right, next to Star and Watch)
3. Choose the account to fork to (usually your personal account)
4. Click Create fork

In 5-10 seconds GitHub will redirect you to your copy:

github.com/original/repo  →  github.com/YOU/repo
                               forked from original/repo

Clone Your Fork, Not the Original

This is the most common mistake! You need to clone your fork, not the original.

In GitHub Desktop

1. File → Clone Repository → GitHub.com tab
2. In the list find the repository marked Forked from…
3. Select it → Clone

How to verify you cloned the right one

In GitHub Desktop: Repository → Repository Settings

✅ Correct:
Primary remote (origin): https://github.com/YOUR-USERNAME/repo-name

❌ Wrong:
Primary remote (origin): https://github.com/SOMEONE-ELSE/repo-name

If origin points to the original — delete it and clone again.

Full Cycle: Fork → PR

1. Fork on GitHub

Clicked Fork → got a copy.

2. Clone the fork

GitHub Desktop → Clone → selected the fork → folder on your computer.

3. Create a branch

Branch → New Branch → feature/my-contribution

4. Work and commit

Normal commits — they go to your fork.

5. Push to fork

Push origin — changes go to your fork on GitHub.

6. Create a PR to the original

On GitHub open your fork → click Compare & pull request.

Critically important: check the PR direction:

base repository: ORIGINAL/repo  ←  compare: YOUR-USERNAME/repo
     ↑ target                              ↑ source

If base points to your fork — click “compare across forks” and fix it.

7. Fill in the description and create the PR

The PR will appear in the original repository, under the Pull requests tab.

Syncing Your Fork with the Original

The original project keeps evolving while you’re working. Your fork “falls behind”.

Via GitHub (easy)

On your fork’s page a banner will appear:

“This branch is N commits behind original:main”

Click Sync fork → Update branch.

In GitHub Desktop after syncing

After Sync fork on GitHub:
1. Switch to main in GitHub Desktop
2. Fetch origin → Pull origin
3. Local main is now up to date

Update your working branch

In GitHub Desktop: Branch → Update from default branch

If your branch changed the same files as the original — there’ll be a conflict.
Resolve it and continue. More detail: Resolving Conflicts.

What Happens After Your PR Is Merged

The maintainer accepted and merged your PR. Your changes are now in the original project!

After that:
1. Delete the branch in the fork (GitHub will suggest it)
2. Sync the fork: Sync fork on GitHub
3. In GitHub Desktop: Fetch + Pull on main

Delete a Fork

If the fork is no longer needed:

Your fork’s settings on GitHub → Settings → Danger Zone → Delete this repository.

This deletes only your fork, the original is untouched.

Fork and Open Source: Etiquette

Before starting work

• Read CONTRIBUTING.md — the project’s rules are there
• Look at open Issues — the task may already exist
• If there’s no issue — create one and say you’re taking it on

In the PR

• Fill in the description — maintainers receive dozens of PRs
• One task — one PR, don’t mix changes
• Be ready for revisions — first PRs are rarely accepted without feedback

After rejection

Don’t be discouraged if your PR isn’t accepted. It’s normal. The maintainer may:
- Ask for a different approach
- Explain the task is being solved differently
- Decline for reasons unrelated to code quality

Thank them for the response and keep going.

Fork vs Collaborator

If you’re working in a team on your own project — you’re a collaborator. Forking is only needed to contribute to someone else’s projects.