什么可能导致git中的数据丢失？

Question

我不想在git中蠢蠢欲动，我想像他们在FaceBook上所说的那样“快速行动并打破局面”。实际上，我认为这几乎是版本控制的重点。我真正需要注意什么？

我猜git rm，尤其是-r可能很危险。

什么时候分支，什么导致覆盖？

Answer 1

一般来说，很难在 git中导致数据丢失。即使在运行从历史记录中删除提交或删除分支的命令时，Git也几乎从未真正删除已经检入存储库的任何内容。

您唯一需要担心的是删除尚未签入git的文件的命令。通常，git将需要这些命令的--force（-f）或--hard标志。

以下是潜在危险命令的快速列表以及使用它们时需要注意的事项：

可以永久删除未提交给git的数据：

• git rm -f - 可以删除尚未签入的文件
• git reset --hard - 将删除尚未签入git的更改
• git clean -f - 将删除未由git
跟踪的文件
• git checkout /path/to/file - 可以将未签入的更改还原为git
• git checkout <rev> -f - 可以覆盖未签入git的更改
• rm -rf .git - 请勿删除您的.git目录！这就是存储所有当地历史的内容。

可以删除远程存储库上的数据（可逆，但您可能没有恢复远程存储库提交所需的访问级别）：

• git push -f - 从远程存储库中的分支中删除历史记录
• git push <remote> :<branch> - 或 - git push <remote> --delete <branch> - 删除远程分支

可以永久删除原本可以恢复的已删除数据（类似于清空操作系统上的垃圾箱）：

• git prune - 永久删除无法从任何分支到达的提交
• git gc - 永久删除无法从任何分支机构访问的旧提交

可以删除本地提交（它们很容易恢复）：

• git reset <revision> - 可以从分支中删除历史记录（虽然大约两周左右可以在本地恢复，但除非您运行git prune）
• git branch -D <branch> - 删除尚未合并的分支（可在本地恢复）
• git branch -f <branch> <rev> - 可以从分支中删除历史记录（可本地恢复）

Answer 2

我学习git最重要的事情就是尽早提交并经常提交。如果您在版本控制中记录了您的更改，那么如果您搞砸了，还有一种方法可以恢复它。在过去的一年中，我有很多时刻，我以为我丢失了数据，但是通过Stack Overflow搜索了一些巧妙的技巧。保持您的数据托管在远程服务器（如GitHub或BitBucket）上，这样如果您完全销毁您的仓库，它仍然在某个地方。如果您执行git branch -D <branch>并删除分支，则该分支上的所有提交都将从回购中清除。

如果你不确切知道自己在做什么，那么我唯一可以真正警告你的是永远不会重写历史。可以执行此操作的是git-reset和git-rebase。除非您知道自己在做什么，否则永远不要做git push <remote> <branch> -f，因为这会强制用本地仓库覆盖所有提交。如果您在本地更改了分支历史记录，或者其他人对回购协议做出了贡献，则可能会导致重大问题。

@meager也提出了一个很好的观点：如果删除git尚未跟踪/提交的文件，您将无法恢复它。

作为旁注，不要害怕使用git-reset和git-rebase，只需要正确使用它们。例如，我有时使用git-reset将工作树重置为最新提交（撤消所有已更改的文件）{@ 1}}或撤消上一次提交消息，同时保留我的工作树git reset --hard HEAD。 Git rebase也可以帮助压缩/重写历史记录中的多个提交。请注意，这些方法可能会导致数据丢失，如果您已经推送到远程仓库，则不应该这样做（从那时起，您需要执行git reset --soft HEAD^。

Answer 3

根据你认为Git可能会跟踪或未跟踪的内容，Git可能会失去＆＃34;您可能希望它持有的各种信息。如果您不熟悉Git内部或它与其他系统的区别，那么分支和标签很容易在随机播放中丢失。

请参阅How to use git to lose data

Answer 4

git rm并不危险，因为您之后可以从之前的提交中检索文件。

作为一般经验法则，请注意-f选项：它迫使Git做一些它不想做的事情。 （例如：branch -f或push -f）

Answer 5

以上都不是。在Git 中导致数据丢失非常困难。当您删除Git尚未跟踪的文件时，Dataloss会发生在Git的外部。如果您在垃圾收集发生之前尝试恢复，这是周的窗口，那么在 Git内部发生的任何感知“数据丢失”都是可恢复的。

经常以小步骤提交您的更改。不要担心产生好的提交消息或漂亮的DAG;无论如何，在合并功能分支之前，你会压缩所有这些东西。在你完成工作之前，这项工作将面临失败的危险。

Answer 6

作为一个方便的提示，如果您认为已删除分支，带注释的标记或重置为先前的提交，您没有丢失它们，您的本地更改都会被记录，您可以使用{{1}查看它们}。

看它只是为了看它记录的内容很有意思。

它列出了可用于将分支恢复到该状态的提交sha。

Answer 7

当您错误地解决冲突时，

存在风险：在eclipse中，当解决文件冲突时，我们遇到了问题。 a.txt声称有冲突，而b.txt被拉/取并显示在索引中。如果用户现在将文件b.txt从索引中删除回到unstaged - 并且只附加他解决的a.txt，并且提交和推送 - 提交将具有来自用户PARENT提交的b.txt状态 - 不再是他本来会得到的版本。问题是，此更改不会显示 - 文件未在提交中列出。您无法直接发现此问题。 （仅当您检查文件的内容时 - 如果是二进制文件，则只能检查BLOB。）需要两个用户，两个存储库+一个裸文件和两个文件。我们在eclipse / egit中发现了这一点 - 不确定它是否也是控制台的问题。您可以使用git ls-tree <commit>

检查blob

Answer 8

正如meagar所说，git rm是一个记录在新提交中的删除，所以它是可以恢复的，可以毫无顾虑地使用。

git reset --hard可能特别有害，因为它会将“当前提交”（Git术语中的HEAD）重置为另一个。因此，如果先前的HEAD未在分支或标签中引用，则它实际上已丢失（至少没有巫术）。它还会导致您未提交的更改丢失。

删除分支和标记也是如此：它可能导致从存储库中清除一行提交。在这些情况下，提交被隐藏在存储库中，您可以恢复它们，但它是技术性的而且不是很容易，因此您最好知道自己在做什么。

与您的数据非常珍贵（以及源代码）的任何其他情况一样，非常希望拥有存储库的镜像，并定期推送它。它可以是另一个本地存储库，一个私有GitHub存储库，或者只是使用当前备份系统备份存储库。这样你就可以随时恢复。

正如其他人在这里所说，请注意那些非常重要的未跟踪文件。未跟踪/忽略的文件应该只是从版本控制下的文件生成的文件：可执行文件等。