如何损坏Git存储库？

Question

什么是创建损坏的git仓库的一些方法？有没有办法永久损坏一个git仓库？你可以瘫痪一个git存储库，这样它的行为有点正常，但做了奇怪的事情？

我的兴趣来自于有人担心自己是否真的创造了不可恢复的状态。通常事情很容易解决或者至少拼凑在一起。有没有隐藏（邪恶）在Git宝石？

Answer 1

那么，可能发生的最直接的腐败是在.git/objects目录内丢失数据或数据完整性。由于它被设计成一个不可变的只写存储机制，所以一旦违反了这个假设，很多其他的东西就会崩溃。比如说，最常见的情况是网络传输中的包文件被破坏。除非你非常（看过：天文数字）不吉利，但git会把这当作是理所当然的事，并大声抱怨。为了以这种方式获得沉默的失败，你需要破坏一个blob，以便保留它的SHA1哈希......在deflate压缩下......使用精确的类型和大小的头文件。

因此，git非常擅长验证自己的数据完整性。我们还能做什么？要真正使国家不可恢复，您需要：

1. 与该国相关的提交和其他物体未引用（也就是说，不是由.git/refs下任何指定ref或引用日志任何可达）;然后
2. 垃圾收集实际上会永久删除该状态，或者采取新的克隆并删除原始垃圾。

否则，您将始终能够运行git checkout <sha> && git branch recovered，并无论您做了什么其他操作，都可以恢复所有工作。在基础git使用过程中，如果您使用rebase，cherry-pick或filter-branch创建新的提交对象，或者如果您在分支上创建新的提交对象，则提交会像这样孤立。默认情况下，您的宽限期为about two weeks，然后，尽管您可以总是截断您的reflog并手动修剪，以便尽早排除某些内容。

更为常见的是，当用户从不将数据添加到git中时，我看到数据丢失。例如，新用户有时会经常犹豫不决，并尝试使用带有脏工作副本的命令。如果你从来没有在git中记录过状态，那么git无法为你带回来！

如果您能够接受可恢复但难以通知诈骗，你可以做一些邪恶与git replace或graft points愚弄混帐到与合并或过滤分支操作的假历史操作。尽管如此，被替换的提交仍然算是可达的，所以它不会是永久性的损害。