如何修复损坏的git存储库？

Question

我将克隆回购文件（我将其在ubuntu上的一个文件夹）绑定到一台新机器上，我得到了：

christopher@christopher-laptop:~/source/personal$ git clone ~/Ubuntu\ One\ Side\ Work/projects.git/

Cloning into 'projects'...

done.

fatal: unable to read tree 29a422c19251aeaeb907175e9b3219a9bed6c616

christopher@christopher-laptop:~/source/personal$ 

因此，我尝试查看此处提出的其他许多类似问题，其中大多数都说要运行git fsck --full，然后在尝试时得到。

christopher@christopher-laptop:~/Ubuntu One Side Work/projects.git$ git fsck --full

Checking object directories: 100% (256/256), done.

Checking objects: 100% (447/447), done.

broken link from  commit 235ae1f48701d577d71ebd430344a159e5ba4881

              to  commit 984c11abfc9c2839b386f29c574d9e03383fa589

broken link from    tree 632a9cf0ef9fccea08438b574e2f1c954f4ff08b

              to    blob 25a742dff0a403b2b3884f2ffddf63eb45721fac

broken link from    tree 632a9cf0ef9fccea08438b574e2f1c954f4ff08b

              to    blob dd4e97e22e159a585b20e21028f964827d5afa4e

broken link from    tree 632a9cf0ef9fccea08438b574e2f1c954f4ff08b

              to    tree 29a422c19251aeaeb907175e9b3219a9bed6c616

broken link from    tree 632a9cf0ef9fccea08438b574e2f1c954f4ff08b

              to    tree 8084e8e04d510cc28321f30a9646477cc50c235c

broken link from    tree 774b5b4157b4caae1c6cad96c8eaf5d4eba2c628

              to    blob a0daa0c1567b55d8de2b4d7a3bc010f58c047eab

broken link from    tree 774b5b4157b4caae1c6cad96c8eaf5d4eba2c628

              to    blob e9052d35bfb6d30065b206fc43f4200a04d5281b

broken link from    tree 774b5b4157b4caae1c6cad96c8eaf5d4eba2c628

              to    blob 1a3a5e4dd2502ac121c22f743c4250e254a94eeb

broken link from    tree 4aa336dc1a5838e8918e03b85580069d83f4ad09

              to    tree 8cc55ec952dc192a233e062201d1e7e873ac3db0

broken link from    tree e5674a91a53e15575a1f3bf5786bc5cc719fb483

Answer 1

Git并没有真正按照您的想法存储历史记录。它基于祖先链在运行时计算历史记录。如果您的祖先缺少斑点，树木或提交，那么您可能无法完全恢复历史记录。从备份还原丢失的对象您可以尝试的第一件事是从备份中还原丢失的项目。例如，查看是否有保存为的提交备份.git/objects/98/4c11abfc9c2839b386f29c574d9e03383fa589。如果是这样，您可以将其还原。如果提交已经被打包，并且为了存储库手术的目的将其返回到一个松散的对象，您可能还想研究git-verify-pack和git-unpack-objects。手术切除如果您无法从备份中替换丢失的项目，则可以删除丢失的历史记录。例如，您可以检查历史记录或reflog来查找984c11abfc9c2839b386f29c574d9e03383fa589的祖先。如果发现一个完好无损，则：将您的Git工作目录复制到某个地方的临时目录中。对未损坏的提交进行硬重置。将当前文件复制回Git工作树，但请确保不要将.git文件夹复制回去！提交当前的工作树，并尽最大努力将其视为所有丢失的历史记录的压缩提交。如果有效，您当然会失去介入的历史。在这一点上，如果您有可用的历史记录日志，那么最好修剪一下历史记录并重新引用所有无法到达的提交和对象。完全还原和重新初始化如果您的存储库仍然损坏，那么希望您有一个未损坏的备份或克隆，可以从中还原。如果不是，但是您当前的工作目录包含有效文件，那么您始终可以重新初始化Git。例如：rm -rf .gitgit initgit add .git commit -m 'Re-initialize repository without old history.'这太剧烈了，但是如果您的存储库历史记录确实不可恢复，那么这可能是您唯一的选择。YMMV。

Answer 2

在尝试本页上描述的任何修补程序之前，我建议您制作一份您的仓库，仅在此副本上进行操作。然后，如果可以修复，最后将其与原始文件进行比较，以确保在修复过程中不会丢失任何文件。对我有用的另一个替代方法是使用以下命令将git head和index重置为其以前的状态：git reset --keep您也可以通过打开Git GUI并选择每个“分段的更改”，然后单击“取消分段”来手动执行相同的操作。一切就绪后，您现在应该可以压缩数据库，检查数据库并提交。我还尝试了以下命令，但它们对我不起作用，但它们可能对您有用，具体取决于您遇到的问题：git reset --mixedgit fsck --fullgit gc --autogit prune --expire nowgit reflog --all最后，为避免此同步问题损坏您的git索引（DropBox，SpiderOak或任何其他云磁盘可能会发生这种情况），您可以执行以下操作：.git通过使用：将文件夹转换为单个“捆绑” git文件git bundle create my_repo.git --all，则它应该与以前一样工作，但是由于所有内容都在单个文件中，因此您再也不必担心同步会损坏git repo。禁用瞬时同步：SpiderOak允许您将检查更改的时间表设置为“自动”（这意味着它可以尽快通过OS通知来监视文件更改）。这很糟糕，因为它会在您进行更改后立即开始上传更改，然后下载更改，因此它可能会删除您刚才所做的最新更改。解决此问题的解决方案是将更改监视延迟设置为5分钟或更长时间。这也解决了即时保存笔记应用程序（例如Notepad ++）的问题。