Explain a change before review
See this course’s project requirements
A local repository with a readable change history, two merged contributions, a resolved practice conflict, and an evidence-based review note.
Keep your working files in your own notebook or software. Save a private description, checklist, and work link in My Proof.
What to include
- Base and clarification commits.
- Review note grounded in an actual diff.
- Merged independent title contribution.
- Resolved hours conflict using the approved policy.
- Final files, history evidence and recovery note.
Review and revise
Use these criteria to check your work and choose what to improve.
- History records meaningful changes.
- Final notice matches all four required lines.
- Conflict resolution retains unrelated content.
- Review and recovery claims are accurate.
Want more background?
The idea in everyday life
A teammate should understand the repair-cafe change without opening every file.
A review connects a proposed change to its effect and evidence.
Explain a change before review — guided practice
Write a review note grounded in an actual diff.
Continue after lesson 2. Run git log --oneline. The newest commit is the clarification; its parent is written HEAD~1.
1. Compare saved snapshots
Run the supplied command.
git diff HEAD~1 HEAD -- notice.txtYou should see: The diff shows the Bring replacement and Access addition.
Comparing commits makes the explanation repeatable.
2. Read context
Open notice.txt and read all four lines.
You should see: Hours remains 10-12; the event name remains Repair Cafe.
A changed line can be correct only in context.
3. Draft a review
Create review.md with: Purpose: clarify suitable items and entrance. Changed: Bring and Access. Checked: event and hours unchanged.
You should see: The note distinguishes the intention from what was actually checked.
Review notes are evidence, not generic praise.
4. Check the scope
Run git status --short; leave review.md untracked until lesson 6.
git status --shortYou should see: Only ?? review.md is new.
Keeping this note outside the current commit makes the next branch exercise predictable.
What to finish
A concise review.md that cites two changes and one verified invariant.
Watch for this
Claiming tests or accessibility checks that you have not performed.
How can I tell I understand it?
Complete the changed case, explain your result, and pass the three application checks.
Quick knowledge check
Answer all 3 questions. Get at least 2 right and the lesson completes automatically.
You’ll get an explanation for each answer. Signed in? Your results save to your account.
Pass the check. We’ll save the progress.
Answer all 3 questions above and get at least 2 right. You can review the explanations and try again.
Go to the knowledge checkOptional course overview video · same video as Lesson 1
Lecture 6: Version Control (git) (2020)
From Missing Semester. Watch here or open it on YouTube .
Optional course overview. Follow the written steps below at your own pace.Tools, templates, and lesson sources
Tools and templates
Tools open in a new tab so you can keep your place here.
Sources and further reading
Explore the references behind this lesson.
Source & access notes · checked 2026-09-12
Opened and inspected on 2026-09-12: Tracked, staged and modified states.
Access: Free public web page; no paid enrollment required.
Reuse: CC BY-NC-SA 3.0 book; link only.
Report a problem with this lesson
Tell us what went wrong. Please leave out personal information and private project contents.