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.
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.
Contact us
Join the community
to join the community
Try Guance
Start online and pay only for what you use.
Get startedChoose a Guance plan