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/ heads/ experiment
ab1afef80fac8e34258ff41fc1b867c702daa24b refs/ heads/ master
cac0cab538b970a37ea1e769cbbde608743bc96d refs/ tags/ v1. 0
9585191f 37f 7 b0fb9444f35a9bf50de191beadc2 refs/ tags/ v1. 1
^ 1 a410efbd13591db07496601ebc7a059dd55cfe9
如果更新了引用，Git 并不会修改这个文件，而是向 refs/heads 创建一个新的文件，为了获得指定引用的正确 SHA-1 值，Git 会首先在 refs 目录中查找指定的引用，然后再到 packed-refs 文件中查找。所以，如果在 refs 目录中找不到一个引用，那么它或许在 packed-refs 文件中。 注意：这个文件的最后一行，它会以 ^ 开头，这个符号表示它上一行的标签是附注标签，^ 所在的那一行是附注标签指向的那个提交。 在使用 Git 的时候，可能会出现意外丢失一次提交的情况，通常这是因为强制删除了正在工作的分支，但是最后却发现还需要这个分支，亦或者硬重置了一个分支，放弃了想要的提交，如果这些事情已经发生，该如何找回相应的提交呢？ 如下所示，将硬重置测试仓库中的 master 分支到一个旧的提交，以此来恢复丢失的提交。首先，来看看仓库现在在什么地方： $ git log -- pretty= oneline
ab1afef80fac8e34258ff41fc1b867c702daa24b modified repo a bit
484 a59275031909e19aadb7c92262719cfcdf19a added repo. rb
1 a410efbd13591db07496601ebc7a059dd55cfe9 third commit
cac0cab538b970a37ea1e769cbbde608743bc96d second commit
fdf4fc3344e67ab068f836878b6c4951e3b15f3d first commit
$ git reset -- hard 1 a410efbd13591db07496601ebc7a059dd55cfe9
HEAD is now at 1 a410ef third commit
$ git log -- pretty= oneline
1 a410efbd13591db07496601ebc7a059dd55cfe9 third commit
cac0cab538b970a37ea1e769cbbde608743bc96d second commit
fdf4fc3344e67ab068f836878b6c4951e3b15f3d first commit
现在顶部的两个提交已经丢失了，没有分支指向这些提交，需要找出最后一次提交的 SHA-1 然后增加一个指向它的分支，窍门就是找到最后一次的提交的 SHA-1，但是如果记不起来了，怎么办呢？ 最方便，也是最常用的方法，是使用一个名叫 git reflog 的工具，当正在工作时，Git 会默默地记录每一次改变 HEAD 时它的值，每一次提交或改变分支，引用日志都会被更新，引用日志（reflog）也可以通过 git update-ref 命令更新，我们在 Git 引用 有提到使用这个命令而不是是直接将 SHA-1 的值写入引用文件中的原因，可以在任何时候通过执行 git reflog 命令来了解曾经做过什么： $ git reflog
1 a410ef HEAD@{ 0 } : reset: moving to 1 a410ef
ab1afef HEAD@{ 1 } : commit: modified repo. rb a bit
484 a592 HEAD@{ 2 } : commit: added repo. rb
这里可以看到我们已经检出的两次提交，然而并没有足够多的信息，为了使显示的信息更加有用，可以执行 git log -g，这个命令会以标准日志的格式输出引用日志： $ git log - g
commit 1 a410efbd13591db07496601ebc7a059dd55cfe9
Reflog: HEAD@{ 0 } ( Scott Chacon < schacon@gmail. com> )
Reflog message: updating HEAD
Author: Scott Chacon < schacon@gmail. com>
Date: Fri May 22 18 : 22 : 37 2009 - 0700
third commit
commit ab1afef80fac8e34258ff41fc1b867c702daa24b
Reflog: HEAD@{ 1 } ( Scott Chacon < schacon@gmail. com> )
Reflog message: updating HEAD
Author: Scott Chacon < schacon@gmail. com>
Date: Fri May 22 18 : 15 : 24 2009 - 0700
modified repo. rb a bit
看起来下面的那个就是丢失的提交，可以通过创建一个新的分支指向这个提交来恢复它。例如，可以创建一个名为 recover-branch 的分支指向这个提交（ab1afef）： $ git branch recover- branch ab1afef
$ git log -- pretty= oneline recover- branch
ab1afef80fac8e34258ff41fc1b867c702daa24b modified repo a bit
484 a59275031909e19aadb7c92262719cfcdf19a added repo. rb
1 a410efbd13591db07496601ebc7a059dd55cfe9 third commit
cac0cab538b970a37ea1e769cbbde608743bc96d second commit
fdf4fc3344e67ab068f836878b6c4951e3b15f3d first commit
不错，现在有一个名为 recover-branch 的分支是 master 分支曾经指向的地方，再一次使得前两次提交可到达了。接下来，假设丢失的提交因为某些原因不在引用日志中，那么我们可以通过移除 recover-branch 分支并删除引用日志来模拟这种情况，现在前两次提交又不被任何分支指向了： $ git branch - D recover- branch
$ rm - Rf . git/ logs/
由于引用日志数据存放在 .git/logs/ 目录中，现在已经没有引用日志了，这时该如何恢复那次提交？ 一种方式是使用 git fsck 实用工具，将会检查数据库的完整性，如果使用一个 --full 选项运行它，它会显示出所有没有被其他对象指向的对象： $ git fsck -- full
Checking object directories: 100 % ( 256 / 256 ) , done.
Checking objects: 100 % ( 18 / 18 ) , done.
dangling blob d670460b4b4aece5915caf5c68d12f560a9fe3e4
dangling commit ab1afef80fac8e34258ff41fc1b867c702daa24b
dangling tree aea790b9a58f6cf6f2804eeac9f0abbe9631e4c9
dangling blob 7108f 7 ecb345ee9d0084193f147cdad4d2998293
本例中，可以在 “dangling commit” 后看到丢失的提交，现在可以用和之前相同的方法恢复这个提交，也就是添加一个指向这个提交的分支。 Git 有很多很棒的功能，但是其中一个特性会导致问题，git clone 会下载整个项目的历史，包括每一个文件的每一个版本。如果所有的东西都是源代码那么这很好，因为 Git 被高度优化来有效地存储这种数据。然而，如果某个人在之前向项目添加了一个大小特别大的文件，即使将这个文件从项目中移除了，每次克隆还是都要强制的下载这个大文件，之所以会产生这个问题，是因为这个文件在历史中是存在的，它会永远在那里。 当迁移 Subversion 或 Perforce 仓库到 Git 的时候，这会是一个严重的问题，因为这些版本控制系统并不下载所有的历史文件，所以这种文件所带来的问题比较少。如果从其他的版本控制系统迁移到 Git 时发现仓库比预期的大得多，那么就需要找到并移除这些大文件。 警告：这个操作对提交历史的修改是破坏性的，它会从必须修改或移除一个大文件引用最早的树对象开始重写每一次提交，如果在导入仓库后，在任何人开始基于这些提交工作前执行这个操作，那么将不会有任何问题。否则， 必须通知所有的贡献者他们需要将他们的成果变基到新提交上。 为了演示，将添加一个大文件到测试仓库中，并在下一次提交中删除它，现在我们需要找到它，并将它从仓库中永久删除。首先，添加一个大文件到仓库中： $ curl https:
$ git add git. tgz
$ git commit - m 'add git tarball'
[ master 7 b30847] add git tarball
1 file changed, 0 insertions ( + ) , 0 deletions ( - )
create mode 100644 git. tgz
其实这个项目并不需要这个巨大的压缩文件，现在将它移除： $ git rm git. tgz
rm 'git.tgz'
$ git commit - m 'oops - removed large tarball'
[ master dadf725] oops - removed large tarball
1 file changed, 0 insertions ( + ) , 0 deletions ( - )
delete mode 100644 git. tgz
$ git gc
Counting objects: 17 , done.
Delta compression using up to 8 threads.
Compressing objects: 100 % ( 13 / 13 ) , done.
Writing objects: 100 % ( 17 / 17 ) , done.
Total 17 ( delta 1 ) , reused 10 ( delta 0 )
也可以执行 count-objects 命令来快速的查看占用空间大小： $ git count- objects - v
count: 7
size: 32
in- pack: 17
packs: 1
size- pack: 4868
prune- packable: 0
garbage: 0
size- garbage: 0
size-pack 的数值指的是包文件以 KB 为单位计算的大小，所以大约占用了 5MB 的空间。在最后一次提交前，使用了不到 2KB，显然，从之前的提交中移除文件并不能从历史中移除它。每一次有人克隆这个仓库时，他们将必须克隆所有的 5MB 来获得这个微型项目，只因为意外地添加了一个大文件，现在来彻底的移除这个文件。 首先必须找到它，在本例中，已经知道是哪个文件了，但是如果不知道，该如何找出哪个文件或哪些文件占用了如此多的空间？ 如果执行 git gc 命令，所有的对象将被放入一个包文件中，可以通过运行 git verify-pack 命令，然后对输出内容的第三列（即文件大小）进行排序，从而找出这个大文件，也可以将这个命令的执行结果通过管道传送给 tail 命令，因为只需要找到列在最后的几个大对象：
$ git verify- pack - v . git/ objects/ pack/ pack- 29 …69. idx \
| sort - k 3 - n \
| tail - 3
dadf7258d699da2c8d89b09ef6670edb7d5f91b4 commit 229 159 12
033 b4468fa6b2a9547a70d88d1bbe8bf3f9ed0d5 blob 22044 5792 4977696
82 c99a3e86bb1267b236a4b6eff7868d97489af1 blob 4975916 4976258 1438
可以看到这个大对象出现在返回结果的最底部占用 5MB 空间。为了找出具体是哪个文件，可以使用 rev-list 命令，如果传递 --objects 参数给 rev-list 命令，它就会列出所有提交的 SHA-1、数据对象的 SHA-1 和与它们相关联的文件路径。可以使用以下命令来找出数据对象的名字： $ git rev- list -- objects -- all | grep 82 c99a3
82 c99a3e86bb1267b236a4b6eff7868d97489af1 git. tgz
现在，只需要从过去所有的树中移除这个文件。使用以下命令可以轻松地查看哪些提交对这个文件产生改动： $ git log -- oneline -- branches -- git. tgz
dadf725 oops - removed large tarball
7 b30847 add git tarball
必须重写 7b30847 提交之后的所有提交来从 Git 历史中完全移除这个文件。为了执行这个操作，要使用 filter-branch 命令： $ git filter- branch -- index- filter \
'git rm --ignore-unmatch --cached git.tgz' -- 7 b30847^ . .
Rewrite 7 b30847d080183a1ab7d18fb202473b3096e9f34 ( 1 / 2 ) rm 'git.tgz'
Rewrite dadf7258d699da2c8d89b09ef6670edb7d5f91b4 ( 2 / 2 )
Ref 'refs/heads/master' was rewritten
–index-filter 选项类似于在Git之深入解析如何重写提交历史 中提到的的 --tree-filter 选项，不过这个选项并不会让命令将修改在硬盘上检出的文件，而只是修改在暂存区或索引中的文件。 必须使用 git rm --cached 命令来移除文件，而不是通过类似 rm file 的命令，因为需要从索引中移除它，而不是磁盘中。还有一个原因是速度，Git 在运行过滤器时，并不会检出每个修订版本到磁盘中，所以这个过程会非常快。如果愿意的话，也可以通过 --tree-filter 选项来完成同样的任务，git rm 命令的 --ignore-unmatch 选项告诉命令：如果尝试删除的模式不存在时，不提示错误。最后，使用 filter-branch 选项来重写自 7b30847 提交以来的历史，也就是这个问题产生的地方。否则，这个命令会从最旧的提交开始，这将会花费许多不必要的时间。 历史中将不再包含对那个文件的引用，不过，引用日志和你在 .git/refs/original 通过 filter-branch 选项添加的新引用中还存有对这个文件的引用，所以必须移除它们然后重新打包数据库。在重新打包前需要移除任何包含指向那些旧提交的指针的文件： $ rm - Rf . git/ refs/ original
$ rm - Rf . git/ logs/
$ git gc
Counting objects: 15 , done.
Delta compression using up to 8 threads.
Compressing objects: 100 % ( 11 / 11 ) , done.
Writing objects: 100 % ( 15 / 15 ) , done.
Total 15 ( delta 1 ) , reused 12 ( delta 0 )
$ git count- objects - v
count: 11
size: 4904
in- pack: 15
packs: 1
size- pack: 8
prune- packable: 0
garbage: 0
size- garbage: 0
打包的仓库大小下降到了 8K，比 5MB 好很多，可以从 size 的值看出，这个大文件还在松散对象中，并没有消失；但是它不会在推送或接下来的克隆中出现，这才是最重要的。如果真的想要删除它，可以通过有 --expire 选项的 git prune 命令来完全地移除那个对象： $ git prune -- expire now
$ git count- objects - v
count: 0
size: 0
in- pack: 15
packs: 1
size- pack: 8
prune- packable: 0
garbage: 0
size- garbage: 0
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
