Introduction

To commit only some files in Git, stage only the files or hunks you want in the next commit, then run git commit. Git is built around the staging area, so selective commits are a normal workflow rather than a special case.

Stage Only the Files You Want

The simplest case is when whole files belong in the commit.

git status
git add src/app.py docs/README.md
git commit -m "Update app logic and README"

Only the staged files go into that commit. Other modified files stay in your working tree, uncommitted.

This is the main reason the staging area exists: you can organize a commit before creating it.

Review What Is Staged

Before committing, check what is actually in the index.

git diff --cached

That shows the staged changes only. It is one of the safest habits in Git, especially when you are trying to keep commits focused or when several unrelated edits happened in the same work session.

Unstage a File If You Added Too Much

If you staged the wrong file by mistake, unstage it before committing.

git restore --staged src/experiment.py

Older documentation may show:

git reset HEAD src/experiment.py

That still works, but git restore --staged is clearer because it describes the intent directly.

Commit Only Part of a File with Patch Mode

Often the real problem is not "some files" but "some changes within one file." Use patch mode for that.

git add -p

Git will show each hunk and ask whether to stage it. That lets you split unrelated edits in the same file into separate commits without manually copying code around.

This is one of the most valuable Git skills for keeping history clean.

A Practical Selective-Commit Workflow

A safe everyday sequence is:

1git status
2git add -p
3git diff --cached
4git commit -m "Fix validation logic"

That works whether the changes are grouped by file or mixed together inside the same file.

Use Separate Commits for Separate Ideas

Selective commits are not just about mechanics. They help preserve history quality.

Good examples of separate commit themes:

• one bug fix
• one refactor
• one documentation update
• one test addition

If you mix all of those into one commit because they happened in the same afternoon, the history becomes harder to review, bisect, and revert.

What Happens to Unstaged Changes?

Unstaged changes remain in the working directory after the commit.

Example:

git add src/main.py
git commit -m "Update main flow"
git status

If src/helper.py was modified but never staged, it still appears as modified afterward. Git does not discard or auto-commit it.

That is exactly what makes selective commits safe.

Use Stash Only If the Working Tree Is Too Messy

If unrelated changes are making staging confusing, you can temporarily stash them:

1git stash push -m "unfinished work"
2git add src/main.py
3git commit -m "Focused commit"
4git stash pop

This is not always necessary, but it is useful when patch mode still leaves too much noise.

Common Pitfalls

The most common mistake is thinking git commit automatically includes every modified file. It includes only staged changes. Another is staging too broadly with git add . and then committing without reviewing the index. Developers also underuse git add -p, even though it is the easiest way to create clean commits when unrelated edits live in the same file.

Summary

• Stage only the files or hunks you want in the next commit.
• Use git add file1 file2 for whole-file selection.
• Use git add -p when you need to commit only part of a file.
• Review staged changes with git diff --cached before committing.
• Leave unrelated edits unstaged so commits stay focused and easy to understand.