How to revert changes from old commit in a single file

Question

How do I revert/remove the changes done in an older multi-file commit, but only do it in a single file? Ie something like

git revert <commit-specifier> <file>

except git revert does not accept <file> argument. None of the following answers addresses this problem:

Git: Revert old commit on single file is rather about how to debug conflicts.

Undo a particular commit in Git that's been pushed to remote repos does not address my single file issue.

Git: revert on older commit also does not address single file issue.

Answer 1

Git is a tool-set, not a solution, so there are multiple solutions. However, one relatively straightforward way is to start with git revert -n , which starts the revert but does not finish it:

git revert -n <commit-specifier>

This tries to back out all changes to all files, of course. You only want to back out changes to one file. But now that git revert has made this attempt without committing you merely need to restore each file that you didn't want changed. Get a list of such files, and then use git checkout or git restore —using the commands exactly as git status advises—to make those files match the current commit. Now git status will show only the one file as changes to be committed , and you can now git commit that one file.

Another relatively straightforward way is to use:

git show <commit-specifier> -- <pathspec> | git apply -R

You can add -3 to the git apply command if you'd like Git to use a three-way merge on the base version of the file; in this case it may help to add --full-index to the git show command options. (As with the cherry-pick -n method you will have to commit the result yourself.)

Answer 2

You can revert it first:

git revert <commit-specifier>

then reset HEAD~1:

git reset --soft HEAD~1

and git add only the file that you want to do the revert:

git add -- <revert_file>

Now you can commit again

git commit --amend

remove all the other changes:

git checkout -- .

Answer 3

I accidentally committed a file with a couple of lines of changes and realized after 10 or so commits later. That file should have never been part of any commit. Reverting using any of the suggested answers in this post or any other SO answers was horrible in my case. Ran into lots of merge conflict hell and numerous git errors. I gave up and manually opened the local file and copied/pasted the text from master and made the commit. Viola. PR didn't show that file at all as changed - luckily I'm the only one working on that repo for now. It literally took me 10 seconds, If I followed the answers in SO. I would probably spend 15 or more minutes and introduced more problems trying to fix the conflicts? Why in the world git has to make things super complicated for trivial use cases,. So if you run into issues like I had, see if you can revert the changes directly on the file itself and commit.

I realize what I did may not apply to everyone's situation but still simple things are so unnecessarily complicated in git. Just look at the number of error prone git commands you need to monkey around with to accomplish what I did in 10 seconds.