10.7 维护及数据恢复.pdf

10.7 维护与数据恢复 维护与数据恢复 有的时候，你需要对仓库进⾏清理 - 使它的结构变得更紧凑，或是对导⼊的仓库进⾏ 清理，或是恢复丢 的内容。 这个⼩节将会介绍这些情况中的⼀部分。 维护 Git 会不定时地⾃动运⾏⼀个叫做 “auto gc” 的命令。 ⼤多数时候，这个命令并不会产 ⽣效果。 然⽽，如果有太多松散对象 （不在包⽂件中的对象）或者太多包⽂件，Git 会运⾏⼀个完整的 git gc 命令。 “gc” 代表垃圾回收，这个命令会做以下事情：收 集所有松散对象并将它们放置到包⽂件中，将多个包⽂件合并为⼀个⼤的包⽂件，移 除与任何提交都不相关的陈旧对象。 可以像下⾯⼀样⼿动执⾏⾃动垃圾回收： $ git gc --auto 就像上⾯提到的，这个命令通常并不会产⽣效果。 ⼤约需要 7000 个以上的松散对象 或超过 50 个的包⽂件才能让 Git 启动⼀次真正的 gc 命令。 你可以通过修 改 gc.auto 与gc.autopacklimit 的设置来改动这些数值。 gc 将会做的另⼀件事是打包你的引⽤到⼀个单独的⽂件。 假设你的仓库包含以下分 ⽀与标签： $ find .git/refs -type f .git/refs/heads/experiment .git/refs/heads/master .git/refs/tags/v1.0 .git/refs/tags/v1.1 如果你执⾏了 git gc 命令，refs ⽬录中将不会再有这些⽂件。 为了保证效率 Git 会将它们移动到名为 .git/packed-refs 的⽂件中，就像这样： $ cat .git/packed-refs # pack-refs with: peeled fully-peeled cac0ca 538 970a37ea1e769c de608743 c96d refs/heads/experiment a 1afef80fac8e34258ff41fc1 867c702daa24 refs/heads/master cac0ca 538 970a37ea1e769c de608743 c96d refs/tags/v1.0 9585191f37f7 0f 9444f35a9 f50de191 eadc2 refs/tags/v1.1 ^1a410ef d13591d c7a059dd55cfe9 如果你更新了引⽤，Git 并不会修改这个⽂件，⽽是向 refs/heads 创建⼀个新的⽂ 件。 为了获得指定引⽤的正确 SHA-1 值，Git 会⾸先在 refs ⽬录中查找指定的引 ⽤，然后再到 packed-refs ⽂件中查找。 所以，如果你在 refs ⽬录中找不到⼀个 引⽤，那么它或许在 packed-refs ⽂件中。 注意这个⽂件的最后⼀⾏，它会以 ^ 开头。 这个符号表⽰它上⼀⾏的标签是附注标 签，那⼀⾏是附注标签指向的那个提交。 数据恢复 在你使⽤ Git 的时候，你可能会意外丢 ⼀次提交。 通常这是因为你强制删除了正在 ⼯作的分⽀，但是最后却发现你还需要这个分⽀；亦或者硬重置了⼀个分⽀，放弃了 你想要的提交。 如果这些事情已经发⽣，该如何找回你的提交呢？ 下⾯的例⼦将硬重置你的测试仓库中的 master 分⽀到⼀个旧的提交，以此来恢复丢 的提交。 ⾸先，让我们看看你的仓库现在在什么地⽅： $ git log --pretty=oneline a 1afef80fac8e34258ff41fc1 867c702daa24 modified repo a it 484a59275031909e19aad 7fcdf19a added repo.r 1a410ef d13591d c7a059dd55cfe9 third commit cac0ca 538 970a37ea1e769c de608743 c96d second commit fdf4fc3344e67a 068f836878 6c4951e3 15f3d first commit 现在，我们将 master 分⽀硬重置到第三次提交： $ git reset --hard 1a410ef d13591d c7a059dd55cfe9 HEAD is now at 1a410ef third commit $ git log --pretty=oneline 1a410ef d135