Git & shipping

When your AI tool finishes a change, the next step is almost always git: look at what changed, stage the parts you want, write a commit message, push, and open a pull request. Operon puts that whole flow inside the app so you never have to drop back to a terminal to ship the agent’s work. It lives on the Changes tab of a session.

The Changes tab reads your session’s repository (or its isolated worktree, if the session runs in one) and shows a live git status: what is staged, what is changed but unstaged, what is untracked, and anything in conflict. As the agent edits files, the view refreshes on its own, so it always reflects the current state of the working tree.

The Changes tab at a glance

The header shows the current branch, staged and unstaged counts, and a set of status chips: a +additions / −deletions diff-stat for the working tree, an ahead / behind indicator against the remote, and — once you open one — a PR or MR status chip. Below it, files are grouped into sections so you always know exactly where each change stands.

• Conflicted — files git could not merge cleanly. Shown first, in red, because they block progress until resolved.
• Staged — changes that will go into your next commit. Unstage the whole group or any single file.
• Changes — modified, deleted, and untracked files that are not yet staged. Stage the whole group or individual files.

Each file row carries a single-letter status chip — M (modified), A (added), D (deleted), R (renamed), C (copied), or U (untracked) — so you can read the shape of the change at a glance.

Review, commit, and push

This is the everyday arc: look at what the agent did, stage the parts you approve of, commit, and push — without leaving Operon.

1. 1

   Click a file to see its diff

   Click any file name to open its diff. Unstaged rows show the HEAD-to-working-tree diff; staged rows show the HEAD-to-index diff. The diff opens in a full viewer you can read side by side or unified.

2. 2

   Stage what you want

   Use "Stage" on an individual file, or "Stage all" on the Changes section to stage everything at once. You can unstage the same way. Staging is reversible at any point before you commit.

3. 3

   Write a commit message and commit

   Enter a message in the commit box and press Commit. Commit only becomes available once you have at least one staged file and a non-empty message. Check "Amend" to fold your staged changes into the previous commit instead of creating a new one.

4. 4

   Push

   Press Push to send your commits to the remote. The button shows how many commits you are ahead. If the branch has no upstream yet, Operon sets one automatically on the first push.

5. 5

   Open a pull request

   Press Create PR to open the draft-PR modal, review the generated title and body, pick the account, and open a GitHub pull request or GitLab merge request. See "Create a pull request" below.

Stage by hunk

Sometimes a single file mixes changes you want with changes you do not. For any modified file — staged or unstaged — the "Hunks" action opens that file’s diff split into individual hunks. Each hunk has its own Stage or Unstage action, so you can commit exactly the sections you approve of and leave the rest for a separate commit. This is the gutter-level control you would normally get from an interactive stage on the command line.

Changes-tab actions

Every git operation Operon exposes in the Changes tab, and what it does. Each one runs against the session’s own repository or worktree and returns fresh status so the view stays in sync.

Sync with base

While the agent works on a feature branch, the base branch may move on. The "Sync with" control brings the base into your current branch so you stay current. Enter the base ref (it defaults to the session’s base, or origin/main) and choose a strategy with the merge / rebase toggle, then press Sync.

If the sync runs into a merge conflict, the conflicting files appear in the Conflicted section at the top of the view, and an "Abort sync" action lets you back out and return to the pre-sync state. Resolve the conflicts (or abort), then continue.

Create a pull request

Create PR opens a modal that generates a draft PR from your session: a title, a body summarizing what changed, and the base and head branches. Operon reads the session’s origin remote to decide where the PR goes — a GitHub repository opens a pull request, a GitLab repository opens a merge request (GitLab’s equivalent). Both are supported, including self-managed GitLab hosts.

• Review the generated title and body before opening — they come from the session’s traces and are meant as a starting point.
• Pick the integration account to open the PR/MR with. You connect GitHub and GitLab accounts under Settings → Integrations.
• The PR is opened as a draft by default, so it will not request review until you mark it ready.
• Once opened, a PR (or Draft PR) status chip appears in the Changes header and on the web sessions list; clicking it opens the PR/MR in your browser.

Finish a worktree session

When a session runs in its own git worktree (an isolated checkout on a feature branch, kept separate from your main checkout), the Changes tab shows a "Finish" control: Merge to base. It fast-forwards your base branch to the work on this session’s branch, landing the change in the base checkout where the base branch lives.

Merge to base is a deliberate, guarded finish exit — it does not automatically end the session, and it only appears for worktree sessions. In-repo sessions ship through commit and push as usual. Worktree isolation itself is chosen when you create a session; see the workflows guide for when it is worth it.

Discard changes

If a change went wrong and you want to start over, "Discard all changes" resets the working tree to the last commit and removes untracked files. Because it is destructive and cannot be undone, it is confirm-gated — you have to confirm before it runs. To roll back more surgically, stage and commit only what you want, or discard individual files instead.

Related