Pull request

The pull request sits between writing code and that code reaching customers. Without it, a mistake goes live as fast as a fix. With it, there is a point where tests run and a second pair of eyes, human or AI, can catch problems. This matters more as AI coding agents write more of the code, because they produce changes quickly and not always correctly.

It also leaves a record. Months later, the description explains why a change was made.

1. Create a branch for every change, however small, and never edit the main version directly.
2. Keep one purpose per pull request so review stays quick.
3. Let the automated checks, usually called CI/CD, run before a person reads anything.
4. Write the description as the reason for the change, not a list of edited files.
5. Require at least one approval before merging.

When someone changes code, they usually do it on a separate copy, called a branch. A pull request is the request to bring that branch back into the main version. It shows exactly which lines were added or removed, a space for comments, and the results of automated tests. GitHub popularised the name. GitLab calls the same thing a merge request.

For a non-engineer, think of tracked changes in a document sent for approval. The edits are visible, someone reads them, and only then are they accepted.

• Bundling many unrelated changes, so reviewers skim.
• Approving without reading because the tests passed. Tests only catch what they were written to catch.
• Leaving pull requests open for weeks, until they no longer fit the code they change.