Remotes, forks & upstream
Everything so far has quietly relied on a machine you've never been introduced to. Time to meet it — and figure out how someone with zero permissions still gets to contribute.
Go back and reread a few lines from earlier chapters. "Rachit pulled this morning." "Push the fix." "Anvesha already has this commit." None of that was ever explained — it was taken on faith, the same way Chapter 1 asked you to trust that "version control" was a real, existing thing before naming it. It's time to open that box.
Every laptop in this story — yours, Rachit's, Anvesha's, Sahil's — has had its own local .git/ folder this whole time, exactly as Chapter 3 described. But they've also, quietly, all been pointed at the same address on GitHub: github.com/accelerate-muj/website. That address is what Git calls a remote — a nickname for a URL where another copy of the same repository's history lives, that your local repo knows how to talk to.
origin is just a nickname — the default one Git assigns when you clone a repo, not a keyword with special meaning. It could be called anything.
The three verbs that move commits between machines
| Command | What actually happens |
|---|---|
git fetch | Downloads any new commits from origin and updates your local knowledge of origin/main — but doesn't touch your own working branch at all. |
git pull | fetch, immediately followed by merge (or rebase, if configured) into your current branch. The one-step version. |
git push | Sends your local commits up to origin, so everyone else's next fetch will see them. |
This is the missing mechanism behind Chapter 6's whole crisis: Rachit's "pull this morning" was a real fetch-and-merge from origin, which is exactly why rewriting the commit he'd already downloaded would have caused him real pain — his local repo and the remote would have disagreed, with no clean way to reconcile automatically.
git fetch is always non-destructive — it only downloads. Once it's done, git log HEAD..origin/main shows exactly what's new before you merge anything in. Slower than git pull, but zero surprises.
The new problem: someone with no write access at all
A new General Member, Ishaan, wants to help out. He's spotted a genuine typo in one of Vidha's beginner Git-track pages on the resources repo and wants to fix it. But per the club's access model — the same one your dashboard reflects — General Members get zero direct write access to any repo. That's not a bug; it's deliberate, matching Article XIII's proposal process: nobody pushes straight to a shared repo they haven't been explicitly granted onto.
So how does he contribute at all? He can't git push to a remote he has no permission on. What he can do is make his own copy — a fork — that lives at his own GitHub username, which he owns completely, and propose that his changes get pulled back into the real one.
(he has no write access here — "upstream") (he fully owns this — "origin")
│
push/pull
│
Ishaan's laptop
Walking through it exactly as Ishaan would
Fork on GitHub
He opens accelerate-muj/resources and clicks "Fork." GitHub creates a full copy — every commit, every branch — living at his own account.
Clone HIS fork, not the original
git clone https://github.com/ishaan-handle/resources. This makes his fork origin — the remote he actually has write access to.
Add the real repo as a second remote, named `upstream`
git remote add upstream https://github.com/accelerate-muj/resources. This is purely for reading — pulling in whatever the club adds later. He'll never be able to push here directly, and that's fine; it's not how his contribution is going to travel.
Branch, fix, push — to his own fork
git switch -c fix/typo-in-staging-page
# fix the typo
git commit -am "docs: fix typo in staging area explanation"
git push -u origin fix/typo-in-staging-pageOpen a pull request FROM his fork TO the real repo
This is the part that finally reunites the two boxes in the diagram — a request, visible to Vidha and the rest of the club, asking that his branch be merged into the real resources. Chapter 13 covers exactly what happens from here.
Staying current with a repo you don't own
Ishaan's fork is a snapshot from the moment he clicked "Fork." The real resources repo keeps moving without him. Before starting any new work, he brings his fork's main up to date with upstream:
GitHub's web UI also has a one-click "Sync fork" button that does the fast-forward case of this without touching a terminal at all — handy for exactly this kind of routine catch-up.
git push from his local clone. Which repository actually receives his commits?git push targets origin by default, and for Ishaan, origin is his own fork — the only remote he actually owns. The real repo only ever receives his work through the pull request his branch gets opened against.
Ishaan's branch is up on his fork, ready. But when he goes to open the pull request, GitHub asks him to sign in — and it's been declining his old password for a while now. Something changed a few years back about how GitHub lets you prove who you are.