What a remote is; clone vs fork vs ZIP
Intermediate Core Git GitLab UI GitHub UI
Why this matters
Git works perfectly well with no network at all. The remote is what turns a personal history into a team's: one agreed copy that everyone sends commits to and takes commits from. Understanding that it is just another repository, with no special powers, explains most of what follows in this section.
A remote is a repository somewhere else
Because Git is distributed, your clone is not a thin window onto the server. It holds every commit, branch and tag the server had when you cloned. That is why git log, git switch and git diff work on a plane, and why only four commands need the network at all.
origin, and how to look at it
origin is not a keyword; it is the nickname git clone gives to the URL it copied from. You can see it:
$ git remote -vorigin https://gitlab.com/northwind-trails/trailguide.git (fetch)
origin https://gitlab.com/northwind-trails/trailguide.git (push)Two lines because Git allows different URLs for reading and writing, which almost nobody uses. For the full picture, including which branches are tracked:
$ git remote show origin* remote origin
Fetch URL: https://gitlab.com/northwind-trails/trailguide.git
Push URL: https://gitlab.com/northwind-trails/trailguide.git
HEAD branch: main
Remote branch:
main tracked
Local branch configured for 'git pull':
main merges with remote main
Local ref configured for 'git push':
main pushes to main (up to date)Most projects have exactly one remote called origin. A second one appears in two situations: contributing through a fork (lesson 7.7), where upstream points at the original project, and mirroring a repository between GitLab and GitHub.
Three ways to get a project
| Clone | Fork, then clone | Download ZIP | |
|---|---|---|---|
| What you get | The full history, plus origin |
A server-side copy that is yours, plus the full history | The files of one commit, no history, no .git |
| Can you commit? | Yes, locally | Yes, locally | No; it is not a repository |
| Can you push? | Only if you have write access | Yes, to your fork | No |
| Use it when | You are on the team | You want to contribute to a project you cannot push to | You only want to read or run the files once |
Two consequences worth remembering. A ZIP download is a dead end: git status in that folder answers fatal: not a git repository, and there is no way to turn it into a contribution. And cloning a project you cannot push to is perfectly fine: you can read all of it, work locally, and commit; only the push will be refused.
Common mistakes
- Believing the remote holds "the real repository" and yours is a copy. Both are complete. The team simply agrees which one is the meeting point.
- Downloading the ZIP, editing, and wondering how to send the change back. There is no way; clone or fork instead.
- Assuming
originis a fixed name. It is a nickname stored in.git/config;git remote renamechanges it andgit remote set-urlchanges the URL it points at. - Adding a second remote by accident with
git remote add origin …when one exists. Git answerserror: remote origin already exists; useset-url.
Try it yourself
Goal: inspect your playground's remote and prove that the history is local.
- In the playground, run
git remote -vandgit remote show origin. - Turn off your computer's network (or unplug the cable, or use flight mode).
- Run
git log --oneline -5,git switch -c docs/offline-test, make a commit, andgit switch main. - Turn the network back on and run
git fetch.
Expected result: every command in step 3 works with no network; only step 4 needs it. git remote show origin fails while offline, because it asks the server.
Show solution
Everything that reads or writes history is local: log, branch, commit, switch, diff, merge. The four network commands are clone, fetch, pull and push (plus git remote show, which queries the server). That split is the practical meaning of "distributed". Clean up: git branch -D docs/offline-test.