如何破坏 Git 存储库？

Question

有哪些方法可以创建损坏的 git 存储库？有没有办法有趣地永久损坏 git 存储库？你能否削弱一个 git 存储库，使其行为正常但做一些奇怪的事情？

我的兴趣来自于有人担心他们是否真的创造了一个不可恢复的状态。事实证明，它通常很容易修复或至少可以拼凑起来。 git 中有隐藏的（邪恶）宝石吗？

Answer 1

嗯，可能发生的最直接的损坏是.git/objects 目录中的数据或数据完整性丢失。由于它被设计成一个不可变的、只写的存储机制，一旦你违反了这个假设，很多其他的东西就会崩溃。最常见的是，这可能是由网络传输中损坏的包文件引起的。但是，除非您非常（阅读：天文数字）不走运，否则 git 会理所当然地检测到这一点并大声抱怨。要以这种方式获得静默失败，您需要破坏 blob，使其保留其 SHA1 哈希...在 deflate 压缩下...具有准确的类型和大小标头。

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

1. 与该状态关联的提交和其他对象未被引用（即，.git/refs 下的任何命名 ref 或任何 reflog 都无法访问）；那么
2. 垃圾收集实际上永久删除状态，或者获取新的克隆并删除原始状态。

否则，您将始终能够运行 git checkout <sha> && git branch recovered 并取回所有工作，无论您做了什么其他工作。在正常的 git 使用期间，当您变基、cherry-pick 或 filter-branch 时，提交会像这样孤立，所有这些都基于旧的提交对象创建新的提交对象，或者如果您 git reset --hard 一个分支。默认情况下，在它们被删除之前，您有一个宽限期 about two weeks，然后，尽管您始终可以截断您的 reflog 并手动修剪以尽早删除某些内容。

更常见的情况是，当用户一开始从未将数据添加到 git 时，我会看到数据丢失。例如，新用户有时会犹豫是否频繁提交，并尝试使用带有脏工作副本的命令。如果你从来没有在 git 中记录过一个状态，那么 git 就无法为你找回状态！

如果您对 可恢复 但 难以注意到 诡计没问题，您可以使用 git replace 或 graft points 做一些坏事来欺骗 git 操作在具有合并或过滤分支操作的虚假历史记录上。不过，被替换的提交仍然算作可达，因此不会造成永久性损坏。