Commit only part of a file in Git

Use git add --patch to stage selected changes, inspect the complete staged snapshot, and commit it without accidentally including the rest of the file.

Best practices
Illustration of a Git commit history and an earlier revision

Use git add -p <file> to choose which changes enter the staging area. Then review the staged diff before committing: a normal git commit includes everything already staged, including changes in other files.

Select the changes to stage

Start by checking your current state:

git status
git diff --staged
git add -p src/app.js

Git presents changes in groups called hunks. The main choices are:

Key Action
y Stage the displayed hunk.
n Leave it unstaged.
s Split it into smaller hunks when the changes permit it.
e Edit the patch manually.
q Stop; keep previous selections and leave remaining hunks unstaged.
? Show the available options.

Splitting is easiest when unchanged lines separate the edits. Adjacent changes may require manual patch editing.

Review the staged snapshot before committing

git diff --staged
git diff
git commit -m "Fix request validation"

The first diff shows what the next normal commit will record; the second shows edits left in the working tree. Run tests against the intended committed state when the remaining edits could affect the result.

Do not use git commit -a for this workflow: it stages tracked-file modifications and deletions, potentially including work you deliberately left out. Passing a file path to git commit also changes its selection behavior and can take that file’s working-tree contents instead of your carefully staged subset.

If unrelated changes were already staged, review them first. In a repository with an existing commit, git restore --staged <file> unstages a file while retaining its working-tree changes; use it only for files you intend to remove from the staged snapshot.

Stage part of a new file

Register the new path with intent-to-add, then select its contents:

git add -N src/new-module.js
git add -p src/new-module.js
git diff --staged

Intent-to-add makes the new file available for patch selection without staging all its contents immediately.

Edit a hunk carefully

In the patch editor, delete an added line beginning with + to leave that addition unstaged. To leave a deletion unstaged, change its leading - to a space so the line becomes context. Keep the other context lines intact.

For a replacement, consider both the removed and added lines. An edited patch can describe an invalid intermediate program even if Git accepts it. If the patch cannot be applied, Git offers a retry; reread the staged diff afterward in either case.

Use an editor if you prefer

Editors can make partial staging easier to see. VS Code provides Stage Selected Ranges in its diff view. JetBrains IDEs also support selecting changes for partial commits, with details depending on the IDE and commit mode. Inspect the resulting staged or selected changes rather than relying only on the working-file view.

What if I missed a line after committing?

For an unshared latest commit, stage the missing change, check the full staged diff, and amend:

git add -p src/app.js
git diff --staged
git commit --amend --no-edit

Amending replaces the commit and changes its identity. If it has already been shared, a follow-up commit is usually easier for collaborators; rewrite shared history only through an agreed workflow. Partial commits otherwise behave like ordinary commits when pushed or reviewed in a pull request.

References

Get a tailored plan

Contact us

Join the community

Scan with WeChat
to join the community

Try Guance

Start online and pay only for what you use.

Get started

Choose a Guance plan

Code hosting