Everything in this series so far has worked entirely on one machine. A remote is what turns Git from a personal history tool into something a whole team shares - and understanding what it actually is clears up a surprising amount of confusion later on, including why pull sometimes does more than you expected.
What a remote actually is
A remote is just a named reference to another copy of your repository, usually hosted somewhere else - a URL plus a short name you refer to it by. When you clone a repository, Git automatically creates a remote called origin pointing at the URL you cloned from. You can see your configured remotes with git remote -v, and add another with git remote add <name> <url> - useful when you need to track more than one copy, like your own fork and the original project.
Fetch vs. pull - the distinction people get wrong for years
This is worth slowing down for, because conflating these two is a common source of "wait, why did my files just change?" moments:
| Command | What it does |
|---|---|
git fetch | Downloads new commits and branches from the remote into your local repo - but does not touch your working files or current branch |
git pull | git fetch followed immediately by a merge (or rebase, if configured) into your current branch - this is the one that changes your files |
Fetch is the safe, look-before-you-touch option: it lets you see what's changed on the remote (git log origin/main, for instance) before deciding whether to bring it into your own branch. Pull just does both steps at once, which is convenient but means you're merging immediately, sight unseen, whatever happened to be on the remote.
Pushing, and setting an upstream
The first time you push a new local branch, Git doesn't automatically know which remote branch it corresponds to - you have to tell it once with git push -u origin <branch-name>. The -u sets up "upstream tracking," so every push and pull after that just works with a plain git push or git pull, no branch name required.
git pull to bring those commits in (and resolve any conflict, covered next), then push again. Force-pushing over someone else's work should be a deliberate, rare decision, not a reflex to a rejected push.Where GitHub and GitLab actually fit
Git itself has no concept of a pull request, an issue, or a CI pipeline - those are features the hosting platforms built on top of plain Git. GitHub, GitLab, and Bitbucket all speak the same underlying Git protocol (over HTTPS or SSH); what differs between them is the web interface and collaboration tooling layered around it: code review workflows, permissions and teams, integrated CI/CD, project boards. Picking a Git host is really picking which company's collaboration layer you want, not picking a different version of Git.
Forks vs. branches
A branch lives inside one repository. A fork is an entirely separate copy of a whole repository, owned by a different account - the standard way to contribute to a project you don't have write access to. You fork it (creating your own copy on the hosting platform), clone your fork, make changes on a branch, push to your fork, then open a pull request asking the original project to merge your branch into theirs. Open source contribution almost always goes through this fork-then-PR pattern.