By the end of this lesson, cadets will be able to:
git status and git log to stay oriented, and apply branching strategies appropriate to a project's complexity. (Outcomes 6, 7)Complete before class. These set the vocabulary we will use.
| Source | Sections | Why |
|---|---|---|
| Beej-Git | Ch. 5-6 (Branches and Fast-Forward Merges, Merging and Conflicts) | The exact mechanics we practice in class: branches, both kinds of merge, and conflict resolution |
If branches and merges are brand new to you, read both chapters closely; they map one-to-one onto the two walkthroughs in Section 5.
git switch, git branch, git merge<<<<<<<, =======, >>>>>>>)Today Git stops being a straight line. The reference below covers the concepts you will see in lecture and practice in the two walkthroughs. Read it before class or use it as a reference during the lab.
The Lesson 24 deck covers branches and HEAD, the two kinds of merge, reading conflict markers (including how your editor shows them), the resolution workflow, branching strategy, and a look ahead to Lesson 25. The slides are the spine of the in-class lecture; the two walkthroughs are where you practice hands-on.
A commit is a snapshot of your files. A branch is nothing more than a lightweight, movable label that points at one commit. HEAD is the special label meaning “where you are right now.” When you are “on main,” that literally means HEAD points at the main label.
Creating a branch does not copy your files. Git just writes a tiny new label. That is why branches are cheap and used freely. The four commands you need today:
We use git switch, the modern command, rather than the older git checkout. Both do the job; switch states the intent more clearly.
When you merge a branch in, Git does one of two things depending on a single question: did the branch I am merging into move since the two branches split?
Conflicts only happen in three-way merges, and only when the two sides touched the same lines. A conflict is not an error you caused wrongly; it is Git asking you to make a decision it cannot make for you.
When an auto-merge fails, Git rewrites the contested region of the file with three marker lines. Read them like this:
The top section (between <<<<<<< HEAD and =======) is yours. The bottom section (between ======= and >>>>>>>) is theirs. Your editor shows the same thing with colored “Current Change” and “Incoming Change” buttons; those buttons just edit these exact marker lines for you.
The single most common mistake: leaving marker lines in the file. The markers are not data. To resolve a conflict you delete all three marker lines and leave the file reading the way it should. Then the four-step workflow:
Lost in the middle of a merge? git merge --abort resets everything to before the merge. Nothing is permanent until step 4.
Branches are cheap, but a tangle of them is not free. Match the strategy to the work: commit small solo changes straight to main; branch anything risky or experimental so a failure leaves main untouched; and on a team, use one branch per feature or per person and merge back often. The biggest lesson from past team projects: small, frequent merges keep every conflict tiny, while saving one giant merge for the end guarantees pain. You will live this in the team project soon.
Three things to do in class. Use the checklist to track your progress.
Fourteen tasks across five sections. Type each Git command at the prompt. The left pane is your terminal; the right pane draws the commit graph as it changes.
Enter your name. It will appear on the completion screen so you can include it in your screenshot for the Lesson 24 reflection.
git log --oneline --graph --all draws.Thirteen tasks across five sections. You will trigger a real conflict, read the markers in the middle pane, fix the file, and finish the merge. This is the part that trips people up the first time, so the widget narrates every step.
Enter your name. It will appear on the completion screen so you can include it in your screenshot for the Lesson 24 reflection.
coffee_run.txt. You will trigger the conflict on purpose, read what git wrote into the file, fix it by hand, and finish the merge. The middle pane is the actual file; watch it change as you go.git merge --abort in your real terminal throws the whole merge away and puts the file back exactly as it was, so you can start over. Nothing you do during a conflict is permanent until you commit. This simulated shell understands the commands the task asks for; follow the card and you cannot break anything.