Browse, review, and merge pull requests
GitHub, GitLab, Bitbucket, and Cursor Origin — what the PRs tab can do on each forge, and where tokens live.
Switch to the PRs tab to browse, review, and merge pull requests for the repository you have open. GitHub gets the full experience; GitLab merge requests, Bitbucket Cloud pull requests, and Cursor Origin pull requests cover the core workflow.
What's supported where
| Capability | GitHub | GitLab | Bitbucket | Origin |
|---|---|---|---|---|
| List, detail, full diff, commits | Yes | Yes | Yes | Yes |
| Create PR/MR (including drafts) | Yes | Yes | Yes | Not yet |
| Merge (merge commit / squash) | Yes | Yes | Yes | Yes |
| Rebase merge | Yes | — | — | — |
| Approve | Yes | Yes | Yes | Not yet |
| Comments, review threads, request changes | Yes | Not yet | Not yet | Existing threads |
| CI checks (live polling) | Yes | Not yet | Not yet | Not yet |
| Close / reopen / mark ready | Yes | Not yet | Not yet | Not yet |
| Stacked PRs (stack card, merge stack) | Yes | — | — | — |
Not yet is planned in GitLane. A dash means the forge does not offer it. Origin merge is squash or merge commit only — no rebase, no delete-branch.
Where something isn't supported, GitLane says so explicitly rather than failing with a confusing error from the underlying CLI or API.
Connecting each forge
- GitHub — GitHub CLI
gh2.95+.gh auth login. Multiple accounts and GitHub Enterprise are both supported; GitLane binds each repository to one account rather than mutating your globalgh auth switchstate. - GitLab —
glabsigned in, or a personal access token in Settings → Accounts (REST v4). Native OAuth (device flow) is also available; the token lands in your OS keychain. - Bitbucket — no first-party CLI. Add an Atlassian API token in Settings → Accounts (legacy app passwords also work), or connect via native OAuth (PKCE loopback).
- Cursor Origin — Origin CLI,
origin auth login. GitLane uses that CLI session and never stores an Origin token. Native Windows is not supported — use macOS, Linux, or WSL.
Creating a pull request from a branch, including GitHub stacks, is a separate write-up: Create a pull request, including GitHub stacks.
Reviewing and stacks
Open a pull request for its body, file list, commits, and — on GitHub — CI checks that poll live. Diffs use the same renderer as the rest of the app.
On GitHub you can work with comments, review threads, and request changes in-app. On Cursor Origin you can reply to, resolve, and reopen existing threads; starting a new inline thread is not available yet. AI actions can Post to PR when the current branch has an open pull request.
When a GitHub pull request is part of a stack, its Info tab shows a stack card: every layer from the base branch up. Merge stack lands your pull request plus every unmerged layer below it in one atomic operation. If any layer can't merge, none of them do. Creating a stack and restacking after a rebase are not in GitLane yet — use gh or the GitHub web UI, then GitLane will show and merge the stack.
Azure DevOps, Gitea, and Forgejo/Codeberg work for commit, branch, push, and pull. Only the pull-request view is unavailable there.
Good to know
Provider tokens are stored in your OS keychain (or owned by
gh/glab/origin) and resolved in the backend immediately before the operation that needs them, then dropped. They are never handed to the frontend. Errors fromgitandghare redacted before they surface.
Full walkthrough: Pull requests.
Installers: Download GitLane.