Restore a file to a specific Git revision

Use git restore --source=COMMIT -- path/to/file to copy a historical version into the working tree. Add --staged --worktree to update both the index and working tree. These operations leave the branch tip in place; commit the result when you want the restoration recorded in history.

Inspect before replacing content

git log --oneline -- src/config.js
git show abc1234:src/config.js
git diff HEAD abc1234 -- src/config.js

Replace the example commit ID with a real revision. Save any uncommitted work at the selected path before restoring it, because the replacement can overwrite that content.

# Working tree only:
git restore --source=abc1234 -- src/config.js
# Alternative: index and working tree together:
git restore --source=abc1234 --staged --worktree -- src/config.js

git restore requires Git 2.23 or later. Review the first form with git diff; review the staged form with git diff --cached. If the chosen version matches the existing contents, there may be no change to commit.

Older checkout syntax and other revisions

git checkout abc1234 -- src/config.js
git checkout 'abc1234^' -- src/config.js
git checkout v1.2.0 -- src/config.js

The checkout form updates both destinations for a file present in the source. ^ means the first parent, which must exist; a merge may require a different parent for your intended comparison.

Checkout uses overlay behavior by default, so it does not exactly match restore when paths are absent from the source tree. Restore can remove tracked paths missing from that tree. This matters especially for directories: git restore --source=abc1234 --staged --worktree -- src/ can remove newer tracked files under src/ to match the older snapshot, while ordinary path checkout can leave them behind.

Restore versus revert

A path restoration replaces selected content and waits for you to commit. git revert COMMIT applies the inverse of a commit's changes, normally creating a new commit; conflicts may require resolution. It is not a single-file snapshot copy. Choose based on whether you want an earlier file state or the reversal of a specific change.

Undo or follow renamed files

Before committing a restoration, you can restore the selected path from HEAD into both destinations:

git restore --source=HEAD --staged --worktree -- src/config.js

This also discards other local changes at that path. After committing, HEAD already contains the restored version. Revert the restoration commit if it contains only that intended change, or copy the file from an explicitly chosen earlier revision and commit again.

For renamed files, use git log --follow -- current/path.js to investigate history. A historical restore addresses the path that existed in that snapshot; it does not automatically map the old name to the current one. Inspect the old content with git show COMMIT:old/path.js, then deliberately apply it to the desired current path.

See git-restore, git-checkout, and git-revert.