Git:在git中查找已删除的文件，不在日志中提交

Question

我犯了一个错误，我想恢复一个以某种方式从我的 GitHub 存储库中删除的文件。该文件是在GitHub界面在线编辑创建的markdown文件，所以它没有出现在我的本地日志中，并且在git fetch之后也没有浮出水面。或 git pull .我在这里阅读了很多关于如何查找已删除文件的其他帖子，但它们不适合我的情况:

例如这篇文章:Git: How to search for a deleted file in the project commit history?运行建议的命令:

git log --all -- **/thefile.*

没有产生任何结果(根本没有打印)。我还运行了在 git 历史记录中查找所有文件删除的命令:

git log --all --diff-filter=D --summary

并没有找到我要找的东西。

我认为这与我直接在 GitHub 远程存储库中创建和编辑文件有关。它可能从未出现在我的本地存储库中，并且可能已被推送以某种方式覆盖。我对 Git 相对缺乏经验，所以我不确定如何从这里开始。关于如何进行的任何建议，或者我是 S.O.L？有没有一连串的事件会导致这样的事情发生，而我将来可以避免？谢谢!

Answer 1

如何找到对存储库进行更改的时间？

底线:您应该使用 git bisect 来完成此任务。

---

深入解释:

如果你想手动搜索日志，你​​可以使用 git log --cc (git v>2.X)。它将向您显示每次提交中的更改列表

您当然可以将其转储到文件并搜索文件内容或屏幕。

---

但是如果我有太多的提交而无法手动检查它们怎么办？

这就是 git bisect 派上用场的地方。 git bisect 搜索您的存储库，并根据给定的退出代码确定是哪个提交引发了“问题”。

您可以手动使用 bisect 或将其传递给脚本以使用脚本自动执行该过程。 (见下面的平分运行)

---

The bisect command does a binary search through your commit history to help you identify as quickly as possible which commit introduced an issue.

Let’s say you just pushed out a release of your code to a production environment, you’re getting bug reports about something that wasn’t happening in your development environment, and you can’t imagine why the code is doing that. You go back to your code, and it turns out you can reproduce the issue, but you can’t figure out what is going wrong.

You can bisect the code to find out.
First you run git bisect start to get things going, and then you use git bisect bad to tell the system that the current commit you’re on is broken. Then, you must tell bisect when the last known good state was, using git bisect good [good_commit]...

---

平分运行

If you have a script that can tell if the current source code is good or bad, you can bisect by issuing the command:

git bisect run my_script arguments

---

Note that the script (my_script in the above example) should exit with code 0 if the current source code is good/old, and exit with a code between 1 and 127 (inclusive), except 125, if the current source code is bad/new.

Any other exit code will abort the bisect process.

The special exit code 125 should be used when the current source code cannot be tested. If the script exits with this code, the current revision will be skipped (see git bisect skip above).

125 was chosen as the highest sensible value to use for this purpose, because 126 and 127 are used by POSIX shells to signal specific error status (127 is for command not found, 126 is for command found but not executable—​these details do not matter, as they are normal errors in the script, as far as bisect run is concerned).

---

这是一个图形化的 luustartion 可以正常工作
http://www.effectiveperlprogramming.com/wp-content/uploads/bisect1.png

这是我的一个 guthub 存储库中的示例代码，以了解您如何使用它