Forks and Upstream Sync

## What a fork is, from Git's point of view Git has no `fork` command and no concept of a fork. A fork is a **server-side copy** of a repository made by the hosting service; once it exists it is just another repository with its own URL. Everything a fork-based workflow does is ordinary Git: you clone one repository and add a second remote pointing at another. That is why the whole workflow reduces to a naming convention over `git remote`. ## The two-remote convention - **`origin`** — your fork. You have write access, so this is where your topic branches live and where you push. `git clone <your-fork-url>` creates this remote for you; the name `origin` is simply the default `git clone` uses. - **`upstream`** — the repository you forked from. You fetch from it to see new work by the maintainers. You typically cannot push here; if you try, the server rejects the push. Nothing in Git enforces this. `upstream` has no built-in meaning whatsoever — you create it yourself: ``` git remote add upstream https://example.org/project.git git remote -v ``` ## Careful: two different meanings of "upstream" Git uses the word *upstream* for a second, unrelated idea: a branch's **upstream branch**, the tracking relationship you query with `@{u}` and set with `git branch -u`. A branch's upstream branch is usually `origin/<branch>` even in a fork workflow, and has nothing to do with a remote that happens to be *named* `upstream`. Interviewers like this distinction because candidates who have only copied commands off a wiki conflate the two. ## Remote-tracking refs are per remote Each remote gets its own namespace of remote-tracking refs under `refs/remotes/`: - `refs/remotes/origin/*` — what your fork looked like at your last fetch of `origin` - `refs/remotes/upstream/*` — what the original project looked like at your last fetch of `upstream` These are updated **only** by fetching that particular remote. `git fetch upstream` moves `upstream/main` and leaves `origin/main` exactly where it was. That is the single most common source of confusion in fork workflows: after fetching upstream, `git status` on your local `main` may still report it as up to date, because it is compared against its upstream branch `origin/main`, which nobody has touched. It also explains why a plain `git pull` in a fork never picks up new maintainer work: `pull` contacts the remote your branch tracks, which is your own fork. ## Why the split exists at all The fork model is what you use when you do not have write access to the project you want to change. Publishing your branch needs a repository you *can* write to, and reviewers need a URL they can fetch from — your fork provides both. The original repository remains the single source of truth about what has actually been accepted, so you keep a live read-only connection to it rather than trusting your fork's copy of `main`, which goes stale the moment it is created and never updates by itself. ## Practical setup ``` git clone https://example.org/you/project.git # creates origin = your fork cd project git remote add upstream https://example.org/project/project.git git fetch upstream ``` From here, `upstream/main` is your reference point for "what the project actually contains", and `origin` is your publishing target. Some people additionally guard against accidents by pointing upstream's push URL at a bogus value with `git remote set-url --push`, so a stray `git push upstream` fails locally instead of at the server. ## What interviewers listen for They want to hear that these are just two remotes, that the names are conventions, that each carries its own remote-tracking refs, and that fetching one does not update the other. A candidate who says "origin is my fork, upstream is the real repo, and my local main tracks origin so I have to fetch upstream explicitly" has demonstrated the whole model in one sentence.