有哪些方法可以创建损坏的 git 存储库?有没有办法有趣地永久损坏 git 存储库?你能削弱一个 git 存储库,使其行为正常但做一些奇怪的事情吗?
我的兴趣来自于有人担心他们是否真的创造了一个不可恢复的状态。事实证明,它通常很容易修复或至少可以拼凑起来。git中是否有隐藏(邪恶)的宝石?
有哪些方法可以创建损坏的 git 存储库?有没有办法有趣地永久损坏 git 存储库?你能削弱一个 git 存储库,使其行为正常但做一些奇怪的事情吗?
我的兴趣来自于有人担心他们是否真的创造了一个不可恢复的状态。事实证明,它通常很容易修复或至少可以拼凑起来。git中是否有隐藏(邪恶)的宝石?
好吧,可能发生的最直接的损坏是.git/objects
目录内的数据或数据完整性丢失。由于它被设计成一个不可变的、只写的存储机制,一旦你违反了这个假设,很多其他的东西就会崩溃。最常见的是,这可能是由网络传输中损坏的包文件引起的。但是,除非您非常(阅读:天文数字)不走运,否则 git 会理所当然地检测到这一点并大声抱怨。要以这种方式获得静默失败,您需要以一种方式破坏 blob,使其保留其 SHA1 哈希……在放气压缩下……使用准确的类型和大小标头。
所以,git 非常擅长验证自己的数据完整性。我们还能做什么?要真正使状态不可恢复,您需要:
.git/refs
或任何 reflog 都无法访问);然后git checkout <sha> && git branch recovered
否则,无论您做了什么其他工作,您都可以随时运行并恢复所有工作。在正常的 git 使用过程中,当您变基、cherry-pick 或 filter-branch 时,提交会像这样孤立,所有这些都会根据旧的提交对象创建新的提交对象,或者如果您git reset --hard
是一个分支。默认情况下,在它们被删除之前,您有大约两周的宽限期,然后,尽管您始终可以截断您的 reflog 并手动修剪以尽早删除某些内容。
更常见的是,当用户从一开始就从未将数据添加到 git 时,我会看到数据丢失。例如,新用户有时会犹豫是否频繁提交,并尝试使用带有脏工作副本的命令。如果你从来没有在 git 中记录过一个状态,那么 git 就无法为你找回状态!
如果您对可恢复但难以注意到的诡计没问题,您可以使用git replace或嫁接点做一些邪恶的事情,以欺骗 git 通过合并或过滤分支操作对虚假历史进行操作。不过,被替换的提交仍然算作可达,因此不会造成永久性损坏。