推送到 GitHub 远程存储库后删除的文件
Files deleted after push in GitHub remote repository
我的第一个 Git 存储库是我在线创建的，名为 myName/python-algorithms。
它包含许多 Python 脚本。我尝试使用以下命令从本地 Ubuntu 终端添加文件 test.py：
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"
git remote add origin https://github.com/myname/Python_Algorithms.git
git remote -v
git push -f origin master
它删除了我所有的 Python 脚本，并用 GitHub 上的文件 test.py 替换了它们。
知道如何取回已删除的脚本吗？
所以有几种方法可以修复不需要的提交。看起来您的本地 git 存储库可能没有远程存储库中的所有信息，这导致您的推送覆盖了它。
在您的终端中，使用 git 日志查看本地 git 的提交历史记录。如果它只列出您的测试提交，我们将需要以不同的方式找到最后一个好的提交（所有文件仍然存在的地方）。
转到您的 git 中心并导航到您的提交历史记录。
您应该在最后一次推送 "some init msg" 之前看到一个提交，它覆盖了您的其他文件。它将在右侧有一个十六进制标识符（蓝色）。复制它！
从您的 git 终端，您想使用命令：
git 结帐复制十六进制#
这会将包含所有文件的版本复制到您的本地存储库。但是，您将处于分离的 HEAD 状态，并且应该收到一条消息。您需要使用以下方法将其变成一个新分支：
git 结帐-b some_new_branch_name
然后你可以正常进行（与 master 合并或继续单独工作，push 等）
此处提供更多有用信息：https://www.atlassian.com/git/tutorials/undoing-changes
希望对您有所帮助！
Any idea how I can get back my scripts that were deleted?
主要方法：找到原始存储库的备份 copy/clone（或请求 GitHub 管理员找一个）。
一种临时方式：如果您的散列 ID 显示在 window 中的某处或写在纸上或白板上的某处，并且可以导航 到 GitHub URL 用于该提交（例如，https://github.com/git/git/commit/b9e62f60115c75c5be5de593862925c8b8d7e683 是 GitHub 上的一个特定提交的 URL 在这个特定的 Git 存储库中 Git)，通过单击 "Browse Files" 使用它来访问 树 对象，并使用它来访问您的文件。您可以在有限的时间内 window 进行此操作；之后，GitHub 的维护清理器将删除提交，除非通过备份副本或其他克隆，否则无法恢复它们。
记住，Git 存储是 提交。每次提交都包含所有文件的完整快照，以及一些 元数据: 关于提交的信息，例如提交人和提交时间。每个提交都有一个唯一的哈希 ID，因此任何 Git 存储库都可以通过检查哈希 ID 立即判断它是否具有该提交。如果存储库具有 that 哈希 ID 的提交，则它具有 that commit.
同时，当然，每个 存储库 都包含一些提交集。您的 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 for "hash":
H <-- master
与此同时，位于 https://github.com/myname/Python_Algorithms.git 的 GitHub 存储库还有其他提交。假设它有四个提交，并将它们称为 A、B、C 和 D。它的 master 持有提交 D 的哈希 ID，它指向提交 C，它指向 B，它指向 A，这是that 存储库中的第一个提交因此没有指向任何地方：
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 没有 没有 父项：这是一个新的根提交，例如 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
此时，GitHub 存储库中的旧提交无法通过正常的Git 机制访问。最终，他们的 Git 维护/看门人处理将会出现并永远清除原始的提交链。在那之前，直接URL通过.../commit/<hash>URL访问绕过了正常的Git机制，所以它仍然可以工作。但是所有常规 Git 操作都被这样一个事实所挫败，即它们的 master 现在指向提交 H 并且它们的 Git 无法 find 提交 D.
您或其他人可能制作了一些其他克隆，其中包含提交 D（如果是这样，它可能也有 A 到 C，或者也许它只有 A 到 C，因为它在添加 D 之后从未更新过，或其他）。如果您可以找到这样的存储库，并且可以通过哈希 ID 或 master 之类的名称访问它的提交，您就可以通过这些提交以这种方式获取文件。如果不是……那么，这就是为什么 git push --force 是危险的！
已修复：感谢 torek 评论，我按如下方式修复了它。来自：
https://api.github.com/repos/myName/Python_Algorithms/events
我在强制推送发生之前找到了旧的 HASH_ID。然后我去了link:
https://github.com/myNAme/Python_Algorithms/commit/HASH_ID
然后我使用浏览文件进行管理，然后返回到我的文件。
谢谢 toreks
我的第一个 Git 存储库是我在线创建的，名为 myName/python-algorithms。
它包含许多 Python 脚本。我尝试使用以下命令从本地 Ubuntu 终端添加文件 test.py：
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"
git remote add origin https://github.com/myname/Python_Algorithms.git
git remote -v
git push -f origin master
它删除了我所有的 Python 脚本，并用 GitHub 上的文件 test.py 替换了它们。
知道如何取回已删除的脚本吗？
所以有几种方法可以修复不需要的提交。看起来您的本地 git 存储库可能没有远程存储库中的所有信息，这导致您的推送覆盖了它。 在您的终端中，使用 git 日志查看本地 git 的提交历史记录。如果它只列出您的测试提交，我们将需要以不同的方式找到最后一个好的提交（所有文件仍然存在的地方）。
转到您的 git 中心并导航到您的提交历史记录。 您应该在最后一次推送 "some init msg" 之前看到一个提交，它覆盖了您的其他文件。它将在右侧有一个十六进制标识符（蓝色）。复制它！
从您的 git 终端，您想使用命令： git 结帐复制十六进制#
这会将包含所有文件的版本复制到您的本地存储库。但是，您将处于分离的 HEAD 状态，并且应该收到一条消息。您需要使用以下方法将其变成一个新分支： git 结帐-b some_new_branch_name 然后你可以正常进行（与 master 合并或继续单独工作，push 等）
此处提供更多有用信息：https://www.atlassian.com/git/tutorials/undoing-changes
希望对您有所帮助！
Any idea how I can get back my scripts that were deleted?
主要方法：找到原始存储库的备份 copy/clone（或请求 GitHub 管理员找一个）。
一种临时方式：如果您的散列 ID 显示在 window 中的某处或写在纸上或白板上的某处，并且可以导航 到 GitHub URL 用于该提交（例如，https://github.com/git/git/commit/b9e62f60115c75c5be5de593862925c8b8d7e683 是 GitHub 上的一个特定提交的 URL 在这个特定的 Git 存储库中 Git)，通过单击 "Browse Files" 使用它来访问 树 对象，并使用它来访问您的文件。您可以在有限的时间内 window 进行此操作；之后，GitHub 的维护清理器将删除提交，除非通过备份副本或其他克隆，否则无法恢复它们。
记住，Git 存储是 提交。每次提交都包含所有文件的完整快照，以及一些 元数据: 关于提交的信息，例如提交人和提交时间。每个提交都有一个唯一的哈希 ID，因此任何 Git 存储库都可以通过检查哈希 ID 立即判断它是否具有该提交。如果存储库具有 that 哈希 ID 的提交，则它具有 that commit.
同时，当然，每个 存储库 都包含一些提交集。您的 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 for "hash":
H <-- master
与此同时，位于 https://github.com/myname/Python_Algorithms.git 的 GitHub 存储库还有其他提交。假设它有四个提交，并将它们称为 A、B、C 和 D。它的 master 持有提交 D 的哈希 ID，它指向提交 C，它指向 B，它指向 A，这是that 存储库中的第一个提交因此没有指向任何地方：
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 没有 没有 父项：这是一个新的根提交，例如 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
此时，GitHub 存储库中的旧提交无法通过正常的Git 机制访问。最终，他们的 Git 维护/看门人处理将会出现并永远清除原始的提交链。在那之前，直接URL通过.../commit/<hash>URL访问绕过了正常的Git机制，所以它仍然可以工作。但是所有常规 Git 操作都被这样一个事实所挫败，即它们的 master 现在指向提交 H 并且它们的 Git 无法 find 提交 D.
您或其他人可能制作了一些其他克隆，其中包含提交 D（如果是这样，它可能也有 A 到 C，或者也许它只有 A 到 C，因为它在添加 D 之后从未更新过，或其他）。如果您可以找到这样的存储库，并且可以通过哈希 ID 或 master 之类的名称访问它的提交，您就可以通过这些提交以这种方式获取文件。如果不是……那么，这就是为什么 git push --force 是危险的！
已修复：感谢 torek 评论，我按如下方式修复了它。来自：
https://api.github.com/repos/myName/Python_Algorithms/events
我在强制推送发生之前找到了旧的 HASH_ID。然后我去了link:
https://github.com/myNAme/Python_Algorithms/commit/HASH_ID
然后我使用浏览文件进行管理，然后返回到我的文件。
谢谢 toreks