Articles

Is this pull request safe? A checklist for people who don’t read code

You don’t need to read code to tell whether a pull request is safe to approve. Check four things, in this order. It takes about a minute.

Checklist4 min read

A pull request is a proposed change to your product’s code, waiting for someone to approve it. If you asked for the change, you are often the best person to say whether it does what you wanted, and you can do that without reading a line of code.

Work through the four steps below in order. Tick them off as you go, or print the page and keep it next to you.

Names follow GitHub. On GitLab a pull request is called a merge request; the same checks apply.

0 of 9 checked

  1. Title and description

    Start at the top of the pull request, before anything else.

    Stop and ask if you see

    • Titles like “fix stuff”, “misc fixes” or “updates”.
    • An empty description.
    • A description that explains how the code works, but not what you will see.

    If the title and description don’t tell you what changed, ask before you look any further. That is a fair request, not a nitpick.

  2. Files changed

    Open the Files changed tab. Read the file names, not the code.

    Stop and ask if you see

    • Names with payments, billing, checkout or pricing.
    • Names with auth, login, session, permissions or roles.
    • migrations, schema or anything that sounds like the database.
    • .env, secrets, keys or config files.
    • Infrastructure and pipeline files, such as .github/workflows or terraform.

    A button-text change that touches a payments file isn’t necessarily wrong. But someone should be able to tell you why in one sentence.

  3. The preview

    If your team builds a preview for each pull request, there will be a link in the conversation. Open it.

    Stop and ask if you see

    • A visual change with no preview and no screenshot.
    • The preview shows something different from what the description says.

  4. The checks at the bottom

    Scroll to the bottom of the Conversation tab, where the automated checks report.

    Stop and ask if you see

    • Any red cross, however small the change looks.
    • Checks that are still running or were skipped. Not finished is not the same as passed.
    • Someone suggesting you merge over a red check “because it’s flaky”, without an engineer saying so in writing.

    Green means the automated tests passed. It doesn’t mean the change is what you asked for. That’s what steps one to three are for.

When to bring in an engineer

  • Any red flag above that nobody can explain in a sentence.
  • The change touches payments, login, permissions, data or infrastructure.
  • A check is red, or a change that matters to customers has no tests at all.
  • Your gut says it is bigger than it looks.

What to write when something looks off

Copy this into a comment on the pull request and fill in the blanks:

Thanks for this! Before I approve, can you help me understand: 1. Why does this change touch [file or folder]? 2. Is there a preview I can try? 3. Is anything else affected that I should test?

Approving a pull request is a judgment call, not a code review. These four checks make it an informed one.