Review and merge a pull request#

Open a pull request from the repository's Pull requests tab. You need read access to see it; review, merge and moderation controls depend on your repository permissions.

Read the changes#

• Conversation contains the description, checks, comments and reviews.
• Commits lists the commits in the proposed change, newest first. Select a commit to inspect it, or use the page controls to see more.
• Files changed shows the diff and inline review threads. See reviewing changes to leave comments or submit a review.

For large pull requests, scroll continuously or use the file tree to jump to a file. Patches load automatically in successive batches of up to 64 without page controls. If one file cannot load, retry that file; the other changes remain available. Binary files and files too large for an inline diff still appear in the list. Full file contents load separately near the viewport, at most two files concurrently, for highlighting and context expansion. Loaded patches belong to the open diff; there is no added retained patch cache. Commit pages also load patches automatically.

API clients can request patches with POST /api/repos/{owner}/{repo}/pulls/{pr}/diff-files, passing { "paths": [...], "expectedVersion": number } with 1–64 unique paths. The response preserves path order and includes snapshot identity, without full text. Entries marked hunksOmitted: true can be requested in a smaller selection. Use GET .../diff-file?contentOnly=true with path and expectedVersion to fetch rename-aware old/new contents without regenerating patches. Refresh the comparison if either request rejects a stale version.

From the repository, cafe pr diff <number> lists changed files. Add --patch for their patches, or --path path/to/file to inspect one file directly. The CLI follows additional file pages automatically.

The source and target branch names identify what will be merged and where. A pull request from a fork shows its source as owner:branch, or deleted fork if that fork is gone.

When new commits arrive, review the refreshed comparison before approving or merging. Previous reviews remain attached to the commits they reviewed; whether an approval becomes stale depends on the repository's rules. If an action reports that the revision changed, refresh and review the latest changes before retrying.

A private fork requires read access to its source to refresh the comparison. Without it, the saved comparison can remain readable, but review submission and merging must wait for current source access. Deleted forks retain their saved comparison.

Merge or close#

For an open pull request, use the merge button's menu to choose Merge, Squash and merge, or Rebase and merge. Unavailable methods are labeled. For repositories mirrored from GitHub, GitHub performs the selected merge.

Read the merge requirements before proceeding. N blockers or Conflicts opens the details; protected branches also show whether merge requirements are met, blocked, or have warnings. Resolve the reported checks, reviews, conflicts or permission problems before trying again. See repository rulesets.

If the latest commits from a fork have not arrived yet, choose Retry to check again. Merging remains unavailable until they arrive.

Draft pull requests offer Ready for review. The menu also offers Convert to draft and Close pull request when applicable. Closed pull requests can be reopened; merged pull requests stay marked Merged.

If Automatically delete head branches is enabled, GitCafe removes eligible same-repository source branches after merging. Default and target branches, protected branches, and branches used by another open pull request are kept. You can restore a retained branch from repository General settings.

Organize the review#

The author or a maintainer can edit the title and description using their pencil controls. Depending on your permissions, the sidebar also lets you:

• Request reviews from repository members and see their review status.
• Set assignees, labels and a milestone.
• Inspect checks for the current head commit.
• Lock or unlock the conversation. A locked conversation cannot accept ordinary comments until a maintainer unlocks it.

Moderate comments and reviews#

Maintainers can hide or unhide a comment from its menu and dismiss a review from its review card. Hidden comments keep their place in the discussion; dismissed reviews remain visible and marked as dismissed.

If someone else changes the pull request, comment or review while you are editing, reload and review their changes before retrying.