Remotes and Refspecs

## A remote is a config entry Newcomers imagine a remote as a connection or a copy of the server. It is neither. A remote is three pieces of local configuration: a name, one or more URLs, and one or more refspecs. `git remote add origin <url>` appends exactly that to `.git/config`, a `[remote "origin"]` section holding `url` and `fetch = +refs/heads/*:refs/remotes/origin/*`. No network traffic occurs. If the URL is wrong you find out at the first `git fetch` or `git push`, not at `git remote add`. ## What the name buys you The name is a local alias so you can type `git fetch origin` instead of the URL. Git attaches no meaning to `origin` — it is merely what `git clone` names the source it cloned from. In a fork setup people conventionally add a second remote called `upstream`, but the names are yours to choose. `git remote rename <old> <new>` renames the config section, moves the remote-tracking refs from `refs/remotes/<old>/` to `refs/remotes/<new>/`, and updates the `branch.<name>.remote` settings that pointed at it. ## Several remotes at once Because each remote's fetch refspec writes into its own `refs/remotes/<name>/` namespace, remotes never collide. With `origin` and `upstream` configured you get both `origin/main` and `upstream/main`, two independent pointers you can compare and merge from. `git fetch --all` updates every configured remote. That is the whole mechanism behind fork workflows: two names, two URLs, two namespaces. ## Inspecting and editing remotes - `git remote -v` lists remotes with their URLs, printing two lines per remote — one tagged `(fetch)` and one `(push)`. - `git remote show <name>` contacts the remote and reports its branches, which ones are tracked, and which local refs are stale. - `git remote get-url <name>` prints the configured URL. - `git remote set-url <name> <newurl>` repoints a remote, for example after a repository moves; `git remote set-url --push <name> <url>` sets a separate push destination, which is what makes the fetch and push lines differ. - `git remote remove <name>` (also spelled `git remote rm`) deletes the config section and the remote-tracking refs under that name. Your local branches are untouched, though ones that tracked the removed remote lose their upstream setting. ## Useful options at add time `git remote add` takes options that pre-shape the configuration: `-f` fetches immediately after adding, `-t <branch>` narrows the fetch refspec to a single branch and may be repeated, `--no-tags` records `tagOpt = --no-tags` so tags are not fetched automatically, and `--mirror=fetch` or `--mirror=push` set up mirroring semantics. Everything they do is expressible as plain config, because that is all a remote is. ## Why interviewers ask The question separates people who treat Git commands as incantations from those who know where state lives. If you can say that it appends a section to `.git/config` and that nothing else happens until a fetch, you can also debug the common failures: pushing to the wrong URL after a repository move, a remote whose refspec was hand-edited, or a `git remote add` that appeared to succeed against a URL that does not exist. ## What it is not Adding a remote does not create a branch, does not set an upstream for any of your branches, and does not authenticate. Those are separate concerns handled at fetch and push time.