如何损坏Git存储库? [英] How can I corrupt a Git repository?

问题描述

创建损坏的git存储库有哪些方法?有没有办法有趣地永久损坏git存储库?您可以削弱git存储库，使其行为正常但会发生奇怪的事情吗?

What are some ways to create a corrupt git repository? Are there ways to permanently damage a git repository interestingly? Can you cripple a git repository such that it behaves somewhat normally but does strange things?

我的兴趣来自某人担心自己是否真的创建了不可恢复的状态.通常证明它很容易修复，或者至少可以拼凑在一起.git中有隐藏的( evil )宝石吗?

My interest comes from when someone is worried about if they've truly created an unrecoverable state. It usually turns out to be something easy to fix or at least to piece together. Are there hidden (evil) gems in git?

推荐答案

好吧，可能发生的最直接的损坏是 .git/objects 目录中的数据丢失或数据完整性.由于它被设计为一种不变的，只写的存储机制，因此一旦违反了这一假设，许多其他事情将分崩离析.例如，最常见的原因是打包文件在网络传输中损坏.不过，除非您非常不幸(阅读:天文学)，否则git会自然而然地检测到这一点并大声抱怨.为了以这种方式获得无提示的失败，您需要以一种破坏blob的方式来破坏它，以使其SHA1哈希...在deflate压缩下...具有准确的type-and-size标头.

Well, the most straightforward corruption that can happen is the loss of data or data integrity inside the .git/objects directory. Since it's designed to be an immutable, write-only storage mechanism, once you violate that assumption, lots of other things will fall apart. Most commonly this would be caused by packfiles that were corrupted in network transmission, say. Unless you're very (read: astronomically) unlucky, though, git will detect this as a matter of course and complain loudly. To get a silent failure this way, you'd need to corrupt a blob in such a way that it preserves its SHA1 hash... under deflate compression... with an accurate type-and-size header.

因此，git非常擅长验证其自身的数据完整性.我们还能做什么?要真正使状态不可恢复，您需要:

So, git is pretty good at verifying its own data integrity. What else can we do? To really make state unrecoverable, you need:

1. 与该状态关联的提交和其他对象是未引用的(即， .git/refs 下的任何命名ref或任何reflog无法访问)；然后
2. 垃圾回收实际上是永久删除状态，或者是新的克隆并删除原始副本.

1. The commits and other objects associated with that state to be unreferenced (that is, not reachable by any named ref under .git/refs or any reflog); then
2. Garbage collection to actually delete the state forever, or to take a fresh clone and delete the original.

否则，您将始终能够运行 git checkout< sha>&&git分支已恢复，无论您做什么，都可以将所有工作取回来.在对git进行常规操作时，如果对基础进行了变基，选择樱桃或筛选分支，则所有提交都是基于旧对象的，或者如果您 git reset --hard ，则在常规git使用过程中，提交都是这样的孤儿周围的一个分支.默认情况下，您的宽限期为大约两个星期，然后再删除它们，尽管您始终可以截断reflog并手动修剪以尽早删除某些内容.

Otherwise, you'll always be able to run git checkout <sha> && git branch recovered and get all of your work back, no matter whatever else you've done. Commits are orphaned like this during normal git usage when you rebase, cherry-pick, or filter-branch, all of which create new commit objects based on the old ones, or if you git reset --hard a branch around. By default you have a grace period of about two weeks before they get deleted, then, although you can always truncate your reflog and prune manually to nuke something early.

更常见的是，当用户从未将数据最初添加到git中时，我已经看到数据丢失.新用户有时不愿频繁提交，并尝试使用带有脏工作副本的命令.如果您从未在git中记录状态，则git无法为您恢复状态！

Far more often, I've seen data loss when users never add their data to git in the first place. New users are sometimes hesitant to commit frequently, and attempt to use commands with a dirty working copy, for example. If you never record a state in git, git can't bring it back for you!

如果您对可恢复没事，但是难以通知尖刻，您可以使用

If you're okay with recoverable but hard-to-notice chicanery, you can do some evilness with git replace or graft points to fool git into operating on a fake history with merges or filter-branch operations. Replaced commits still count as reachable, though, so it won't be permanent damage.

这篇关于如何损坏Git存储库?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！