Forks & Pull Requests

In one line

A fork is your own personal remote copy of someone else's repository — and a pull request is a formal request asking the original project to pull your changes back in, reviewed before anything merges.

0/4 · 0%

Think of it like this

Photocopying a public recipe book to scribble your own notes and improvements in the margins, then formally proposing to the original author 'here's a specific set of changes — please consider adding them to the real book.' A fork is your personal copy; a pull request is that formal proposal.

Key ideas

01
A FORK (a GitHub/GitLab platform feature, not a core Git concept itself) creates a complete copy of someone else's repository under YOUR account, which you can freely push to, since you don't have write access to the original. This is how open-source contribution works when you're not already a collaborator on the project.
02
The standard fork workflow: fork the repository on the platform (creating your own copy), git clone YOUR fork locally, make changes on a new branch, push that branch to YOUR fork, then open a PULL REQUEST asking the ORIGINAL repository to merge your branch into theirs — the original maintainers review it, request changes if needed, and merge it (or not) at their discretion.
03
A pull request is fundamentally a REVIEW mechanism, not just a merge trigger — it shows the exact diff being proposed, lets reviewers leave inline comments on specific lines, supports a back-and-forth conversation, and typically runs automated checks (CI, Phase 7) before anyone even considers merging it.
04
upstream is the conventional name for the ORIGINAL repository's remote, added to your fork's local clone specifically so you can pull in the original project's latest changes over time (git remote add upstream <original-url>, then git fetch upstream and merge/rebase as needed) — without this, your fork silently falls behind the real project's ongoing progress.
05
On a project where you ARE a direct collaborator (write access to the actual repository, common inside a company), pull requests still work the same way for REVIEW purposes, just without the forking step — you push a branch directly to the shared repository and open a pull request from that branch, rather than from a personal fork.

Code & diagrams

ForkWorkflowdiagram

You never push directly to a project you don't have write access to — your fork is the bridge.

Rendering diagram…

fork-and-pr.shmarkdown

The full sequence, after forking a repo on GitHub's own website first.

# After clicking "Fork" on GitHub — clone YOUR fork, not the original
git clone https://github.com/YOUR-USERNAME/some-project.git
cd some-project

# Add the original project as a second remote, to stay in sync with it
git remote add upstream https://github.com/original-owner/some-project.git
git remote -v
# origin    -> your fork (fetch and push)
# upstream  -> the original project (fetch only, typically)

# Do your work on a dedicated branch
git switch -c fix/typo-in-readme
echo "corrected text" >> README.md
git add README.md && git commit -m "Fix typo in README"

# Push to YOUR fork (origin), not upstream — you don't have write access there
git push -u origin fix/typo-in-readme
# Now open a Pull Request on GitHub: your fork's branch -> the original repo

# Keep your fork in sync with the original project over time
git fetch upstream
git switch main
git merge upstream/main
git push origin main

Explain it without notes

Why do you need a fork at all, instead of just cloning the original repository directly and pushing your changes to it?

What's the purpose of adding the original project as an 'upstream' remote on your fork's local clone?

Practice

Fork any small public repository on GitHub, clone your fork locally, and confirm with git remote -v that origin points to your fork specifically, not the original.

Add the original repository as an upstream remote on that same clone, fetch from it, and merge any new upstream changes into your fork's local main branch.

Trade-offs

↔
The fork-and-pull-request model is what makes open-source collaboration at massive scale possible (anyone can propose a change without needing write access to anything) — but it adds real overhead (an extra remote to manage, a fork that can drift out of sync) compared to direct collaboration inside a single shared repository, which is exactly why most companies use direct branch-and-PR workflows internally and reserve the full fork model for genuinely external, open contributions.

Done when you can

I can explain what a fork is and why it's needed for contributing to projects I don't have write access to.
I can set up upstream tracking on a fork and pull in the original project's latest changes.
I understand a pull request is fundamentally a review mechanism, not just an automatic merge.