Pull requests from your Git host

Check out a colleague's pull request into its own worktree with nothing but its number, run it, review the commits, push a fix to it, and watch it leave the board when it merges. Mergepond does not talk to your host's API; it fetches the pull/N/head ref that GitHub and compatible hosts expose over plain Git, so it works with any remote you can fetch from, with no token to set up.

Updated 10 November 2026

Check out a pull request

  1. Press ⌘⇧N, or choose File › New Worktree from Pull Request…. The new-worktree sheet opens with "Pull request" selected.
  2. Type the "Pull request number", say 412. The sheet explains what will happen: "Fetched from origin into the branch pr-412".
  3. The Folder fills in from your pattern, so the worktree lands at ../api.worktrees/pr-412. Leave "Run the setup recipe" ticked if you want it built and ready to run.
  4. Click "Create worktree". Mergepond runs git fetch origin pull/412/head:pr-412 and checks the branch out in the new folder.
  5. Open it in a new window from the sheet, or find its card on the board with ⌘3.
A pull request worktree on the board next to your own work.

Your own branch and working folder are untouched. When you are done with the review, remove the worktree from its card and your disk is as it was; the pr-412 branch stays until you delete it from the sidebar.

Review it

  1. Press ⌘2 in the pull request's worktree. Its commits sit above the point where it left your default branch.
  2. Click each commit to read the diff in the inspector, or right-click the first one and pick "Interactive rebase from here…" if you want to see the whole series as one list.
  3. Run the project from the worktree's folder. "Open in Terminal" is on the card and in the sidebar's right-click menu.
  4. Leave your comments on your Git host as usual. Mergepond's part is giving you a real checkout to test against.

Push a fix to the pull request

If the pull request's branch lives in the same repository, you can commit to it from the worktree and push.

  1. Make the change, stage it and commit with ⌘⏎.
  2. The branch pr-412 has no upstream, so the card moves to Ready for review and the board shows "Ready for review" on it.
  3. Push to the pull request's real branch from Terminal: git push origin HEAD:feat/search. Mergepond's Push button pushes pr-412 under its own name, which would create a new branch on the remote rather than update the pull request.

For a pull request from a fork, the fetch still works, because hosts expose fork pull requests under the same pull/N/head ref, but pushing needs the fork as a remote; do that in Terminal too.

When it merges

Once the pull request is merged and its branch deleted on the host, the next Fetch (⌘⌥F) marks the worktree "Merged" or "Branch gone on the remote" and moves its card to Merged or gone. "Clean up" removes it with everything else in that column, and says how much disk comes back.

Your own pull requests

Push your branch with ⌘⇧↑. The first push of a new branch sets its upstream on your default remote, and from then on the card shows how many commits are waiting to push. Open the pull request on your Git host the way you normally do; when it merges and the branch is deleted there, the card moves to Merged or gone and Clean up tidies it away.

Get more from it

  • Reviewing a pull request in a worktree means your own branch keeps running in its own folder. Two dev servers, two ports, no stash.
  • The palette has "Create worktree from a pull request" so you can type ⌘K, "pull", ⏎, 412.
  • Setup recipes run for pull request worktrees too, so a reviewer's checkout can be built before you have finished reading the description. See Worktrees that set themselves up.
  • For a run of pull requests, create them all first and let the board tell you which are ready while you review the first one.