Skip to content
Download

DOCS / GIT

Commit changes

Birch’s Changes tab shows one row per file with a tri-state checkbox — no separate staged/unstaged lists. This page covers staging (including partially staged files and why they show a combined diff), writing or ✨-generating the commit message, amending, and the commit-area controls that live beside them.

The Changes tab is the first tab of the Git view. You reach it from a workspace’s Git tab, or from a repository page’s Open Git button.

Every changed file is a single row with a tri-state checkbox:

Checkbox stateMeaning
CheckedThe file’s changes are fully staged
UncheckedNothing is staged for this file
IndeterminatePartially staged — some changes are in the index, some are only on disk

Clicking a row’s checkbox toggles the whole file between staged and unstaged. The master checkbox above the list (tooltip: Stage or unstage all files) does the same for every visible row, and the Filter changed files box narrows the list first — so you can filter, then stage the remainder in one click.

The list supports multi-select: ⌘A / Ctrl+A selects all rows, and Space toggles staging on every selected row. See Keyboard shortcuts for the full table.

Rows carry two extra markers when relevant: an LFS badge for files tracked by Git LFS, and a glyph for files with a merge conflict.

A row that is both staged and modified on disk shows its total change in the diff pane — git diff HEAD, not just the index — with a staged + unstaged note explaining that the pane is showing everything since HEAD. A cached-only diff would hide edits made after you staged, which is exactly the situation the tri-state row represents. See Reading diffs for details.

The commit area sits below the file list:

  • Summary (required) — the commit subject, a single line.
  • Description — the optional body.
  • Commit to <branch> — the commit button names the branch it will commit to. It enables once the Summary is non-empty and at least one file is staged (or Amend last commit is checked).

A toast confirms each commit.

The button inside the Summary field (tooltip: Generate commit message with AI) writes a message from your staged diff: the generated first line lands in Summary, the rest in Description. It is enabled only when at least one file is staged.

Check Amend last commit to replace the branch tip instead of adding a new commit. Checking it prefills the Summary/Description with the last commit’s message, so you can amend purely to reword — no staged changes required. As the checkbox’s tooltip says:

Replace the last commit (prefills its message). Don’t amend commits you’ve already pushed.

Amending a pushed commit rewrites history and will leave your branch diverged from its upstream — see force push with lease for what Birch offers in that state.

Right-click a changed-file row for:

  • Discard — throws away the selected file’s (or files’) changes after a confirmation that lists the affected paths. Discarding is permanent; for untracked files it deletes the file outright.
  • Show file history… — opens the file’s commit history window.
  • View blame… — opens the blame window for the file.
  • Add to .gitignore — a submenu offering to ignore the exact file, its extension, or its folder.

Blame and file history are documented with the other power tools; they remain reachable from this menu.

When the repository has submodules, a Submodules expander appears below the file list. It lists each submodule with its state and pinned commit, plus three actions:

ButtonRuns
Initgit submodule init
Updategit submodule update, honoring the init (--init) and recursive (--recursive) checkboxes
Syncgit submodule sync

The row under the commit button holds two remote-facing controls: the Pull strategy dropdown (remembered per repository) and the Force push (with lease) button, which appears only when your branch has diverged from its upstream. Both are covered in Sync, push & pull.

Every agent workspace is its own worktree on its own branch, so commits you make from its Git tab land on the workspace branch and never touch your main checkout. Two habits help:

  • Agents often commit as they work. Use the workspace’s Review tab to see everything the branch changed vs its base — committed or not — before you add commits of your own.
  • If you open the Create PR dialog while the worktree still has uncommitted changes, Birch commits them automatically using the PR title as the commit message. Stage and commit deliberately first if you want a different message — see Create a pull request.