Fork Workflow

Course 2 · Ch 4

Fork Workflow vs Shared-Repo Workflow

Contributing to projects you don't have direct push access to — and when forking makes sense even on your own repos

Every workflow covered so far assumed you have push access to the repository — you branch directly off it, push your branch, and open a PR within the same repo. That breaks down the moment you want to contribute to someone else's project (an open-source library, a colleague's personal repo) where you don't have, and shouldn't have, push access. That's exactly what forking solves.

What a Fork Actually Is

A fork is your own complete copy of someone else's repository, created on GitHub, that you fully own and control — you can push to it freely, exactly like any repository you created yourself. The fork stays connected to the original ("upstream") repository in GitHub's interface, which is what makes opening a PR back to the original possible.

You fork upstream on GitHub → clone YOUR fork locally → push to your fork → open a PR from your fork back to upstream

The Fork Workflow, Step by Step

Fork the repository on GitHub

The "Fork" button on any repo page creates a complete copy under your own account in seconds.

Clone YOUR fork, not the original

git clone https://github.com/yourname/project.git — note it's your username in the URL, not the original maintainer's.

Add the original repo as a second remote, conventionally named "upstream"

git remote add upstream https://github.com/originalowner/project.git — this is the second-remote scenario flagged back in Course 1, Chapter 5.

Branch, commit, push to YOUR fork (origin)

Exactly the Course 1 workflow — git switch -c, commit, git push -u origin <branch>.

Open a PR from your fork's branch into upstream's main branch

GitHub detects the fork relationship automatically and offers this as an option when opening a new PR.

Keeping your fork up to date

Your fork doesn't automatically stay in sync with upstream as the original project keeps moving — you periodically need to pull upstream's changes into your fork.

$ git fetch upstream
$ git switch main
$ git merge upstream/main
$ git push origin main # updates your fork on GitHub too

git fetch vs git pull, properly distinguished

git fetch downloads a remote's commits without merging them into your current branch — it just updates what your local git knows about that remote. git pull is really git fetch + git merge combined. Using fetch explicitly (as above) lets you inspect upstream's changes with git log upstream/main before deciding to merge them in.

Fork Workflow vs Shared-Repo Workflow

🍴

Fork Workflow

Used when: contributing to a project you don't have push access to — open source, a colleague's personal project, a project where access is intentionally restricted.

Trust model: maintainers don't need to grant you any access at all — they just review and merge (or decline) your PR.

🤝

Shared-Repo Workflow

Used when: you're already a collaborator with push access — most internal team projects, everything in Course 1's branching and PR chapters.

Trust model: you're trusted to push branches directly; branch protection rules (Course 3, Ch6) still gate what reaches main.

Forking your own repo can be useful too, even with full access

Some teams deliberately use a fork-based workflow even internally — it keeps the main repository's branch list clean (no accumulation of personal branches from every contributor) and adds a clear boundary between "experimental personal work" and "the shared repo." Not the default choice, but a legitimate one for larger teams.

Command Reference

Command	What it does
git remote add upstream <url>	Adds the original repo as a second remote, conventionally named upstream
git fetch upstream	Downloads upstream's commits without merging them in
git merge upstream/main	Brings upstream's changes into your local main branch
git push origin main	Pushes the now-updated main to YOUR fork (origin)

Chapter 4 Quick Reference

A fork is your own complete, fully-owned copy of someone else's repo, linked to the original on GitHub
Fork workflow: fork → clone YOUR fork → add upstream remote → branch/commit/push to origin → PR into upstream
upstream = conventional name for the original repo's remote, alongside your own origin
git fetch vs git pull: fetch downloads without merging; pull = fetch + merge combined
Use forks when you lack push access; use the shared-repo workflow when you already have it
Keeping a fork current: fetch upstream → merge upstream/main → push to origin, periodically
Next chapter: stashing, cherry-picking, and tagging releases