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."