Skip to main content
Stage and commit changes by file, hunk, or line.

​
Opening the Working copy panel

Uncommitted changes are handled in the Working copy panel. Click the Uncommitted changes row at the top of the graph, or the Working copy card at the top of the right sidebar, and the panel opens. The panel divides changed files into sections by status.
  • Conflicted appears at the top only when there are conflicts.
  • Unstaged marks untracked new files with a green + badge.
  • Staged holds changes that will be included in the next commit.
The Unstaged and Staged headers each carry a split button that covers both the files you selected and the whole section.
When you stage only part of a file, it appears in both sections at once.
A screen with the commit graph on the left and the Working copy panel open on the right. The Working copy has an UNSTAGED section with 8 files and a STAGED section with 2, each header carrying a Stage or Unstage button with a chevron beside it, and only the new file notes/reconciliation-draft.md inside UNSTAGED is marked with a green + badge

​
Flat view and tree view

Use the toggle button above the file list to switch between flat view (full paths on one line each) and tree view (grouped into folder hierarchy). Your view mode and collapsed folders are preserved the next time you open the panel.

​
Staging whole files

Click a file and a diff tab opens in the center. Select a file and click the Stage / Unstage button in the section header, and the change applies immediately; select multiple files to apply it to all of them at once.
The × button that appears when you hover over a file row is Discard. Clicking it throws the change away.

​
Section header actions

The Unstaged and Staged headers each carry one split button, and its two halves target different sets of files. The left half always does the same thing and never remembers what you last picked from the menu. The two halves cover different sets of files. A button that remembered your last choice would eventually stage a whole section when you meant to stage one file. It’s disabled when the selection holds nothing eligible, while the chevron stays clickable either way. The Conflicted header has no actions.
Stage All and Unstage All work on the whole section. Neither one needs a selection. In a sparse checkout, entries outside your checkout pattern keep their skip-worktree mark.
While a conflict is unresolved, the menu item is disabled and the panel says Resolve conflicts first. Staging the whole section would mark the conflicted file resolved and take it past the merge editor. Selection-based Stage / Unstage keeps working. You can still handle the files that aren’t in conflict.

​
Very large selections

A selection of several hundred files is passed to Git as several calls in sequence, each carrying a batch of paths that fits the command line’s length limit.
  • The calls run one at a time, never overlapping on the same index.
  • If one of them fails, the calls after it aren’t attempted. A notification reports how many files were completed, and the ones left over stay selected. You can retry with the same selection.
  • Turning Amend last commit back off restores files the same way. If that stops partway, Amend stays on, so turning it off again continues from where it stopped.
  • A single path too long to pass to Git at all stops the run before it starts, and the error names that path.
Files that were already handled are not rolled back. Several Git calls can’t be wrapped into one transaction, and undoing them would mean re-reading the working tree and overwriting changes you may have made in the meantime.

​
Staging hunks and lines

Click a file to open its Working copy diff.
1

Stage / Unstage a hunk

A contiguous block of changes is one section. Hover over any row in the section, and buttons appear to the right of the first row. In an unstaged diff these are Stage and Discard; in a staged diff it is Unstage.
2

Apply a single line

Hover over a changed line, and a Stage line / Unstage line button appears next to the line number. When -old and +new are paired as one edit, both lines are applied together.
An unstaged Working copy diff. In one hunk of a workflow YAML file, a single runs-on line is removed in red (−) and 4 lines (strategy, matrix, target, and runs-on) are added in green (+)
An already-staged Working copy diff, showing a small hunk with 2 constant declaration lines added in green (+) below an existing function in a Rust file
Line actions are only available in the Working copy diff of a modified text file. They don’t appear for new files, deleted or renamed files, conflicts, or binary and LFS files. Turning on Ignore whitespace changes hides hunk and line actions together. Handle those files at the file level. There is no line-level Discard.
In a repository with core.safecrlf=fail, a file with mixed line endings can’t be staged, and a CRLF would be replaced by LF in '<file>' error appears. This is standard Git behavior. git add rejects the same file in the same way. Save the file with LF line endings to normalize it, or relax the setting with git config core.safecrlf warn.

​
Committing

The commit form at the top of the Working copy panel, with the Summary (required) field, the Description field, the Amend last commit checkbox, and the green Commit button stacked in that order
Summary is required and Description is optional; the two are joined into one message with a blank line between them. Click Commit and the graph redraws with the new commit selected. The button is disabled when there is nothing staged or the summary is empty.
A commit includes only staged changes. If a Git hook such as pre-commit is configured, it runs at commit time, and the commit fails if the hook rejects it.