Reviewing a pull request

Which pull requests you see

You see your own pull requests. You also see every open pull request whose changed files are all visible to you, whether they are Can read, Can edit or Types only. This includes the core team's and your teammates' pull requests.

When someone asks you to review (by mentioning @your-github-login on GitHub, requesting you as a reviewer, or with Gitfence's Ask for review), you get an email, and a Slack message if Slack is connected. The pull request comes first under To review, marked Review requested. Your own review answers the request.

An admin can also turn on Also show pull requests that partly touch hidden folders in the repository's Settings → GitHub Actions & collaboration section. It is off by default. When it is on, you see those pull requests too, but hidden files appear only as N files outside your access. Their names never appear.

Read the diff

Open a pull request and choose Files changed. You can use unified or split view, syntax highlighting, the file tree with +/- counts, and Viewed checkboxes.

Gitfence computes the diff from your own copy and its filtered history, never from GitHub's real diff. Hidden files never appear. For a types-only file, you see the diff of the generated declarations or stub as it exists in your copy.

Show more lines above and below a hunk and Expand all lines (the whole file) also read only from your copy.

Large diffs work like GitHub. A file with more than 2,000 changed lines is not rendered until you choose Load diff. The same applies when the diff passes 20,000 lines in total or contains more than 3,000 files.

Comment on lines

Review comments from GitHub appear inline at their line, as threads with replies. Comments on hidden files are left out. Comments on types-only files are left out too, because their line numbers refer to the real file, not the stub.

You can start a comment on any changed line in a file you can read or edit. You cannot start one on a types-only file. Gitfence posts the comment on GitHub through the Gitfence app as <name> (via Gitfence), on the same line of the real pull request. It first checks that the file is identical, so the line maps 1:1.

Submit a review

Choose Review changes, write a summary, then choose Comment, Approve or Request changes.

Gitfence always posts this on GitHub as a COMMENT review through the Gitfence app. 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. The approval comes from the app, not a person with GitHub access, and must not let the app's identity satisfy branch protection. A team member with GitHub access approves and merges.

You cannot approve or request changes on your own pull request. You can comment on it.

Suggestions

A reviewer's suggested change appears as a change, with the lines it replaces and the new lines. On your own open pull request, choose Apply suggestion. Gitfence commits it to your branch with the same checks as a push. Then run git pull before your next commit.

A suggestion cannot be applied to a file you can only read, to an outdated comment, or when it quotes code outside your access. Suggestions on hidden or types-only files never appear.

Resolve conversations

On your own open pull request, choose Resolve conversation on any review thread you can see. On someone else's pull request, you can resolve only threads you started. Choose Unresolve conversation to reverse it. The Gitfence app makes the change on GitHub.

Resolved threads are collapsed and say who resolved them. Choose Show resolved to read one.

Reactions

Conversation and line comments show reaction counts. Choose Add a reaction to add one. On GitHub, it is the Gitfence app's reaction, not yours. There can be one of each kind per comment across Gitfence members, and you cannot remove a reaction.

Labels, assignees and linked issues

The sidebar shows Review requested from, Assignees, Labels, Milestone and Closes when they are present.

On your own open pull request, you can set Labels from the repository's existing labels, except Gitfence's own labels. Those stay unchanged. You can set Assignees only from people already on the pull request. The Gitfence app makes these changes on GitHub.

Closes lists linked issues shared with you. Other linked issues are only counted, not named.

AI agents, REST and MCP

AI agents can read the same diff and review it through the REST API or MCP tools. For REST, send the token as Authorization: Bearer <token>.

• GET /api/collab/repos/<owner>/<repo>/pulls: your own pull requests in pullRequests, plus a reviewing list.
• GET .../pulls/<n>/files: JSON files with hunks and an outside count.
• GET .../pulls/<n>/files?format=patch: plain unified diff text.
• GET .../pulls/<n>/files?path=<file>: one file in full, as with Load diff.
• GET .../pulls/<n>/lines?path=<file>&side=RIGHT|LEFT&from=1&to=50: lines of the file from your copy.
• POST .../pulls/<n>/comments with {"path","line","side","body"}: add a line comment.
• POST .../pulls/<n>/reviews with {"event":"comment"|"approve"|"request_changes","body"}: submit a review.
• POST .../pulls/<n>/threads/<comment id> with {"resolved": true|false}: resolve or unresolve the thread starting at that comment.
• POST .../pulls/<n>/comments/<comment id>/reactions with {"content": "+1", "kind": "review"|"issue"}: add a reaction.
• POST .../pulls/<n>/suggestions/<comment id>: apply that comment's suggestion.
• GET .../pulls/<n>/options: list the labels and assignees you can choose.
• PUT .../pulls/<n>/labels with {"labels": [...]}: replace the pull request's labels.
• PUT .../pulls/<n>/assignees with {"assignees": [...]}: replace the pull request's assignees.

The MCP tools are:

• my_pull_requests, which also lists reviewing.
• pull_request_status.
• pull_request_diff with repo, number, optional path, and optional format set to "patch" or "json".
• pull_request_file_lines with repo, number, path, side, from and to.
• comment_on_line with repo, number, path, line, side and body.
• submit_review with repo, number, event and body.
• reply_to_review.
• resolve_thread with repo, number, comment_id and optional resolved, which defaults to true.
• react with repo, number, comment_id, content and optional kind set to "issue" or "review".
• apply_suggestion with repo, number and comment_id.
• set_labels with repo, number and labels.
• set_assignees with repo, number and assignees.

Next: code review, AI agents and MCP, and what syncs with GitHub.