Code review

Steps

1. Open the pull request. In a repository, open Pull requests. Filter with All, Needs a human or Low risk, expand a row to read its summary, then choose Review on GitHub. A team member with GitHub access approves and merges there.
2. Read the summary. It lists changed files and folders, the risk areas touched, new and changed dependencies with versions, the test result when available, and the person or agent who made the change.
3. Approve the exact version. For a Needs a human change, a person with GitHub access reviews that commit on GitHub and approves it. The check passes and its title becomes Approved by @name (touches …). Bots and the author do not count.
4. Make the check required. On GitHub, open the default branch's branch protection, turn on Require status checks to pass, and add Gitfence review. Pull requests that did not come through Gitfence pass it automatically.
5. Adjust the areas. In the repository, choose Risk areas to open Settings → Changes a person must review. Untick built-in areas, or add Your own areas with Add an area, an Area name and Folders, files or words. Then choose Save risk areas.

Built-in risk areas

• Sign-in and security
• Payments and billing
• Database migrations
• CI, deploy and infrastructure
• Dependencies
• Permissions and policies
• Secrets and keys

What restricted people see

Restricted people work in a GitHub-like view inside Gitfence, built from their own copy of the repository. It has Code, Pull requests and Issues tabs:

• Code: browse folders and files with syntax colours, the README and the last commit per entry. Types-only files carry a badge. Press t to find a file.
• Pull requests: Conversation (reviews, review threads with their code, commits pushed and the checks), Commits, Checks and Files changed (a file tree, unified or split diff, inline threads). They can reply to a thread and comment on any changed line in a file they can read or edit.
• Issues: issues shared with them by label, with replies.

Review sync goes both ways. Your reviews and comments on GitHub (including bots like CodeRabbit) come back to them with hidden content redacted; comments on hidden or types-only files are dropped, and hidden content shows as Hidden by your access. Their replies and line comments are posted to the same GitHub thread through the Gitfence app, as "alice (via Gitfence)". Your team can keep reviewing on GitHub.

A separate Gitfence check confirms the branch still matches what Gitfence delivered and scans added lines for fingerprints of hidden code.

Contractors reviewing pull requests

To ask a contractor for review, mention @their-github-login in the pull request (its description, a comment or a review); GitHub can only request reviews from collaborators. Admins can also use Ask for review on Gitfence's Pull requests page, which posts nothing on GitHub. The contractor is told only if they can see the pull request, and it comes first in their To review list.

Contractors see their own pull requests. They also see open pull requests when every changed file is visible to them, including files marked Types only. By default, a pull request that touches a hidden folder stays out of their list. An admin can change this in Settings → GitHub Actions & collaboration with Also show pull requests that partly touch hidden folders. The hidden files then show only as N files outside your access, never as names.

The Files changed tab builds the diff from the contractor's own filtered copy, not GitHub's diff. They can review the core team's and teammates' pull requests, reply to threads and comment on changed lines in files they can read or edit. Reviewing a pull request explains the contractor view.

Review changes offers Comment, Approve and Request changes. On GitHub, all three are posted by the Gitfence app as a COMMENT review. An approval starts with ✅ Approved these changes; a request for changes starts with 🔴 Requested changes. It never counts as a GitHub approval: it does not satisfy branch protection's required approvals or CODEOWNERS review, and it does not block merging. Otherwise the app's identity, rather than a person with GitHub access, could satisfy branch protection. A team member with GitHub access must approve and merge. Contractors cannot approve or request changes on their own pull requests.

Notifications

Members get email, and Slack DMs when Slack is connected, for review requests and activity on their pull requests. While the code is locked, messages leave out titles, comment text, file paths and check names. See Notifications while the code is locked.

Gotchas

• Low risk means the changed paths matched none of your risk areas. It is not a statement that the code is correct, secure or tested.
• A GitHub approval only counts for the exact commit reviewed. Pushing a new commit needs a new approval.
• If the branch changed outside Gitfence after it was submitted, the report says Needs a human (changed outside Gitfence) and an approval does not make it pass.
• Changing risk areas re-evaluates open pull requests. Labels and requested reviewers are best effort.

Next: AI agents and MCP and Types only.