Lesson 06 · team collaboration · capstone
The last piece: how your local pointers talk to a server. Master one idea — a remote is just more pointers, living somewhere else — and pushing, PRs, and reading a shared graph all fall out of it.
You use push and pull by habit but have no model underneath. This lesson gives you that model, and with it the two final mission goals: open a clean pull request, and read git log --graph on a shared repo. Everything rests on one extension of the pointer idea from Lesson 02.
origin is Git's default name for the server repo you cloned from (GitHub, GitLab, a colleague's machine). It's a full copy of the repo — same commits, its own branch pointers. Your local main and the server's main are two independent pointers that happen to share history.
To track the gap, Git keeps a third pointer locally: origin/main — a remote-tracking branch. Read it as: "where the server's main was the last time I synced." It's a cached bookmark, not live. It moves only when you fetch, pull, or push.
This graph says: you're 2 ahead of the server. git status literally prints "Your branch is ahead of 'origin/main' by 2 commits." Now it means something — it's comparing your main pointer to the origin/main cache.
git fetch downloads the server's new commits and moves origin/main — but does not touch your main. It's the safe "show me what's new" with zero risk. git pull = fetch then merge origin/main into main — it downloads and merges in one step, which is where surprise merge commits and conflicts come from. When unsure on a shared repo, fetch first, look, then merge deliberately.
A pull request (PR) is a GitHub/GitLab feature, not a Git command: "please review my branch and merge it into main." The Git half is just pushing a branch; the review half lives on the website.
git switch -c feature, commit your work — exactly Lesson 04. Never work directly on main on a team.git push -u origin feature. The -u (upstream) links your local feature to origin/feature once — after that, plain git push and git pull know where to go. GUI: "Publish Branch" in the Source Control panel.main ← compare feature. Title + description explaining why. This starts the review.git push. The PR updates automatically — no new PR needed. Repeat until approved.--no-ff merge commit by default — see Lesson 04), then delete the branch. Locally: git switch main, git pull to catch up."wip" / "fix typo" / "actually fix" noise. Two tools you already own from the solo half — commit --amend to fix the last commit before pushing, and git reset --soft to squash a few messy commits into one clean one before the PR. Both are history rewrites, so only on your unpushed branch — the reset-before-share rule still holds.
The final mission goal. One command shows every pointer — local and remote — at once:
git log --graph --oneline --all --decorateRead it bottom-up: history forked at 7a8b9c, two commits happened on feature (the second one addressing review), then f3a1c2 is the merge commit that rejoined them into main. The |\ and |/ are the fork and the rejoin — the exact three-way-merge shape from Lesson 04, now with remote pointers labelled. You can reconstruct what the team did without asking anyone. GUI: the Git Graph extension, or Source Control → "…" → View History, draws this same graph.
Primary source — read this one: Pro Git §3.5, "Remote Branches". The definitive treatment of origin/main, tracking branches, and fetch vs. pull, with Git's own pointer diagrams.
Then do it for real: GitHub Skills — guided courses that run inside a real GitHub repo, walking the full PR + review loop. The one resource in the workspace built specifically for this workflow.