Git add -p: stage specific lines and make focused commits

To commit only part of a file, stage the changes you want with `git add -p -- path/to/file`, review them with `git diff --cached`, then commit. The remaining edits stay in your working files. In GitTree, open the file diff, select the changed lines and choose Stage Lines to prepare the same kind of focused commit.

Suppose you fixed a checkout validation bug, then started reorganizing the same component. A reviewer should be able to understand the bug fix without reading an unfinished refactor. This guide separates those changes before they become history. The animated example uses GitTree, the client we make for macOS, Windows and Linux. Partial staging belongs to the Free plan; current official builds require sign-in.

Working tree, staging area and commit: what gets saved?

Staging is a selection step, not a commit and not a push. A file can be partly staged: the index holds one version while your editor shows all edits. If you edit again after staging, the staged version does not silently update. Review it again before committing. The visual commit graph helps inspect the history once the commit exists.

How to use git add -p on one file

Begin with git status and inspect anything already staged. Patch mode adds selected changes to the existing index; it does not remove earlier selections. In this example, replace src/checkout.ts with your tracked text file, then accept only the validation fix when Git asks about each block.

git status
git diff --cached
git diff -- src/checkout.ts
git add -p -- src/checkout.ts
git diff --cached
git diff -- src/checkout.ts
git commit -m "fix: validate checkout input"

Run the final commit only after reviewing the staged diff and testing the intended change. git diff --cached shows what the commit will record; plain git diff shows what will remain uncommitted. Do not use git commit -a or give file paths to git commit for this workflow: those forms can bypass the partial selection you just prepared.

Split a hunk when the fix and refactor are close together

A hunk is a block of nearby changed lines with context. Patch mode may group the fix and the refactor together. Use s to ask Git to split the block. If the edits cannot be separated automatically, e opens a patch editor, or a visual line selector can help you choose the intended additions and removals.

For a replacement, consider both the removed line and its replacement as one logical change. Selecting only half can produce code you never saw in your editor. Advanced patch editing is optional; if you cannot explain the staged result, unstage it and choose a clearer boundary. Focused commits need to work on their own, not simply be small.

Download GitTree to review a mixed diff and build focused commits visually. You can use it on an existing repository alongside the terminal; both read the same Git staging area.

Unstage changes without discarding your edits

git restore --staged -- src/checkout.ts
# Or choose which staged blocks to remove:
git restore --staged -p -- src/checkout.ts

These are alternative commands. With --staged, restore changes the index rather than your working file. For a repository with commits, it normally resets the staged content toward HEAD. Without --staged, restore can overwrite working edits, so keep the distinction clear. In GitTree choose Unstage, not Discard, when you only want to change what the next commit includes.

Why a file appears twice, or a line cannot be staged

A file under both Staged Files and Unstaged Files usually means partial staging or a later edit, not a duplicate file. A new, untracked text file may need git add -N -- path/to/new-file before patch mode can offer its contents. Binary files have no ordinary text hunks; GitTree also stages renames, LFS pointers and submodule changes as whole-file operations. If whitespace is hidden, show it before selecting whitespace-only changes.

If an editor or formatter changes the file after you open its diff, GitTree may refuse a stale line selection. Refresh the diff and pick again. Avoid splitting tightly coupled changes just to reach a smaller line count. For a task interruption, stash the unfinished work; for already committed mixed history, review the interactive rebase guide.

Test the commit you are preparing, not just the editor’s files

Your normal test command runs against working files, which still include unstaged edits. Passing tests there do not prove the partial commit is complete. For an important split, make the first local commit, then inspect and test that committed snapshot in a separate clean checkout or worktree. Add the missing dependency if it fails before sharing the branch. The worktree guide explains how separate folders help keep those versions apart.