Welcome to the NZRT Wiki Podcast. Today we’re looking at Pull Requests.

If you’ve ever worked on a codebase with other developers, you’ve probably come across pull requests. But what exactly are they, and how do they work at NZRT? Let’s walk through everything you need to know.

A pull request — or PR for short — is the main way code changes get reviewed and merged into a shared codebase on GitHub. When you’ve been working on a feature or a fix in your own branch, a pull request is how you say “hey, I’ve got some changes here — can someone check them over before we bring them in?” It creates a structured, documented process around that conversation.

When you open a PR, a few things happen automatically. First, GitHub shows a visual diff — that’s a line-by-line comparison of everything you’ve changed. Anyone reviewing can see exactly what was added, removed, or modified. Second, all the commits you made on your feature branch are listed, so reviewers can follow the history of your work. Third, GitHub Actions kicks off — those are automated workflows that run checks like linting, testing, and security scans. These have to pass before the PR can be merged.

Then comes the human part. One or two of your peers — depending on how the repository is set up — will review your code. They can leave comments, ask questions, or request changes. If changes are needed, you push additional commits to address the feedback, and those appear in the PR automatically. Once a reviewer is satisfied, they approve, and a maintainer can merge it in.

Let’s talk about how NZRT specifically handles this. It follows a ten-step flow. You start by creating a feature branch with a descriptive name. You make your changes and commit them with clear messages. Then you push that branch up to GitHub and open the pull request with a title and description. You wait for GitHub Actions to pass — that covers linting, testing, and a security scan. Then you request a review from one or two developers. You address any feedback, push more commits if needed, get an approval, and finally a maintainer merges the PR — usually using a squash merge into the develop branch. After that, the branch is automatically deleted, which keeps things tidy.

Now let’s cover PR title format. The title follows a short, structured pattern. You start with a type — for example, feat for a new feature, fix for a bug fix, docs for documentation, style for formatting changes, refactor for restructuring code, perf for performance improvements, test for anything test-related, or chore for maintenance tasks. After the type, you put the scope in parentheses — that’s the area of the codebase you’re touching, such as dolibarr, wp-sync, or scripts. Then a colon, followed by a brief description. So as a spoken example, a PR adding a product comparison widget to the WordPress sync area would read something like: feat, wp-sync scope, add product comparison widget.

PR descriptions follow a standard template with four sections. The first is a plain description of what the PR does. The second links to a related issue — if the work closes a tracked issue, you reference it there. The third section covers testing — you explain how someone can verify the changes work correctly. And the fourth is a checklist: does the code follow the style guide, were tests added or updated, was documentation updated, and are there any breaking changes? Having this template means every PR carries the same core information, making review faster and more consistent.

One more thing worth knowing: NZRT supports draft PRs. If you’re still working on something and not ready for review, you can open it as a draft. That signals to the team it’s a work in progress, so nobody jumps in to review before you’re ready.

There are also three ways a PR can actually be merged. A merge commit preserves all your individual commits as-is. A squash merge combines everything into one clean commit — this is the most common approach at NZRT. And a rebase replays your commits on top of the target branch. Each repository can be configured to support one or more of these strategies depending on what works best for that codebase.

Pull requests aren’t just a gate before merging — they’re a collaboration tool. They create a record of why changes were made, who approved them, and what feedback was exchanged. Over time, that history becomes genuinely valuable for anyone working in the same codebase.

That’s it for this episode of the NZRT Wiki Podcast. Thanks for listening.