Remove a file or its changes from the latest Git commit

Distinguish removing a newly added file from restoring an older tracked version, then amend only an unpublished commit or make a corrective commit.

Best practices
Illustration of Git branches and version history

First decide what “remove the file from the commit” means. You may want to stop tracking a newly added file entirely, or keep a tracked file at its previous version while excluding only the latest edits. The index must contain the intended result before you amend.

Stop tracking a newly added file

For an unpublished tip that accidentally introduced .env:

git rm --cached -- .env
printf '\n.env\n' >> .gitignore
git add .gitignore
git diff --cached
git commit --amend --no-edit

Your working copy of .env remains. The amended snapshot does not contain it, and the ignore rule helps prevent accidental addition. If the file existed in the parent commit, however, removing it from the index records a deletion; it does not merely exclude this commit's edits.

Exclude edits to an existing tracked file

Restore the parent's version in the index while retaining your current working copy:

git restore --source=HEAD^ --staged -- path/to/file
git diff --cached
git commit --amend --no-edit

Now the amended commit has the parent's version of that path. The excluded edits remain as unstaged changes. This requires a parent commit; HEAD^ does not exist for a root commit. Review all staged content because ordinary amend includes the entire index. If excluding the change would make the amended commit empty relative to its parent, Git normally refuses the amend. Keep an empty commit only deliberately with --allow-empty, or review whether the unpublished commit should be removed entirely while preserving the work you need.

git restore --staged path/to/file alone defaults to HEAD, so it does not remove a change already committed in HEAD.

Rebuild the commit instead

For a clean working tree and an unpublished ordinary tip:

git reset --soft HEAD^
git restore --staged -- .env
git diff --cached
git commit -m "Recreate the change without the local environment file"

After the reset, HEAD is the parent, so restoring the index from it excludes the file's latest change. A mixed reset (git reset HEAD^) instead puts the changes in the working tree. Use that approach with git add -p to select individual hunks. A soft reset leaves everything staged, so git add -p alone would not deselect unwanted hunks.

Handle a published commit

On shared history, make a new corrective commit rather than amending and forcing a push. For example, git rm --cached -- .env followed by a reviewed commit stops tracking it going forward. That does not remove older copies from history.

For an agreed rewrite of a personal published branch, coordinate with collaborators and use a lease when pushing. Others may need to reconcile their work; do not tell them to discard it with an unconditional reset.

If the file contained a secret

Revoke or rotate the exposed credential promptly. Removing a path from the latest snapshot does not invalidate the secret or erase copies in older commits, clones, caches, and artifacts. A coordinated history-cleanup procedure may also be needed; it has a broader scope than amending one commit.

See git-restore, git-rm, git-commit, and git-reset.

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