Forking workflow

Overview

The forking workflow is the standard model for open-source projects and any setting where contributors are not trusted with direct push access to the main repository. Instead of pushing to a shared repo, each contributor works in their own server-side copy — a fork — and proposes changes back through a pull request. It is how millions of contributions reach projects on GitHub and GitLab every day.

The key difference

In the feature branch workflow, everyone pushes branches to one shared repository. The forking workflow adds a layer: there are now two server-side repositories — the official upstream repo, which you cannot write to, and your fork, which you fully control. You push to your fork and ask upstream to pull from it.

Step by step

1. Fork the upstream repository on the hosting platform. This creates your-fork under your account — a complete server-side copy.

2. Clone your fork to your machine:

git clone https://github.com/you/project.git
cd project

3. Add upstream as a remote so you can pull in the project's latest changes:

git remote add upstream https://github.com/original/project.git

Your clone now has two remotes: origin (your fork) and upstream (the official repo). See git remote for managing these.

4. Create a branch and work:

git switch -c fix/typo-in-docs
# ...make changes and commit...
git push -u origin fix/typo-in-docs

5. Open a pull request from your fork's branch to upstream's main branch. Maintainers review it, request changes if needed, and merge when satisfied.

Staying in sync with upstream

Because the project moves on without you, periodically refresh your fork from upstream before starting new work:

git switch main
git fetch upstream
git merge upstream/main
git push origin main

This keeps your fork's main branch aligned with the official project, so your new branches start from current code.

Why it works

The forking model lets a project accept contributions from anyone while keeping the official repository locked down — only maintainers can merge. Contributors need no special permissions, review happens in the open on each pull request, and the upstream history stays clean. For untrusted, large-scale collaboration, it is the safest of the common Git workflows.

Practice