git-gc

原文: https://git-scm.com/docs/git-gc

名称

git-gc - 清理不必要的文件并优化本地存储库

概要

git gc [--aggressive] [--auto] [--quiet] [--prune=<date> | --no-prune] [--force] [--keep-largest-pack]

描述

在当前存储库中运行许多内务处理任务,例如压缩文件修订版(以减少磁盘空间并提高性能),删除可能从之前调用 git add 创建的无法访问的对象,打包引用,修剪reflog,rerere元数据或陈旧的工作树。也可以更新提交图等辅助索引。

建议用户定期在每个存储库中运行此任务,以保持良好的磁盘空间利用率和良好的运行性能。

一些git命令可以自动运行 git gc ;有关详细信息,请参见下面的--auto标志。如果您知道自己在做什么,并且您想要的是永久禁用此行为而无需进一步考虑,只需执行以下操作:

$ git config --global gc.auto 0

OPTIONS

 --aggressive 

通常 git gc 运行速度非常快,同时提供良好的磁盘空间利用率和性能。此选项将导致 git gc 更积极地优化存储库,但代价是花费更多时间。这种优化的效果是持久的,所以这个选项只需要偶尔使用;每几百个变更集左右。

 --auto 

使用此选项, git gc 检查是否需要任何内务处理;如果没有,它退出而不执行任何工作。执行可能会创建许多松散对象的操作后,某些git命令会运行git gc --auto。如果存储库中有太多松散的对象或太多的包,则需要内务处理。

如果松散对象的数量超过gc.auto配置变量的值,则使用git repack -d -l将所有松散对象合并为单个包。将gc.auto的值设置为0将禁用松散物体的自动包装。

如果包数超过gc.autoPackLimit的值,则使用-A选项将现有包(标有.keep文件或超过gc.bigPackThreshold限制的包除外)合并为单个包中git repack 。如果估计内存量不足以使git repack平稳运行并且未设置gc.bigPackThreshold,则也将排除最大包(这相当于使用--keep-base-pack运行git gc)。将gc.autoPackLimit设置为0将禁用包的自动合并。

如果由于许多松散的物体或包装而需要进行保养,则还将执行所有其他内务处理任务(例如,rerere,工作树,reflog ……)。

 --prune=<date> 

修剪早于日期的松散对象(默认为2周前,可由配置变量gc.pruneExpire覆盖)。 –prune =所有修剪松散的对象,无论其年龄如何,如果另一个进程同时写入存储库,则会增加损坏的风险;请参阅下面的“注意”。 –prune默认开启。

 --no-prune 

不要修剪任何松散的物体。

 --quiet 

取消所有进度报告。

 --force 

即使可能在此存储库上运行另一个git gc实例,也强制git gc运行。

 --keep-largest-pack 

除最大包装外的所有包装和标有.keep文件的包装都合并为一个包装。使用此选项时,将忽略gc.bigPackThreshold

组态

可以设置可选配置变量gc.reflogExpire以指示每个分支的reflog中的历史条目在此存储库中保持可用的时间。该设置表示为时间长度,例如 _90天_或 _3个月_。默认为 _90天_。

可以设置可选配置变量gc.reflogExpireUnreachable以指示不属于当前分支的历史reflog条目在此存储库中保持可用的时间长度。这些类型的条目通常是使用git commit --amendgit rebase的结果创建的,并且是修改或重组发生之前的提交。由于这些更改不是当前项目的一部分,因此大多数用户希望尽快使其过期。此选项默认为 _30天_。

上述两个配置变量可以赋予模式。例如,这仅将非默认到期值设置为远程跟踪分支:

[gc "refs/remotes/*"]
	reflogExpire = never
	reflogExpireUnreachable = 3 days

可选配置变量gc.rerereResolved表示您保留先前解决的冲突合并记录的时间长度。默认为60天。

可选配置变量gc.rerereUnresolved表示保留未解决的冲突合并记录的时间长度。默认为15天。

可选配置变量gc.packRefs确定 git gc 是否运行 git pack-refs 。这可以设置为“notbare”以在所有非裸存储库中启用它,或者可以将其设置为布尔值。默认为true。

可选配置变量gc.writeCommitGraph确定 git gc 是否应该运行 git commit-graph write 。这可以设置为布尔值。默认为false。

可选配置变量gc.aggressiveWindow控制在指定-aggressive选项时优化存储库中对象的增量压缩所花费的时间。值越大,优化增量压缩所花费的时间就越多。有关详细信息,请参阅 git-repack [1] 中–window选项的文档。默认为250。

类似地,可选配置变量gc.aggressiveDepth控制 git-repack [1] 中的–depth选项。默认为50。

可选配置变量gc.pruneExpire控制未被引用的松散对象在被修剪之前必须有多长。默认为“2周前”。

可选配置变量gc.worktreePruneExpire控制在git worktree prune删除之前过时工作树的年龄。默认为“3个月前”。

笔记

git gc 非常努力地不删除存储库中任何位置引用的对象。特别是,它不仅会保留当前分支和标记集引用的对象,还会保留由 git filter-branch 在refs / original /中保存的索引,远程跟踪分支,引用引用的对象。或者reflogs(可以引用稍后修改或重绕的分支中的提交)。如果您希望某些对象被删除而它们不是,请检查所有这些位置,并确定在您的情况下删除这些引用是否有意义。

另一方面,当 git gc 与另一个进程同时运行时,存在删除另一个进程正在使用但尚未创建引用的对象的风险。如果其他进程稍后添加对已删除对象的引用,则这可能只会导致其他进程失败或可能损坏存储库。 Git有两个功能可以显着缓解这个问题:

  1. 修改时间比--prune日期更新的任何对象以及从中可以访问的所有对象。

  2. 将对象添加到数据库的大多数操作都会更新对象的修改时间(如果已存在),以便应用#1。

但是,这些功能缺乏完整的解决方案,因此同时运行命令的用户必须承受一定的腐败风险(实际上似乎很低),除非他们用 git config gc.auto关闭自动垃圾收集。 0

挂钩

git gc –auto 命令将运行 pre-auto-gc 挂钩。有关更多信息,请参阅 githooks [5]

也可以看看

git-prune [1] git-reflog [1] git-repack [1] git-rerere [1]

GIT

部分 git [1] 套件