Unit 08 · lesson
Review a Change Before Merging It
A branch can contain valid code that you still should not merge.
Review asks a different question from "does it build?"
Four review layers
Source
Is the change understandable and scoped?
Build
Does Jekyll build successfully in the intended environment?
Generated output
Did the expected pages/assets change and nothing surprising change?
User experience
Do links, responsive behavior, keyboard access, and content still work?
Review checklist
Before merging a portfolio branch:
[ ] git diff reviewed
[ ] no secret/private files added
[ ] build succeeds
[ ] generated output inspected
[ ] affected pages tested
[ ] deployment assumptions considered
[ ] accessibility regression check where relevant
[ ] commit messages make sense
Review is not only for teams
Even if you are the only developer, a branch/pull-request review creates a pause between "I wrote it" and "this becomes production source."
That pause catches assumptions.
Rejected change
Find one thing in your branch you would not merge as-is.
Maybe:
- debug marker;
- copied secret path;
- temporary CSS;
- theme experiment;
- hard-coded URL.
Remove/fix it before merge.
Checkpoint
Write one review comment to yourself or a peer that references specific source evidence and expected output, not a generic "looks good."