知道如何找回被删除的脚本吗？
主要方式：找到原始仓库的备份副本/克隆（或请求GitHub管理员找到）。
一种临时方法：如果您有一个散列 ID 显示在窗口某处或写在纸或白板上某处，并且可以导航到该提交的 GitHub URL（例如，@987654321 @ 是这个特定 Git 存储库中 GitHub 上的一个特定提交的 URL），通过单击“浏览文件”使用它来访问 tree 对象，然后使用它来访问你的文件.您可以在有限的时间范围内执行此操作；之后，GitHub 的维护清理器将删除提交，并且它们将无法恢复，除非通过备份副本或其他克隆。
记住，Git 存储的是提交。每个提交都包含您所有文件的完整快照，以及有关提交的一些元数据： 信息，例如提交者和时间。每个提交都有一个唯一的哈希 ID，因此任何 Git 存储库都可以通过检查哈希 ID 立即判断它是否具有该提交。如果存储库有一个带有 that 哈希 ID 的提交，它有 那个提交。
同时，当然，每个 repository 都包含一些提交。您的 GitHub 存储库有一些提交，其中包含您的文件。
当您创建一个新的空存储库时：
git init
git config user.name "myName"
git config user.e-mail "myEmail@myEmail.se"
这个新的空存储库根本没有提交。这没什么大不了的，因为您可以进行新的提交：
git add test.py
git commit -m "some init msg"
这个新的存储库现在有 一个 提交。让我们画出来。它有一些丑陋的散列 ID，但我们称它为 H 表示“散列”：
H <-- master
同时，https://github.com/myname/Python_Algorithms.git 的 GitHub 存储库还有其他提交。假设它有四个提交，并称它们为A、B、C 和D。它的master 持有提交D 的哈希ID，它指向提交C，它又指向B，又指向A，这是that中的第一个提交em> 存储库，因此不指向任何地方：
A <-B <-C <-D <-- master (in the Git on GitHub)
当你运行git push 没有 -f:
git remote add origin https://github.com/myname/Python_Algorithms.git
git remote -v
[以及你没有做什么：]
git push origin master
你的 Git 会调用另一个 Git 并提供你的一个提交，你有而他们没有。到目前为止，一切都很好：他们接受了那个提交并将其放在隔离区。然后，您的 Git 对他们的 Git 说：如果没问题，请使用此提交的哈希 ID 设置您的分支名称 master。
他们的 Git 在他们的存储库中查找，该存储库具有以 D 结尾的提交链。它尝试向后提交H，以查看是否会使其提交D。但是提交 H 有 no 父级：它是一个新的根提交，例如 A。所以H 不会返回D，GitHub 会响应你的 Git：不！如果我用提交哈希 H 覆盖我的名字 master，我将丢失提交 D，从而也丢失所有之前的提交！
唉，你告诉你的 Git 到 git push -f origin master，添加 force 标志。强制标志将您的 Git 礼貌的如果可以请求更改为命令：设置您的master！
GitHub 上的 Git 服从了。他将他的master 设置为指向H：
A--B--C--D [abandoned]
H <-- master
此时，普通 Git 机制无法访问 GitHub 存储库中的旧提交。最终，他们的 Git 维护/看门人处理将出现并永远清除原始提交链。在此之前，通过.../commit/<hash> URL 通过直接 URL 访问绕过了正常的 Git 机制，因此它仍然可以工作。但是所有常规的 Git 操作都被他们的master 现在指向提交 H 并且他们的 Git 无法find提交 D 的事实所挫败。
您或其他人可能制作了其他克隆，其中包含提交D（如果是这样，它可能也有A 到C，或者它可能只有A 到@ 987654365@，因为它在添加D 或其他任何内容后从未更新过）。如果您可以找到这样的存储库，并且可以通过哈希 ID 或 master 之类的名称访问其提交，那么您可以从这些提交中获取您的文件。如果不是……那么，这就是为什么git push --force 很危险！