Why fork

You rarely have write access to a project you want to contribute to. The forking workflow solves this: you fork the upstream repo into your own namespace, push to your fork, and open pull requests from your fork to the upstream. It is the default model for almost every public OSS project.

The setup

# Fork on the web UI, then clone your fork
git clone https://github.com/yourname/project.git
cd project

# Add upstream as a second remote
git remote add upstream https://github.com/original-owner/project.git
git remote -v

Now origin points to your fork, upstream to the source.

The contribution loop

# Sync from upstream before starting
git fetch upstream
git checkout main
git merge upstream/main
git push origin main

# Branch off main
git checkout -b feature/improve-error-message

# ...work...
git push -u origin feature/improve-error-message

# Open PR via UI or CLI
gh pr create --repo original-owner/project

Keeping your fork in sync

The upstream main moves while your PR is reviewed. Sync regularly:

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

# Update your feature branch
git checkout feature/improve-error-message
git rebase main

If your branch is already pushed, force-push after rebase:

git push --force-with-lease

Handling review feedback

For OSS, reviewers usually prefer a clean history before merge:

git rebase -i upstream/main
# squash review-feedback commits
git push --force-with-lease

Some projects prefer merge-as-is for transparency. Read CONTRIBUTING.md.

Multiple PRs

Each PR should be its own branch. Do not stack unrelated work on one branch:

git checkout main
git pull upstream main
git checkout -b feature/another-fix

Signing your commits

Some projects require signed commits or sign-off:

git commit -s -m "Fix typo in error message"
git config commit.gpgsign true
git config user.signingkey YOUR_KEY_ID

Etiquette

• Read CONTRIBUTING.md before opening a PR.
• Open an issue first for non-trivial changes.
• One concern per PR.
• Be patient - maintainers are often volunteers.
• Respond to feedback graciously, even when you disagree.

After merge

git checkout main
git fetch upstream
git merge upstream/main --ff-only
git push origin main
git branch -d feature/improve-error-message
git push origin --delete feature/improve-error-message

Forks for private projects

The fork model also works inside companies as a permission boundary - core maintainers have write to the canonical repo, contributors work from forks, and PRs cross the boundary. It scales to thousands of contributors precisely because trust is per-PR, not per-branch.