How to Revert a File to a Previous Commit in Git

To restore one tracked file from an earlier commit, find the commit that has the version you need, then run git restore --source <commit> -- <file-path>. This updates the file in your working tree without changing commit history and, by default, leaves the restored version unstaged. Review or save valuable local edits first: restoring replaces the file contents in your working tree. If you want the restored version recorded in a new commit, stage and commit it afterward.

Find the commit that contains the version you want

Use git log --oneline -- <file-path> to see commits that changed the file and identify the commit whose version you want. For example, for a repository-root README.md, run git log --oneline -- README.md. The -- marks the end of command options; it is useful when a path could otherwise be interpreted as an option. For git log, a path may be relative to your current directory; you can also use a repository-root-relative path with Git’s :(top) path syntax, such as :(top)README.md.

Read the commit summary and, when needed, inspect the file at a candidate commit with git show <commit>:<file-path>. In this form, the path after the colon is always relative to the repository root, regardless of your current directory. For example, if you ran git log --oneline -- README.md from a docs subdirectory to find changes to docs/README.md, inspect that version with git show <commit>:docs/README.md; for a repository-root README.md, use git show <commit>:README.md from either the root or a subdirectory. Use the commit identifier shown by the log, abbreviated or full, in the restore command. A commit can contain the desired version even if later commits changed the same file; choose based on the file contents you intend to bring back, not simply the newest entry.

Restore a file from a previous commit

First inspect or save any valuable edits to the target file. Then restore the chosen version with git restore --source <commit> -- <file-path>. For the supplied example, the command is git restore --source 9cbe84d -- README.md. Replace the commit and path with the values from your repository. This command copies the file version recorded in that commit into your working tree. It does not create a commit or move the current branch, and the restored contents are not staged by default.

These command snippets show Git operations and are not accompanied by claimed runtime output; their effect depends on your repository history and current index and working-tree state. After the restore, use git diff -- <file-path> to review the working-tree change. If you also have staged changes for that path, inspect the staged version with git diff --cached -- <file-path> so you know what will be included in the next commit.

Choose between git restore and git checkout

For a file from a chosen commit, git restore --source <commit> -- <file-path> makes the source commit explicit and updates the working tree without staging the result by default. The path-form alternative is git checkout <commit> -- <file-path>. That form updates both the working-tree file and the index, so the restored version is staged immediately. This distinction matters when you are preparing a commit: inspect the staged change after git checkout, and stage the file yourself after git restore only if that is what you intend.

Both forms replace the target file’s current working-tree contents. Save or inspect local edits before running either command, especially if those edits are not committed elsewhere. A file restore does not create a commit; it changes the state from which you can continue working. The branch history remains as it was until you make a later commit.

Stage and commit the restored file

After git restore, review the change and stage it with git add -- <file-path> if you want it included in a commit. Then check git diff --cached -- <file-path> to confirm the staged version and create a commit with a message that describes why the file was restored. If you do not want to record the restore yet, leave it as a working-tree change.

After path-form git checkout <commit> -- <file-path>, the restored version is already in the index. Review it with git diff --cached -- <file-path> before committing. You can edit the file further, stage those edits, or unstage the path while keeping the working-tree contents, depending on your next step. Restoring one file is independent of whether you choose to commit it; it does not automatically publish or share the change.

Understand git revert and git reset for files

git revert and restoring a file solve different problems. git revert <commit> creates a new commit that reverses the changes introduced by an earlier commit; it is used to undo a commit while preserving the existing history. It is not the command for copying one file from an earlier commit. To bring back one file version, use the source-commit restore workflow above, then decide whether to commit that result.

Path-form git reset HEAD -- <file-path> unstages that path: it changes the index to match HEAD while leaving the working-tree file contents in place. It does not restore the file contents from a chosen commit. To discard working-tree edits and return a file to the current HEAD version, git restore -- <file-path> restores from HEAD by default; this also replaces the working-tree contents, so review or save edits first. The older path form git checkout -- <file-path> has a similar discard effect, but does not select an earlier commit. Use the explicit --source <commit> form when the target version comes from a particular commit.

For more detail, consult the Git restore documentation, the Git checkout documentation, and Pro Git’s chapter on undoing things.