By the end of this lesson, cadets will be able to:
fetch, pull, and push. (Outcomes 6, 7)Complete before class. These give you the vocabulary we will use in the walkthroughs and labs.
| Source | Sections | Why |
|---|---|---|
| Beej-Git | Ch. 9, 10, 14, 17 (Remotes: Repos in Other Places, Remote Tracking Branches, Collaboration across Branches, GitHub: Forking and Pull Requests) | How remotes, push/pull, and pull requests actually work |
| Supplementary notes (instructor) | Code review workflow and conventions | What a good review comment looks like; severity and tone |
origin, and remote-tracking branches (origin/main)fetch vs pull vs pushgit pull can produce a merge conflict, and you resolve it the exact same way you did in Lesson 24. If that feels rusty, skim your Lesson 24 notes so it is fresh.Lesson 24 gave you branching, merging, and conflict resolution on a single machine. Today the repository lives in more than one place, and the new skill is keeping those copies in agreement while a teammate is changing the same code. The reference material below covers the concepts you will see in lecture and practice in the two walkthroughs.
The Lesson 25 deck covers the local-versus-remote mental model, the four sync commands, the rejected push, pull requests, and what makes a good code review comment. The slides are the spine of the lecture; the two walkthroughs in Section 5 are where you practice.
When you clone a shared repo, you end up with three things that matter. There is your local main (the branch you actually work on), the remote main on GitHub (the shared truth your teammates pull from), and a third thing called origin/main.
origin/main is a remote-tracking branch: your local copy's memory of where the remote was the last time you talked to it. It is not a live feed. The remote can move forward (a teammate pushes) and your origin/main will not know until you clone, fetch, or pull. Almost every sync headache traces back to that snapshot being stale.
| Command | What it does |
|---|---|
| git clone <url> | Copy a remote repo to your machine, once, at the start. Sets up origin automatically. |
| git fetch | Download the remote's new commits but do not merge them yet. Updates origin/main. The cautious "let me look first" move. |
| git pull | fetch then merge in one step. Brings remote work into your branch. Can produce a merge conflict. |
| git push | Upload your local commits to the remote so others can get them. |
If a pull reports a conflict, resolve it exactly the way you did in Lesson 24: open the file, fix the conflict markers, then add and commit. The skill carries over unchanged.
This is the single most common collaboration error, and it is Git protecting you, not failing. It happens when a teammate pushes to the remote after your last sync, so the remote has a commit you do not. When you try to push, Git refuses:
The fix is always the same: git pull to bring in the teammate's work (resolving any conflict), then git push again. Read the hint Git gives you; in this corner of Git the error messages tell you exactly what to do. You will make this rejection happen on purpose in the remote_sync walkthrough.
On a team you usually do not push straight to main. Instead you do your work on a feature branch, push the branch, and open a pull request: a request to merge your branch into main. The name is a little confusing because it has "pull" in it, but it is about getting your work merged in, not pulling work down.
A pull request is a conversation around a diff. The title says what changed, the description says why, and reviewers leave comments before anything merges. That review checkpoint is how a team catches problems before they reach the shared branch and everyone's copy. In Lab 1 you open a real pull request for a small Summit Log feature.
A useful review comment is three things at once: specific (it points at a line and names the actual issue), actionable (it says what to change or check, ideally with a suggested fix), and kind (it is about the code, not the author, and assumes good faith). Compare:
i <= n, but valid indices are 0..n-1, so this reads one past the end. Should it be i < n?”Lead with correctness. A review that flags whitespace while missing a buffer overflow has failed at the one job that mattered. Style and personal preferences come after, and should be clearly marked non-blocking so the author knows what truly must change before merge.
Reviewing is a form of testing. Some bugs compile cleanly under -Wall -Werror and still do the wrong thing; the only tool that finds them by inspection is a careful human reading the code. Ask of every change: what is the worst input this could get, and what would it do? That question is what you will practice in the code_review walkthrough and apply for real in Lab 2.
Four things to do in class. Use the checklist to track your progress.
elevation_per_mile feature on a branch and open a pull request against your team's main. Half autograded, half checked on your PR.
REVIEW.md. You must catch at least one correctness bug, not just style.
Thirteen tasks across four sections. Type each git command at the prompt. The terminal shows what git did; the right pane shows how your local branch and origin/main line up. Watch the right pane when the teammate pushes and when your push gets rejected.
Enter your name. It will appear on the completion screen so you can include it in your screenshot for the Lesson 25 reflection.
Ten short diffs from a Summit Log pull request. For each, read the code and pick the strongest review comment. Choosing reveals why it is strong or weak; you must choose before you can advance. There is no score, the goal is to train your eye before Lab 2.
Enter your name. It will appear on the completion screen so you can include it in your screenshot for the Lesson 25 reflection.
REVIEW.md for Lab 2.