Remotes & Collaboration
Everything so far has happened entirely on your laptop — commits, branches, merges, all local. That's genuinely useful on its own, but Git's real power for teams shows up once your repository can talk to a copy living somewhere else: a remote. This is how your laptop, your teammate's laptop, and a shared server all stay in sync without anyone emailing zip files around.
💡 The Bottom Line
A remote is just another copy of the same repository, usually hosted somewhere everyone
can reach — like GitHub. git push sends your local commits there;
git pull brings down commits others have added; git fetch checks
for new commits without touching your working files yet. Together, these three commands are
the entire mechanism behind team collaboration in Git.
What "origin" actually means
When you clone a repository from GitHub, Git automatically names that source
origin — it's just a convenient default label for "the remote I got this from,"
not a special keyword. You can see it, and its URL, with:
git remote -v
origin https://github.com/yourname/my-project.git (fetch)
origin https://github.com/yourname/my-project.git (push)If you started a repo locally instead of cloning it, there's no remote yet — you add one yourself, pointing at an empty repository you've created on GitHub:
git remote add origin https://github.com/yourname/my-project.git
git push -u origin mainThe -u flag sets up tracking, so future plain git push /
git pull commands know which remote branch to talk to by default.
Push, pull, and fetch
# send your local commits up to the remote
git push origin main
# fetch AND merge new remote commits into your current branch
git pull origin main
# just check what's new on the remote, without touching your files
git fetch origingit fetch is the cautious cousin of git pull: it downloads new
commits and updates Git's record of the remote branch, but leaves your own working files
exactly as they were. git pull does that fetch and then immediately merges those
new commits into your current branch — convenient, but it means a merge (or conflict) can
happen without much warning. Fetching first, then reviewing what changed before merging, is a
common safer habit once a project has several active contributors.
🙋 There Are No Dumb Questions
Q: Is GitHub the only place you can host a Git remote?
A: Not at all. GitHub is the most popular, but GitLab, Bitbucket, a company's private Git
server, or even a folder on a USB drive can all serve as a remote — Git itself doesn't care
where the other copy lives, only that it can reach it. GitHub's real value-add on top of
plain Git is the web interface: pull requests, code review, issue tracking, and CI —
features Git itself doesn't provide.
The typical collaboration flow
Most teams settle into a version of this pattern:
git switch -c feature/checkout-page
# ... work, commit locally ...
git push -u origin feature/checkout-pagePushing a new branch makes it visible to teammates on GitHub, where someone opens a
pull request (a request to merge that branch into main, with a
space for review comments and discussion) before it's merged — keeping main
protected from unreviewed changes.
⚠️ Watch Out
Pushing directly to a shared main branch without a pull request skips the
whole safety net of code review and any automated checks a team has set up — and if two
people push conflicting changes to main at the same time, Git will reject the
second push until it's pulled and reconciled first. Working on a branch and pushing that
instead avoids this entirely.
🔧 Try It Yourself
If you have a GitHub account, create a new empty repository there, then connect a local project to it:
cd git-practice
git remote add origin https://github.com/yourname/git-practice.git
git branch -M main
git push -u origin main
git remote -vRefresh the repository page on GitHub — your commits should now be visible there, confirming the push worked and the two copies are in sync.
✅ Quick Check
What's the key difference between git fetch and git pull?
Next up: the last piece — what to do when you've made a mistake, at every stage from an unstaged typo to a commit you already pushed.