Git 03 — Remotes, PRs & Collaboration

Everything so far happened on your laptop. But the job is team work: your code on a server, teammates’ code arriving daily, changes reviewed before they touch main. This module connects your local git to GitHub and walks the real collaboration loop — fetch, push, pull request, review, merge — the exact cycle that ships every line of code at a product company.

The Goal

By the end of this module you can:

• Explain what origin actually is — a named bookmark for a remote URL, not a magic GitHub link
• Distinguish fetch from pull and say precisely why fetch is the safe first move
• Describe a tracking branch and how it connects your local branch to one on the remote
• Run the full pull-request workflow with the gh CLI — from branch to merged PR — without leaving the terminal
• Choose between a fork and a branch and explain when each is the right model

The Lesson

A remote is a named URL — origin is just the default name

A remote is a bookmark: a short name that stands for a repository URL somewhere else (usually GitHub). When you git clone, git automatically creates one remote called origin pointing at the URL you cloned from. There’s nothing special about the name “origin” — it’s a convention, the default. You could rename it; you can add more (upstream is the common second one, covered under forks below).

git remote -v

origin  https://github.com/you/splitease-api.git (fetch)
origin  https://github.com/you/splitease-api.git (push)

Two lines because git tracks a fetch URL and a push URL separately (almost always identical). The mental model: origin is a label for “the GitHub copy.” Your local repo and the GitHub repo are two independent clones of the same history that you keep in sync by hand with fetch, pull, and push.

flowchart LR
    L[Your laptop repo] -->|push sends commits| R[GitHub repo - origin]
    R -->|fetch and pull bring commits| L

origin/main is a cached photo, not GitHub live

Here is the single most important idea in this module, and the one that clears up most “but GitHub says something different” confusion. When you git fetch, git downloads the remote’s commits and updates a set of remote-tracking branches — local pointers named origin/main, origin/feature, and so on.

origin/main is your machine’s cached snapshot of where GitHub’s main was at your last fetch. It is not live. git status and git log compare against this cached copy offline — they never phone GitHub themselves. So if a teammate pushed five minutes ago and you haven’t fetched, your tools still report “up to date” — up to date with old news.

This exact trap has its own real-error writeup — read fetch-updates-your-knowledge now, because internalizing “origin/main is a photo on my desk, fetch takes a fresh photo” is what stops you from being confused by remotes for the rest of your career.

fetch vs pull — the difference that matters

These are the two ways to bring remote changes down, and confusing them is how beginners get surprise conflicts.

git fetch is always safe — it changes no files and can never conflict. That makes it the right first move when you’re unsure what’s going on. Look before you leap:

git fetch
git log HEAD..origin/main --oneline   # what GitHub has that I don't yet
git status                            # now this answer is actually current

git pull is fetch + merge in one step — convenient, but it changes your working files and can drop a conflict on you mid-stride. Prefer git fetch then inspect when you want to see changes before they touch your files; use git pull when you already know you want them.

sequenceDiagram
    participant You as Your repo
    participant Origin as origin cache
    participant GH as GitHub
    You->>GH: git fetch
    GH-->>Origin: latest commits and branch tips
    Note over You,Origin: files unchanged - only knowledge updated
    You->>Origin: git merge origin main
    Note over You: now your files change - this is the pull half

Tracking branches — the local-to-remote link

When your local main is tracking origin/main, git knows they’re a pair. That link is what lets git status say “your branch is ahead of origin/main by 2 commits,” and what lets you type a bare git push or git pull without naming the remote and branch every time.

Clone sets this up automatically for main. When you create a new branch locally and push it the first time, you establish the link with -u (short for --set-upstream):

git switch -c add-rate-limit
# ...commit some work...
git push -u origin add-rate-limit

After that one-time -u, plain git push and git pull work on this branch. Check what’s tracking what:

git branch -vv

* add-rate-limit  a1b2c3d [origin/add-rate-limit] add token bucket
  main            f4e5d6a [origin/main] release v2

The bracketed name is the upstream each local branch tracks. No bracket means an untracked local-only branch — git push will refuse until you give it -u.

The pull request workflow — how code actually ships

Nobody pushes straight to main at a real company. The unit of change is a pull request (PR): you do work on a branch, push it, open a PR, a teammate reviews it, CI runs against it, and only then is it merged into main. The PR is where review and the automated checks (your CI/CD pipeline) gate every change.

flowchart LR
    A[Branch off main] --> B[Commit your work]
    B --> C[Push the branch]
    C --> D[Open a pull request]
    D --> E[Review plus CI checks]
    E --> F[Merge into main]
    F --> G[Delete the branch]

The whole loop, in the terminal, with the gh CLI (GitHub’s official command-line tool — free, and it means you never leave the keyboard for the browser):

gh auth login                                   # one-time: authenticate gh to GitHub
git switch -c add-rate-limit
# ...make changes, commit...
git push -u origin add-rate-limit
gh pr create --title "Add rate limiting" --body "Token bucket on the auth endpoint"
gh pr view --web                                # open it in the browser if you want
gh pr checks                                     # watch CI status from the terminal
gh pr merge --squash --delete-branch            # merge once approved and green

gh pr create opens the PR from your current branch against main. gh pr merge finishes the loop and cleans up the branch. Merge strategies you’ll choose between:

Squash is the most common team default: your messy work-in-progress commits become one clean commit on main. This is the merge vs rebase trade-off from Git 02 showing up as a button in your daily workflow.

Forks vs branches — two collaboration models

Both isolate your work, but the access model differs:

Branch model: you’re on the team, you have write access, you push branches to the shared repo and open PRs there. This is your day job at a company — splitease-api with your teammates.

Fork model: you want to contribute to a project you don’t have write access to (any open-source repo). You fork it — GitHub makes a full copy under your account — clone your fork, push branches to your fork, and open a PR from your fork back to the original. The original is conventionally added as a second remote called upstream so you can pull in its updates:

gh repo fork owner/project --clone        # fork and clone in one step
git remote -v                              # origin = your fork, upstream = the original
git fetch upstream
git merge upstream/main                    # keep your fork current with the original

Rule of thumb: branch when you have write access, fork when you don’t. Inside a company you’ll almost always use branches; the first time you contribute to open source, you’ll use a fork.

Check The Concept

How This Shows Up At Work

• The surprise conflict at pull. A teammate runs git pull on a stale branch, gets a wall of conflicts, and freezes. You git fetch + git log HEAD..origin/main first, see what’s coming, and decide calmly. The habit of fetch-then-look marks you as someone who understands remotes.
• The PR that ships your feature. Every line of splitease-api you ever ship in a job goes through: branch → push → gh pr create → review → green CI → merge. Knowing the gh loop cold means you spend your energy on the code, not on fighting the tool.
• The first open-source contribution. You find a typo in a library’s docs, fork it, fix it, and open a PR — your first commit in a stranger’s repo. Knowing fork-vs-branch is what makes that a 10-minute act instead of a confusing afternoon.
• The interview question. “Walk me through how your team’s code gets from your laptop to production.” The answer is this module — remotes, tracking branches, PRs, review, merge. A clear walk-through signals you’ve actually worked on a team.

Build This

All in PowerShell, using your real GitHub account and the free gh CLI. You’ll create a repo, set up the remote, push a branch, and run a complete PR loop from the terminal. (gh is free and the most useful single tool on this list — install it from cli.github.com if you don’t have it.)

1. Authenticate gh once (skip if already done) and create a throwaway repo:

gh auth login
gh repo create gh-pr-lab --private --clone
cd gh-pr-lab

gh repo create makes the repo on GitHub and clones it, so origin is already wired. Confirm:

git remote -v

You should see origin pointing at https://github.com/<you>/gh-pr-lab.git.

2. Make a first commit on main and push it:

"# gh PR lab" | Out-File -Encoding utf8 README.md
git add README.md
git commit -m "Add README"
git push

Note git push worked with no -u — clone/gh repo create already set main to track origin/main. Confirm:

git branch -vv

main shows [origin/main] — that’s the tracking link.

3. Branch, commit, and push with -u (the first push of a new branch needs it):

git switch -c add-license
"MIT" | Out-File -Encoding utf8 LICENSE.txt
git add LICENSE.txt
git commit -m "Add license file"
git push -u origin add-license

The -u created origin/add-license and linked them. Future pushes on this branch are bare git push.

4. Open and inspect the PR from the terminal:

gh pr create --title "Add license file" --body "Adds an MIT license"
gh pr status
gh pr view

gh pr create opens a PR from add-license into main. gh pr view shows it in the terminal; add --web to open it in the browser.

5. Merge it and watch the loop close:

gh pr merge --squash --delete-branch
git switch main
git pull
git log --oneline

--squash collapsed your branch into one clean commit on main; --delete-branch removed the merged branch on GitHub. Then git pull brought that merged commit down to your local main. The full ship cycle, all from PowerShell.

6. Break it on purpose — feel the stale-cache trap. Make a change directly on GitHub (edit the README in the web UI and commit), then back in your terminal:

git status          # still says up to date - it has not fetched
git fetch
git status          # NOW it says behind origin/main by 1 commit

That’s fetch-updates-your-knowledge live: git status was reading a stale photo until fetch refreshed it. Finish with git pull to sync.

Interview Practice

Real remote/collaboration git questions from backend and fintech interviews. Answer out loud first.

Where to Practice

Check Yourself

1. What is origin, and is the name special?
2. What does origin/main represent, and why can it be out of date?
3. State the difference between git fetch and git pull, and which is safe to run anytime.
4. What is a tracking branch, and how do you set one up for a new local branch?
5. List the steps of the PR workflow from branch to merged, using gh.
6. What’s the difference between --squash, --merge, and --rebase when merging a PR?
7. When do you use a fork instead of a branch?
8. Why does a fork-based contributor usually have two remotes, and what are they?

Explain it out loud: Explain to an empty chair how one line of code travels from your laptop to production — name every step (commit, push with tracking, PR, fetch/review, CI, merge, pull) and explain why git status can lie until you fetch. If you stumble on fetch vs pull, re-read that section.

Why AI Can’t Do This For You

AI can generate gh pr create commands all day. What it can’t do is know that your origin/main is stale because you haven’t fetched, that this branch was already pushed so a force-push would wreck a teammate, or that the right merge strategy for your team is squash because that’s the convention they agreed on. Those facts live in your remote and your team’s habits, not in any prompt.

And when “GitHub says something different from my terminal” at 11pm, the engineer who knows origin/main is a cached photo — and that git fetch is the free, safe way to refresh it — solves it in seconds. The collaboration loop isn’t knowledge you can paste in; it’s a reflex you build by pushing branches and shipping PRs until the remote model is something you feel.

Module done? Add it to today’s tracker