您可能能够从中止的提交中恢复文件
基于@the-malkolm 的观察。
从问题中的信息来看,没有提交,并且文件在任何时候都没有被跟踪。因此 git 并不真正了解任何已删除的文件。
尽管如此,还是有希望的。仅仅因为您尝试在删除文件之前提交文件,就会出现一个幻像提交,其中包含您的所有文件。
这是一个例子:
$ git init
Initialised empty Git repository in /tmp/so/.git/
$ echo "find this text" > README.md
$ git add README.md
$ git commit -v
Aborting commit due to empty commit message.
$ git rm -rf .
rm 'README.md'
$ git status
# On branch master
#
# Initial commit
#
nothing to commit (create/copy files and use "git add" to track)
上面模拟了问题中的事件,通常这就是重新开始重写代码的时候了。没有提交,文件不见了。
识别中止的提交
但是检查.git
存储库会产生一些信息:
$ tree .git/objects/
.git/objects/
├── 91
│ └── 9cdf847a6af7c655c8de1d101385f47f33e0f9
├── d6
│ └── 7d51abe2521dcd00cec138b72f5605125c1e41
├── info
└── pack
尽管没有提交,但 git 存储库中有对象。有必要确定两个对象中的哪一个是树:
$ git ls-tree 919cdf
fatal: not a tree object
$ git ls-tree d67d51
100644 blob 919cdf847a6af7c655c8de1d101385f47f33e0f9 README.md
$
第一个引用是代表 README.md 文件的blob - 存储库中的每个文件都有一个 blob,本示例中的第二个是树引用。
重新创建工作副本
一旦确定了树哈希,就可以使用read-tree重建索引:
$ git read-tree d67d51abe2521dcd00cec138b72f5605125c1e41
$ git status
# On branch master
#
# Initial commit
#
# Changes to be committed:
# (use "git rm --cached <file>..." to unstage)
#
# new file: README.md
#
# Changes not staged for commit:
# (use "git add/rm <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# deleted: README.md
$
此时,工作副本为空,但丢失的文件已暂存以进行提交。
提交他们:
$ git commit -m "phew"
并签出以匹配存储库的提交状态:
$ git checkout .
$ ls
README.md
然后,所有文件都存在并已提交。