Revert a Single File in Git: Restoring One Path Without Touching the Rest

Q: How do I revert a single file in Git?

Use git restore --source= -- path/to/file, or the older git checkout -- path/to/file. Both update the working tree and index so the change is staged and ready to commit.

Q: How do I restore a file that was deleted in an old commit?

Find the deleting commit with git log --diff-filter=D --oneline -- path, then restore from its parent: git restore --source= ^ -- path. The file existed in the parent, not in the commit that removed it.

To restore a single file to how it looked at an earlier commit: git restore --source=<commit> -- path/to/file. The older equivalent is git checkout <commit> -- path/to/file. Note that neither is git revert, which operates on whole commits and has no way to target one path — that mismatch is why this is confusing.

Git has three different commands whose names suggest undoing, and they operate at different granularities. Getting the single-file case right means knowing which one takes a path argument and what each does to your working tree.

The commands, and which takes a path
Finding the right commit first
Reverting one file’s changes from a specific commit
Recovering a deleted file
Doing it in the GitLab or GitHub interface
Restoring is not deploying
How this fits the rest of the stack
FAQ

The commands, and which takes a path

git restore — operates on files. Takes paths. This is the one you want.
git checkout — the older, overloaded command. Takes paths in this form, and also switches branches, which is why it was split.
git revert — operates on commits. Creates a new commit inverting an old one. Takes no path argument.
git reset — operates on the branch pointer and index. Takes paths, but for unstaging rather than for restoring content.

The git revert limitation is the source of most confusion here. You cannot revert one file out of a commit directly — you restore the file to its previous state and commit that, which achieves the same outcome by a different route.

# Restore a file to how it was in a specific commit
git restore --source=a1b2c3d -- src/config.js

# Restore to how it was one commit before HEAD
git restore --source=HEAD~1 -- src/config.js

# Older syntax, identical behaviour
git checkout a1b2c3d -- src/config.js

# Discard uncommitted changes to a file (restore from HEAD)
git restore src/config.js

git restore --source=X -- file updates both the working tree and the index by default, so the change is staged and ready to commit. Add --worktree only, or --staged only, if you want finer control.

Finding the right commit first

You need the commit where the file was still correct, which means reading its history rather than the branch’s.

# Every commit that touched this file
git log --oneline -- src/config.js

# Follow the file through renames
git log --follow --oneline -- src/config.js

# With the actual changes
git log -p -- src/config.js

# Who changed each line, and in which commit
git blame src/config.js

# Search history for when a string appeared or vanished
git log -S 'apiTimeout' --oneline -- src/config.js

git log -S is the one worth remembering. It finds commits where the number of occurrences of a string changed, which answers when did this line get deleted directly rather than by scrolling through diffs.

Before restoring, look at what you would be changing:

# Compare the current file against that commit's version
git diff a1b2c3d -- src/config.js

# Read the old version without touching anything
git show a1b2c3d:src/config.js

# Save it elsewhere to compare side by side
git show a1b2c3d:src/config.js > /tmp/config.old.js

git show <commit>:<path> is genuinely useful and underused — it prints a file at any point in history without modifying your working tree at all.

Reverting one file’s changes from a specific commit

A subtly different task: a commit changed five files, and you want to undo its effect on one of them while keeping the other four.

# The file as it was BEFORE that commit
git restore --source=<commit>^ -- path/to/file
git commit -m 'Revert config change from <commit>'

# Or apply the inverse of just that file's diff
git show <commit> -- path/to/file | git apply --reverse
git add path/to/file
git commit -m 'Revert config change from <commit>'

The ^ suffix means the parent commit — the state before the change. <commit> gives you the file after; <commit>^ gives you the file before. Getting these the wrong way round is the most common error here and produces a no-op that looks like a broken command.

The git apply --reverse form is better when other changes have landed on the file since. It inverts only that commit’s hunks rather than overwriting the whole file, so subsequent legitimate edits survive. It can conflict, which is honest — a conflict means the later edits genuinely overlap what you are undoing.

Recovering a deleted file

The file is gone and you need the commit that removed it — which is not the commit you want to restore from.

# Find the commit that deleted it
git log --diff-filter=D --oneline -- path/to/deleted-file.js

# Restore from that commit's PARENT, where it still existed
git restore --source=<deleting-commit>^ -- path/to/deleted-file.js

# If you do not know the path, search all of history
git log --diff-filter=D --name-only --oneline | grep -i 'config'

--diff-filter=D filters to commits that deleted files, which turns a history search into one command.

For a file deleted but never committed, the reflog will not help — uncommitted work is not in Git at all. If it was staged at some point, git fsck may find it:

git fsck --lost-found
# Dangling blobs land in .git/lost-found/other/
# Inspect them with: git show <blob-sha>

This is a strong argument for committing early and often, even on messy work-in-progress branches. Git can only recover what it was told about.

Doing it in the GitLab or GitHub interface

When you do not have a terminal — reviewing on a phone, or a repository you have not cloned — the web interfaces cover the common cases.

In GitLab:

Navigate to the file, then select History to see commits that touched it.
Open the commit where the file was correct.
Use the file’s options menu to view it at that revision, then Edit and commit the restored content.
For a whole commit, GitLab’s Revert button on the commit or merge request page creates a revert commit, optionally in a new merge request.

In GitHub: open the file, click History, choose the commit, then use the View file option at that revision, copy the content, and edit the current file. GitHub also has a Revert button on merged pull requests that opens a revert PR.

Both platforms’ revert buttons operate on whole commits or merge requests, not on single files. For one file out of a multi-file commit, the web UI route is to view the old version and edit the current one — which is fine, and slower than the command line.

GitLab’s revert-to-new-merge-request option is genuinely useful on a protected branch, since it produces something reviewable rather than a direct push you would not be allowed to make anyway.

Restoring is not deploying

Worth separating two things that get conflated when something is broken in production. Restoring a file fixes the repository. It does not fix what is running.

The sequence that matters under pressure is: restore, commit, push, deploy — and the last step is the one that determines how long the incident lasts.

Rolling back the deploy is usually faster than fixing forward, and the two are not in tension: roll back to stop the bleeding, then take your time restoring the file properly. A platform that keeps previous deploys makes that a button rather than a rebuild — on RunxBuild each deploy maps to a commit with rollback to the previous one, covered in the GitHub deployment documentation.

The related habit is small commits. Restoring one file out of a commit that changed five is fiddly; reverting a commit that changed one file is trivial. git add -p and focused commits make every one of these operations easier, and they cost about ten seconds each.

How this fits the rest of the stack

Use git restore --source=<commit> -- path for a single file, remembering that <commit>^ gives you the state before that commit rather than after. git revert cannot target a path, which is the confusion at the heart of this. And when production is broken, roll back the deploy first and restore the file properly afterwards. If you are setting up deploys where each commit is a rollback point, the RunxBuild hosting calculator shows the build and runtime costs separately.

Useful related references:

FAQ

How do I revert a single file in Git?

Use git restore —source= — path/to/file, or the older git checkout — path/to/file. Both update the working tree and index so the change is staged and ready to commit.

Why can git revert not target one file?

git revert operates on whole commits and creates an inverse commit, so it has no path argument. To undo one file’s changes from a commit, restore that file from the commit’s parent using the ^ suffix instead.

How do I restore a file that was deleted in an old commit?

Find the deleting commit with git log —diff-filter=D —oneline — path, then restore from its parent: git restore —source=^ — path. The file existed in the parent, not in the commit that removed it.

What is the difference between commit and commit^ when restoring?

commit gives you the file as it was after that commit’s changes; commit^ gives you the parent, meaning the state before them. Undoing a change needs the parent, and mixing these up produces a no-op.

Can I revert a single file from the GitLab web interface?

Not with the Revert button, which operates on whole commits and merge requests. View the file at the earlier revision through its History, then edit the current file with that content and commit.