The Forking Workflow

Forking creates your own server-side copy of a repository you cannot push to, so you can make changes and propose them back through a pull request. It is the standard model for open source and for any contribution that crosses an organization boundary, because it requires no write trust: you work entirely in your copy until a maintainer chooses to merge.

The whole workflow comes down to keeping two remotes straight — the original repo and your copy of it — and not letting your copy drift so far behind that the eventual pull request is a wall of conflicts. Get those two habits right and forking is no harder than branching.

Fork, Origin, Upstream

When you fork, your copy becomes origin — the remote you clone from and push to. The original repository is conventionally added as a second remote named upstream, which you fetch from but never push to. Keeping these two names straight is the entire mental model: you pull new work from upstream and publish your contributions to origin.

A fresh clone of your fork has only origin configured. You add the original with git remote add upstream <url>, and from then on git remote -v shows both, making it obvious which is yours and which is the source of truth.

Syncing a Fork

Your fork is a snapshot taken at the moment you created it; it does not update itself. The instant the original repository gains a commit, your fork is behind. You catch up with git fetch upstream followed by a merge or rebase onto upstream/main, or by clicking the "Sync fork" button GitHub shows on the fork's home page.

Syncing before you start each piece of work is what keeps a pull request small and reviewable. A fork that has not been synced in weeks produces a diff against a base the maintainer no longer recognizes.

Contributing via Pull Request

You never work on your fork's default branch. You create a feature branch in your fork, push it to origin, and open a pull request whose base is the upstream repository's branch and whose head is your fork's branch. GitHub recognizes the fork relationship and offers the cross-repository PR automatically.

Branching per contribution lets you have several pull requests open at once, each isolated, and lets you keep working while one of them waits for review.

Maintainer-Side Controls

When you open the pull request, the "Allow edits by maintainers" checkbox lets a maintainer push small fixes directly to your branch — a one-line typo or a rebase — instead of asking you to do it across a timezone gap. Maintainers can also fetch your branch locally to test or amend it before merging.

Fork vs Branch Decision

The choice is governed by access. If you have push access to the repository — you are on the team — you branch directly and skip the upstream sync entirely; branch protection applies to your branch as-is. If you do not have push access — open source, an external contributor — you fork, because it gives isolation without anyone having to grant you write permission first.