GitHub CODEOWNERS vs PullApprove

The GitHub CODEOWNERS file uses a syntax similar to gitignore to define the "owner" of files in your repo. If your code review is only dependent on file ownership, and has simple requirements (i.e. 1 approval on every PR), then CODEOWNERS may be a good fit for you.

PullApprove also allows you to define file ownership, but goes beyond that in allowing other rules for assigning PR reviewers. In PullApprove you can use a combination of the files modified, labels applied to a PR, who authored the PR, or even the size of the change to determine who needs to review it.

Further, PullApprove lets you specify the exact approval requirements depending on the type of review. A documentation change, for example, may only require one approval while a more complex backend change requires two approvals from more senior engineers.

Let's look at an example of how this might work in CODEOWNERS vs PullApprove.

CODEOWNERS

First, you would have a CODEOWNERS file in your repo that looks something like this:

/docs/ @docsReviewer
/app/ @backendReviewerA, @backendReviewerB, @backendReviewerC

Then in your branch protection settings, you have the option to require a PR, approval from code owners, and set a required number of approvals.

GitHub CODEOWNERS branch protection settings

This works well for choosing to require one approval on every PR, or two approvals on every PR, etc. But you cannot be more granular than that – every PR will be subject to the same number of approvals. If you choose to require one approval, then you cannot require more approvals on PRs with more significance. If you choose to require two approvals, then trivial PRs will require two approvals as well which could be frustrating and slow down developers.

PullApprove

In PullApprove we have the concept of review teams, and each team can have their own assignment conditions and approval requirements.

The "Docs" team, for example, can choose to require only one approval:

The "App" team has a similar setup, but can choose to require two approvals:

Now in a pull request step, you can automatically request review from all matching teams, and each team will have their own requirements for approving the PR.

PullApprove review phase with teams

You can further design your PR workflow to require tests to pass before review starts, or send notifications to instruct the PR author on next steps (and more).

This is a simple example, but hopefully shows a couple of key differences between GitHub's CODEOWNERS and PullApprove's review teams. If you have any questions, feel free to ask!