Issues and PRs

The Issues and PRs board is a full page that lists a project’s GitHub, GitLab, Gitea, Forgejo or Gerrit issues and pull requests (merge requests on GitLab, changes on Gerrit, which has no issues), or your Linear issues. Pick an item and its preview opens beside the list. Looking at another project here doesn’t change the project the rest of the app is on.

Open the board

Click the pull-request icon in the sidebar header, next to scheduled tasks and the archive.
Choose Issues and PRs in the command palette.
Press ⌘K then B (Ctrl+K then B on Windows and Linux). The same keys close it.

On a phone, tap the pull-request button in the footer of the sessions menu. The board isn’t available in the VS Code extension.

The board reopens on the project, tab and team you left it on.

Find items

Everything sits in one toolbar row. On the left is the project picker, with project icons and a search. Next to it you switch between Issues, Pull requests and Linear. Issues and pull requests come from the project’s own host: GitHub, GitLab, Gitea, Forgejo, Gerrit, or a host an extension adds. The Linear tab appears only once Linear is connected. A project on none of these hosts shows only that tab, or says there’s nothing to list. A remote on a host alias from ~/.ssh/config, such as github.com-work, counts as none of them.

A second picker next to the project picker chooses what the board lists, and appears once the folder holds more than one repository. In a folder that isn’t a Git repository itself but has repositories inside it, All repositories is first and is the default: the board lists the issues and pull requests of every GitHub repository in the folder together, and each row names its repository. Search works across all of them, including a pasted link or a number. A note above the list says how many repositories aren’t included, for example one on GitLab, Gitea, Forgejo or Gerrit or one no connected account can read, and its menu shows which and why. Pick a single repository to list only that one.

A folder that is a Git repository is listed itself and stays the default, with its submodules and nested checkouts beside it to pick instead. All repositories isn’t offered there, since the root’s own items would be listed beside themselves. The board remembers the choice for each project, and it’s separate from the repository the Git view has selected.

Comments, labels, reviewers and merging work on the repository an item belongs to. New session still starts in the project’s folder. Changes and Walkthrough open the pull request in its own repository and leave the repository the Git view has selected as it is. Starting work in a worktree isn’t offered for these items yet. A link to an issue or pull request of one of these repositories opens in the Tracker, read through that repository. On the phone it opens on the board, which reads it through its own repository too, leaving the list as it was. The VS Code extension has no board, so none of this changes anything there.

On Linear the project picker becomes a team picker: choose All teams or one team. For a project with only Linear, the project picker stays next to the team picker, so you can switch to another project. If you’ve connected more than one Linear workspace, switch workspaces from the same menu. Connecting Linear is covered in Integrations.

Search takes a title, a number, or a pasted link. The filter menu stays open while you pick, so you can combine filters.

For GitHub, GitLab, Gitea, Forgejo and Gerrit:

Status: Open, Closed, All, and Merged for pull requests
People: Anyone, Assigned to me, Created by me, and Review requested for pull requests

For Linear:

Status: Open, All, Backlog, To Do, In Progress, In Review, Done, Canceled, Duplicate
People: Anyone, Assigned to me, Created by me
Priority: All priorities, Urgent, High, Medium, Low, No priority

Read an item

The preview shows the description, labels and comments. On a Linear issue, click the status pill to move it to another of the team’s states.

The Labels row has a pencil button that opens a searchable list of the repository’s labels. Check or uncheck them. The change is saved when you close the list, so several clicks count as one change. An open pull request (merge request on GitLab) also has a Reviewers row that works the same way, with the people who can review in the repository. On GitHub, the pull request’s author isn’t offered. Linear issues have neither row.

Comment and review

Below an issue’s or pull request’s activity is a comment box. Comment posts your text to the repository’s host, and so does ⌘+Enter (Ctrl+Enter on Windows and Linux). The text stays in the box until it’s posted, so a failed post loses nothing. Switching to another item clears the box. Linear issues don’t have one.

An open pull request (merge request on GitLab) also has Approve and Request changes, and the text in the box goes with the review. Request changes needs text saying what to change. The review is for the commits the preview shows: if someone pushed since, it’s refused and the preview refreshes so you can look again. On GitLab, Request changes works when you’re a reviewer of the merge request, and the review text is posted as a separate comment. If only that comment fails, the review still counts and your text stays in the box.

A Gerrit change has a row for each of the project’s labels, such as Code-Review and Verified, with the scores you’re allowed to give; pick them and choose Vote. Your text goes with the votes as a message. Votes go on the latest patchset, so they aren’t offered while you’re reading an earlier one.

Start work

The actions sit at the bottom of the preview.

New session opens a new session in the project with the item attached to the message box. You write the first message yourself.
Start in worktree… on an issue, or Check out in worktree… on a pull request, opens the New Worktree dialog with the item already chosen. A pull request checks out its own branch. See Worktree Sessions.

For a Linear issue, Start in shows the project the session will start in. That’s the project mapped to the issue’s team in the Linear card in Integrations. Without a team mapping it’s the default project, and without that, the project the board showed last. You can pick another project there for this issue.

Pull requests

A pull request’s preview also shows its branch, its size (lines added and removed, and files changed), its checks and its review. The Activity feed puts comments, review verdicts and the newest commits in the order they happened. Commits that came in a row are grouped, so you can see which commits a review answered.

Two buttons sit beside the size. Changes opens the pull request’s diff in the side panel, and Walkthrough opens its walkthrough. If the app is on another project, it switches to the PR’s project first. On a phone, Changes opens the PR in the Git tab of the workspace drawer; Walkthrough is desktop and web only.

At the bottom, Merge asks before merging and uses your usual merge method. A draft also gets Ready for review.

On Gerrit the preview also shows the change’s topic, and whether it’s private or work in progress. When a change has more than one patchset, a picker next to Changes chooses which one the files and diff come from; it starts on the latest. Merge is Submit, and it stays off until the change’s submit requirements are met, with the unmet ones named beside it. Close and Reopen are Abandon change and Restore change.

An open issue or pull request also has Close issue or Close pull request (Close merge request on GitLab); a closed one has Reopen issue or Reopen pull request (Reopen merge request). Neither asks first, since it can be undone. A merged pull request can’t be closed or reopened. On GitHub, an issue closes as completed.

Git hosts: connect GitHub, GitLab, Gitea, Forgejo or Gerrit and attach items to messages
Worktree Sessions: where worktree sessions start
Integrations: connect Linear and map teams to projects