Git can include many files in a single commit. You can modify, add, or delete multiple files, then commit the new state of the working directory.
What if we deleted multiple files, and now we need to recover in Git some but not all of what has been
deleted?
Since Git tracks the state of our repository as a series of snapshots
(aka Commits) in time, we can recover the file by looking at a past snapshot /
commit and “checking out” the resource(s) we must recover.
For example: Let's say that a few days ago I
deleted several files from the Git repository. I deleted them on my local, committed the
change, and pushed to the server. Other developers have done many other commits since then.
Now, it turns out one of the files is needed after
all, but the others should remain deleted. How to get the one file back?
I will show some Git command-line steps to
retrieve it. There are other ways, using your IDE, File Explorer, Tortoise or
your UI of choice. But the command-line shows best what has to happen.
$ git rev-list -n 1 HEAD -- src/js/SomeOldFile.js
b654fa9411d11624035c7e2eacb69caa65399782
The first step is to see what commit in our repository
history last referred to the file to be restored. The command “git rev-list”
lists commits in reverse-chronological order. I specified “-n 1” because I was only interested in 1
commit: the most recent, i.e. the commit that deleted the file.
“HEAD” tells the command where to start from. In my case, I
wanted to start from the HEAD commit, which was currently pointing to the most
recent commit on the dev branch.
“--
WebContent/Common/InfoPopupPos.js” specifies the file that we are interested in.
The result is the name of the last commit in which that file
was affected: “b654fa9411d11624035c7e2eacb69caa65399782”
$ git checkout b654fa94^ src/js/SomeOldFile.js
Next, we ask git to put into the Working Directory the
deleted file as it looked right before the commit that deleted it.
“git checkout” is the command to check out a branch or a
certain moment in history snapshot.
“b654fa94^” is the start of the commit name. I don’t want to
type the whole commit name, so I give it enough for git to know which one I
mean.
Notice the “^” at the end of the commit name. That character
tells git that we don’t want the commit, we want the state of the file right
before that commit.
If we stop there, the Working Directory would revert to
look like our whole code base did at that point in time. But since I want to restore a single file, not the whole repository, we add the file name to the
command. The result is that the deleted file is restored to the Working Directory, and everything else remains at the present state.
We would expect that we now have 1 new file change
to commit. Let’s check:
$ git status
On branch dev
Your branch is up-to-date with
'origin/dev'.
Changes to be committed:
new file: src/js/SomeOldFile.js
Just as expected, the deleted file has appeared in the Working Directory. Now we still need to commit it to be sure to keep it.
(Actually, since the file is ready to be committed, it added the file not just
to the Working Directory, but also to the Index).
$ git commit -m "Restore SomeOldFile.js since it is used after all"
[dev 748f49b] Restore SomeOldFile.js since it is used after all
1 file changed, 53 insertions(+)
The file is now committed to the local repository. Let’s check the
status again, to verify that. We should expect nothing local to commit, but a
difference between the local repository and the server repository upstream:
$ git status
On branch dev
Your branch is ahead of
'origin/dev' by 1 commit.
nothing to commit, working tree
clean
Good. Our change is committed locally, and is ready to push
to the server. As always, do a pull before attempting any push.
$ git pull
Current branch dev is up to
date.
$ git push
Counting objects: 5, done.
Compressing objects: 100% (5/5),
done.
Writing objects: 100% (5/5), 962
bytes | 0 bytes/s, done.
Total 5 (delta 2), reused 0
(delta 0)
Done! We have now used Git to restore a file that had been
deleted, committed and pushed several days ago, and many other commits had
happened since then. There were many other ways to accomplish it, but the steps
were:
- Find the commit that deleted the file;
- Restore (“check out”) the file from the commit before the one that deleted it;
- Commit it locally;
- Push it to the central repository.