Remotes & GitHub
Push your work to GitHub, pull others' changes, and collaborate through pull requests
So far everything has lived on your machine. A remote is a copy of your repository hosted elsewhere — usually GitHub — that you and your team sync with. This is how code gets shared, reviewed, and shipped.
What Is a Remote?
A remote is a named URL pointing to another copy of the repo. When you clone from GitHub, Git automatically names that remote origin.
git clone https://github.com/user/project.git
cd project
git remote -v
origin https://github.com/user/project.git (fetch)
origin https://github.com/user/project.git (push)
origin is just a convention — a nickname for "the place I cloned from." You can have multiple remotes, but most projects have exactly one.
Pushing Your Work
git push uploads your local commits to the remote. The first time you push a new branch, tell Git where it should go with -u (set upstream):
git switch -c feature/search
git commit -m "feat: add search bar"
git push -u origin feature/search
After that upstream link is set, plain git push and git pull know which remote branch to use:
git push # uploads new commits on the current branch
git pull # downloads and merges remote commits into your branch
git fetch downloads remote commits but does not change your working
files — it just updates your knowledge of the remote. git pull is fetch
mergein one step. When you want to look before you leap, fetch first.
Staying in Sync
On a team, main moves constantly. Before starting new work, get the latest:
git switch main
git pull
remote main: A ─ B ─ C ─ D (teammates pushed C, D)
local main: A ─ B → git pull → A ─ B ─ C ─ D
The Pull Request Workflow
You almost never push directly to main on a team. Instead, you propose changes through a pull request (PR) — GitHub's mechanism for review and discussion. The full loop:
1. git switch -c feature/x create a branch
2. ...commit your work...
3. git push -u origin feature/x push the branch to GitHub
4. Open a PR on GitHub "please merge feature/x into main"
5. Teammates review & comment
6. Address feedback (more commits, push again)
7. Merge the PR feature/x → main
8. git switch main && git pull sync your local main
The PR is where code review happens: teammates read your diff, leave comments, request changes, and approve. It's the single most important collaboration ritual in professional development.
A 50-line PR gets reviewed in minutes; a 2,000-line PR sits for days and hides bugs. Small, focused branches (one feature or fix each) are reviewed faster and merged sooner.