How to Fork a GitHub Repository and Contribute to It

A fork is your own GitHub-hosted copy of another repository. It lets you make and push changes without write access to the original project, then propose those changes with a pull request. Here is the complete fork workflow, from creating the copy to keeping it in sync.

1. Fork the repository on GitHub

1. Sign in to GitHub and open the repository you want to contribute to.
2. Select Fork near the top of the repository page.
3. Choose the destination account and, if prompted, a name for your fork. Confirm the fork creation.

GitHub creates a repository under your account, typically at https://github.com/YOUR-USERNAME/REPOSITORY. Some organizations restrict forking, and private repositories may require permission or use organization-specific policies.

2. Clone your fork to your computer

Copy the clone URL from your fork, then clone it and enter the project directory:

git clone https://github.com/YOUR-USERNAME/REPOSITORY.git
cd REPOSITORY

In this common setup, Git names your fork's remote origin. Check the configured URL with git remote -v before pushing, especially if you cloned the original repository instead of your fork.

3. Add the original repository as upstream

Add a second remote pointing to the project you forked. The name upstream is a convention for the original repository:

git remote add upstream https://github.com/ORIGINAL-OWNER/REPOSITORY.git
git remote -v

You should see your fork under origin and the original project under upstream. Remote names are configurable; use the names shown by git remote -v in later commands.

4. Create a branch and make your change

Start from the project's contribution branch, commonly main. Fetch the latest original branch and create a separate branch for your work:

git fetch upstream
git switch main
git merge --ff-only upstream/main
git switch -c fix-navigation

The fast-forward step starts your contribution from the latest upstream history when your local main branch has not diverged. If it fails, inspect the branch history and resolve the difference before creating your work branch.

Follow the repository's contribution guide, run any relevant tests, and review the diff before committing:

git status
git diff
git add path/to/changed-file
git commit -m "Fix navigation on small screens"

5. Push your branch to your fork

Push the branch to your fork, not the original project:

git push -u origin fix-navigation

The upstream repository can usually be read from but not pushed to without explicit access. If your remote setup is different, confirm the destination with git remote -v before pushing.

6. Open a pull request to the original project

On GitHub, open your fork or use the prompt shown after pushing and start a new pull request. Check both sides carefully:

• Base repository and branch: the original project and the branch that should receive your change.
• Head repository and branch: your fork and the feature branch you pushed.

Review the diff, write a clear title and description, link any relevant issue, and follow the project's template. Request reviewers if appropriate. New commits pushed to your branch update the existing pull request.

Keep your fork up to date

To bring new commits from the original project into your local main branch, fetch upstream and fast-forward your local branch when possible:

git fetch upstream
git switch main
git merge --ff-only upstream/main
git push origin main

Replace main if the project uses a different default branch. The --ff-onlyoption avoids creating an unexpected merge commit; if it fails, stop and inspect your local history rather than forcing the update. Keep separate contribution branches based on the project's preferred workflow.

Forking FAQ

What is the difference between a fork and a clone?

A fork is a GitHub-hosted copy of a repository under another account or organization. A clone is a local copy on your computer. A typical contribution workflow uses both.

Do I need permission to contribute through a fork?

You generally do not need write access to the original repository for a public fork-based contribution, but the project must accept pull requests and its maintainers decide whether to merge them. Private repositories and organization policies may require access.