Pull requests and merging

The Checks tab in a task’s inspector is where work gets published. One button carries the task from branch to merge, changing as the pull request moves along. Pull requests need a repository connected through the GitHub App.

The one button

The button sits at the top right of the inspector, or in the task header while the inspector is hidden. Review sits beside it, to have an agent look the work over before you ship it. See Review. The button shows the next step:

While an action runs, the button shows its current step, such as Preparing…, Writing description…, Committing…, Pushing…, or Creating PR….

Its menu also has Create draft PR, Commit and push, Open on GitHub, Merge PR (Merge anyway… while something blocks the merge), and Mark ready for review or Convert to draft. Once the pull request is merged or closed, the menu has Open on GitHub and Archive workspace.

Create PR and the preparation before every commit and push run as background jobs on the Rivets server. A dropped connection or a slow step does not fail them: the app keeps following the same job until it finishes.

Title, description, and commit message

The pull request title and description sit at the top of Checks. The description shows as rendered Markdown. Click it to edit, with a formatting toolbar. Drag the handle under it to resize it, and Rivets keeps that height for the next description you open.

Leave the title and description empty and Create PR writes them. Before a pull request exists, you can also choose Write with AI on web, or Generate on Mac and iOS, to draft them first. When there are uncommitted changes, a commit message is written too.

Generation runs on the worker with your own agent, on a small, inexpensive model. If the repository has a pull request template on the base branch, such as .github/pull_request_template.md, the description keeps its structure. The prompts are customizable under Settings › Prompts as Pull requests and Commit messages. See Custom prompts.

Rivets autosaves a draft of the title and description. Autosaving does not edit GitHub. For an open pull request, choose Save changes to update it on GitHub. If someone else edits the text in another client or on GitHub, or the last update to GitHub was not confirmed, Rivets says so under the fields.

Git status

Below the draft, Git status lists one line per fact, each with its action:

Push only pushes committed work and never adds uncommitted edits. Pull fetches the selected base, or the task’s branch on GitHub, and merges it locally. Commit or discard your changes before pulling. These actions never force-push, rebase, silently stash, or discard work.

Conflicts

When the branch conflicts with its base, choose Resolve. Rivets commits local work, merges the base locally, and asks the agent to resolve the conflicts. A file that still contains conflict markers counts as unresolved, even when staged. The agent gets one retry. If conflicts remain, Rivets stops and tells you.

While a Rivets merge is in progress, Git status shows the conflicted files. Open one to see its diff, or choose Resolve (Resolve with agent on Mac and iOS) to send the resolution to the agent. When the files are resolved, choose:

• Continue to verify the index and branch, finish the merge, then commit and push any remaining work.
• Abort to undo the merge Rivets started. It refuses to discard edits made afterwards.

Stop a running agent before changing git state.

Checks

The Checks view lists, for the current head:

• Check runs, each linking to its source on GitHub.
• The review decision.
• Unresolved review threads. Choose Fix on a thread to send it to the agent.
• A merge line: Ready to merge with Merge, Draft PR with Mark ready, or the reason merging is blocked.
• Deployments, when Rivets can read them.

Missing permissions or evidence never count as passing. Checks Rivets cannot read show as Checks unavailable and block the merge. Rivets cannot read branch protection rules, so every check counts as required.

Merge anyway

When checks fail, stall, or never report, the blocked merge line offers Merge anyway. After you confirm, Rivets merges the reviewed head regardless of the readiness gate. It still requires write access, an open pull request, and no other git action running. GitHub’s branch protection still has the final say.

In the sidebar

Each task row in the sidebar starts with an icon for its state, so you can see what needs you without opening the task:

• Working: an agent is running or queued, or the workspace is being set up.
• Merge conflicts: a Rivets merge stopped on conflicts, or GitHub reports that the open pull request conflicts with its base.
• Ready to merge: the pull request is open and GitHub reports it ready to merge.
• Idle: anything else.

Hover the icon to see the state in words.

Merge method

Owners set the default merge method under Settings › Git workflow › Merge method:

• Squash and merge
• Create a merge commit
• Rebase and merge

To override it for one repository, use Repository override in the same section, or open the repository’s settings from its project row in the sidebar: choose the gear that appears on hover, or right-click the row and choose Settings…. On iPhone, use the project’s … menu.

Auto-archive

Under Settings › Git workflow, Archive a workspace when its pull request is merged archives the task after a merge, including merges completed on GitHub. It is on by default, and only owners can change it. Rivets learns about merges through GitHub webhooks.

If an agent is still running in the task, Rivets waits until it finishes. A task waiting for approval is never archived automatically. With the setting off, choose Archive on the merged pull request’s line in Git status.

Archiving stops the task’s scripts, terminals, and previews and runs its archive script. See Archive and restore.

Reading the changes

• Changes lists every changed file with line counts. Open a file to see its diff in Unified or Split layout. Web, Mac, iPhone, and iPad draw diffs with the same viewer, so syntax colors and layout match, and large diffs scroll smoothly.
• Files shows the worktree as it is on disk, including ignored files and build output. Folders load as you open them. Text files open in an editor, so you can make a small change and save it in place.

If an action fails

A failed action says what went wrong, with Retry. Retrying resumes the same operation: steps that already finished, such as a commit, are kept and not repeated. It does not pick up edits made since. If the app never heard back about an action, it shows The last Git action didn’t confirm with Retry, which checks on the original action rather than starting a new one. A merge whose answer is lost is retried automatically after about 20 seconds without risking a second merge, and Rivets checks the pull request, so a merge that went through shows as merged.

Limits

• Rivets publishes to a branch with the same name on origin in the same repository.
• Pull requests from forks, alternate push remotes, and mismatched origins are not supported. Rivets rejects them with an explanation.
• Repositories added as credential-free or file:// remotes can commit but cannot open pull requests.
• Rivets credentials cannot push changes to .github/workflows. A push that touches workflows fails. Remove the change, or push the branch yourself with your own GitHub credentials.