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.

Older links using /pulls/<number> continue to work and redirect to the canonical /pull/<number> address. Their /commits, /diffs, and /files variants also redirect; /files resolves to the canonical /diffs tab.

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.

The diff toolbar shows total added (+) and deleted (-) lines across the changed files once their counts load. If a file has no line counts, the toolbar reports that line totals are unavailable. Binary files do not contribute text lines.

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 list changed files with the pull request changes operation, which returns metadata only, then use the pull-request diff operations to request patches for 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. The single-file operation can also return rename-aware old/new contents without regenerating patches. Refresh the comparison if either operation 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.

To change the target branch of an open pull request, use the CLI from the repository with edit access to the pull request:

Replace 27 with your pull request number. The new target must already exist. The comparison, readiness and merge checks then use the new branch. Members of a stack follow their stack instead (see stacks), and pull requests in a repository mirrored from GitHub change their base on GitHub.

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.

Read commits and diffs as Markdown#

Append ?format=markdown to a pull request's /commits or /diffs URL, or request the same URL with Accept: text/markdown. The same read permissions apply as in the browser; private pull requests are not exposed anonymously.

Each document contains up to 20 commits or changed files. Files include text diff hunks where available, with explicit notices for binary, oversized or budget-limited patches. Follow Next page links without editing their revision parameters. If the pull request changes and a continuation fails, reopen the first page to read the new revision.

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. Native merge commits use gitcafe <noreply@gitcafe.dev> for system attribution.

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.

A pull request whose latest head commit reaches the default branch another way, such as a direct push, is marked Merged by the person who pushed. Only the exact head commit counts: a rebased or squashed copy is not detected, so close that pull request by hand.

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.