简体中文 ▾ 主题 ▾ 最新版本 ▾ git-gc 最后更新于 2.49.0

名称

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

概要

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

描述

在当前仓库中运行多项内务管理任务，例如压缩文件修订（以减少磁盘空间和提高性能）、移除可能由先前调用 git add 创建的不可达对象、打包引用、修剪引用日志、rerere 元数据或过时的裸工作目录。也可能更新辅助索引，如提交图。

当运行创建对象的常见“瓷器命令”（porcelain operations）时，它们会检查仓库自上次维护以来是否已大幅增长，如果是，则自动运行 git gc。有关如何禁用此行为，请参阅下面的 gc.auto。

手动运行 git gc 通常只在以下情况需要：在不定期运行此类“瓷器命令”的情况下向仓库添加对象，进行一次性仓库优化，或者例如清理次优的大量导入。有关导入情况的更多详细信息，请参阅 git-fast-import[1] 中的“PACKFILE OPTIMIZATION”部分。

选项

--aggressive

通常 git gc 运行速度非常快，同时提供良好的磁盘空间利用率和性能。此选项将使 git gc 更积极地优化仓库，代价是花费更多时间。此优化的效果大部分是持久的。有关详细信息，请参阅下面的“AGGRESSIVE”部分。

--auto

使用此选项，git gc 会检查是否需要任何内务管理；如果不需要，则退出而不执行任何工作。

有关此启发式方法的工作原理，请参阅下面“CONFIGURATION”部分中的 gc.auto 选项。

一旦内务管理因超出 gc.auto 和 gc.autoPackLimit 等配置选项的限制而触发，所有其他内务管理任务（例如 rerere、工作目录、引用日志…​）也将被执行。

--[no-]detach

如果系统支持，则在后台运行。此选项会覆盖 gc.autoDetach 配置。

--[no-]cruft

在过期不可达对象时，将它们单独打包成一个冗余包（cruft pack），而不是将它们存储为松散对象。--cruft 默认开启。

--max-cruft-size=<n>

将不可达对象打包到冗余包中时，限制新冗余包的大小最多为 <n> 字节。此选项会覆盖通过 gc.maxCruftSize 配置指定的任何值。有关更多信息，请参阅 git-repack[1] 的 --max-cruft-size 选项。

--expire-to=<dir>

将不可达对象打包到冗余包中时，将包含已修剪对象（如果有）的冗余包写入目录 <dir>。此选项仅在与 --cruft 一起使用时才有效。有关更多信息，请参阅 git-repack[1] 的 --expire-to 选项。

--prune=<date>

修剪早于指定日期的松散对象（默认为两周前，可通过配置变量 gc.pruneExpire 覆盖）。--prune=now 会修剪所有松散对象，无论其创建时间，如果另一个进程同时写入仓库，会增加损坏的风险；请参阅下面的“NOTES”。--prune 默认开启。

--no-prune

不修剪任何松散对象。

--quiet

禁止所有进度报告。

--force

即使此仓库上可能正在运行另一个 git gc 实例，也强制运行 git gc。

--keep-largest-pack

除了最大的非冗余包、任何带有 .keep 文件的包以及任何冗余包外，所有包都将合并为一个包。使用此选项时，gc.bigPackThreshold 将被忽略。

AGGRESSIVE

当提供 --aggressive 选项时，git-repack[1] 将被调用并带有 -f 标志，这反过来会将 --no-reuse-delta 传递给 git-pack-objects[1]。这将丢弃任何现有的增量并重新计算它们，代价是花费更多的时间进行重新打包。

这种效果大部分是持久的，例如当包和松散对象合并到另一个包中时，该包中现有的增量可能会被重用，但在各种情况下，我们也可能会从较新的包中选择一个次优的增量。

此外，提供 --aggressive 将调整传递给 git-repack[1] 的 --depth 和 --window 选项。请参阅下面的 gc.aggressiveDepth 和 gc.aggressiveWindow 设置。通过使用更大的窗口大小，我们更有可能找到更优的增量。

在给定仓库上不进行定制性能基准测试的情况下使用此选项可能不值得。它会花费大量时间，并且产生的空间/增量优化可能不值得。对于大多数用户及其仓库来说，根本不使用此选项是正确的权衡。

配置

本节中以下所有内容均从 git-config[1] 文档中选择性地包含。内容与彼处相同：

gc.aggressiveDepth

git gc --aggressive 使用的增量压缩算法中的深度参数。这默认为 50，这是不使用 --aggressive 时 --depth 选项的默认值。

有关更多详细信息，请参阅 git-repack[1] 中 --depth 选项的文档。

gc.aggressiveWindow

git gc --aggressive 使用的增量压缩算法中的窗口大小参数。这默认为 250，这是一个比默认 --window 10 更激进的窗口大小。

有关更多详细信息，请参阅 git-repack[1] 中 --window 选项的文档。

gc.auto

当仓库中的松散对象数量大约超过此值时，git gc --auto 将对其进行打包。一些“瓷器命令”会使用此命令不时执行轻量级垃圾回收。默认值为 6700。

将其设置为 0 不仅会禁用基于松散对象数量的自动打包，还会禁用 git gc --auto 否则会用来确定是否有工作要做的任何其他启发式方法，例如 gc.autoPackLimit。

gc.autoPackLimit

当仓库中未标记 *.keep 文件的包数量超过此值时，git gc --auto 会将它们合并为一个更大的包。默认值为 50。设置为 0 会禁用此功能。将 gc.auto 设置为 0 也会禁用此功能。

请参阅下面的 gc.bigPackThreshold 配置变量。使用时，它将影响自动包限制的工作方式。

gc.autoDetach

如果系统支持，则使 git gc --auto 立即返回并在后台运行。默认值为 true。此配置变量作为 maintenance.autoDetach 未设置时的备用选项。

gc.bigPackThreshold

如果非零，当运行 git gc 时，所有大于此限制的非冗余包都将被保留。这与 --keep-largest-pack 非常相似，只是所有符合阈值的非冗余包都会被保留，而不仅仅是最大的包。默认为零。支持常见的单位后缀 k、m 或 g。

请注意，如果保留的包数量超过 gc.autoPackLimit，此配置变量将被忽略，除了基本包之外的所有包都将被重新打包。在此之后，包的数量应低于 gc.autoPackLimit，并且 gc.bigPackThreshold 应该再次受到尊重。

如果运行 git repack 所需的估计内存不可用且未设置 gc.bigPackThreshold，则最大的包也将被排除（这相当于运行 git gc 时带有 --keep-largest-pack）。

gc.writeCommitGraph

如果为 true，则在运行 git-gc[1] 时 gc 将重写提交图文件。当使用 git gc --auto 时，如果需要内务管理，提交图将更新。默认值为 true。有关详细信息，请参阅 git-commit-graph[1]。

gc.logExpiry

如果文件 gc.log 存在，则 git gc --auto 将打印其内容并以状态零退出而不是运行，除非该文件早于 gc.logExpiry。默认值为 "1.day"。有关指定其值的更多方法，请参阅 gc.pruneExpire。

gc.packRefs

在仓库中运行 git pack-refs 会导致 Git 1.5.1.2 之前的版本无法通过 HTTP 等哑传输克隆。此变量决定 git gc 是否运行 git pack-refs。这可以设置为 notbare 以在所有非裸仓库中启用，也可以设置为布尔值。默认值为 true。

gc.cruftPacks

将不可达对象存储在冗余包中（参见 git-repack[1]），而不是作为松散对象存储。默认值为 true。

gc.maxCruftSize

重新打包时限制新冗余包的大小。当与 --max-cruft-size 一起指定时，命令行选项优先。请参阅 git-repack[1] 的 --max-cruft-size 选项。

gc.pruneExpire

当运行 git gc 时，它将调用 prune --expire 2.weeks.ago（如果通过 gc.cruftPacks 或 --cruft 使用冗余包，则调用 repack --cruft --cruft-expiration 2.weeks.ago）。使用此配置变量覆盖宽限期。“now”值可用于禁用此宽限期并始终立即修剪不可达对象，或“never”可用于抑制修剪。此功能有助于在 git gc 与另一个写入仓库的进程并发运行时防止损坏；请参阅 git-gc[1] 的“NOTES”部分。

gc.worktreePruneExpire

当运行 git gc 时，它会调用 git worktree prune --expire 3.months.ago。此配置变量可用于设置不同的宽限期。“now”值可用于禁用宽限期并立即修剪 $GIT_DIR/worktrees，或“never”可用于抑制修剪。

gc.reflogExpire
gc.<pattern>.reflogExpire

git reflog expire 会移除早于此时间的引用日志条目；默认为 90 天。“now”值会立即过期所有条目，“never”会完全抑制过期。在中间带有“<pattern>”（例如“refs/stash”）的设置仅适用于匹配该模式的引用。

gc.reflogExpireUnreachable
gc.<pattern>.reflogExpireUnreachable

git reflog expire 会移除早于此时间且无法从当前 HEAD 访问的引用日志条目；默认为 30 天。“now”值会立即过期所有条目，“never”会完全抑制过期。在中间带有“<pattern>”（例如“refs/stash”）的设置仅适用于匹配该模式的引用。

这些类型的条目通常是使用 git commit --amend 或 git rebase 产生的，并且是修改或变基发生之前的提交。由于这些更改不属于当前项目，大多数用户会希望更快地使其过期，这就是为什么默认值比 gc.reflogExpire 更激进的原因。

gc.recentObjectsHook

在考虑是否移除对象时（无论是生成冗余包还是将不可达对象存储为松散对象），使用 shell 执行指定的命令。将其输出解释为 Git 将视为“最新”的对象 ID，无论其创建时间如何。通过将其修改时间视为“现在”，输出中提及的任何对象（及其后代）都将保留，无论其真实创建时间如何。

输出必须每行包含一个十六进制对象 ID，不能包含其他任何内容。在仓库中找不到的对象将被忽略。支持多个钩子，但所有钩子都必须成功退出，否则操作（无论是生成冗余包还是解包不可达对象）将被中止。

gc.repackFilter

重新打包时，使用指定的过滤器将某些对象移动到单独的 packfile 中。请参阅 git-repack[1] 的 --filter=<filter-spec> 选项。

gc.repackFilterTo

重新打包并使用过滤器时，请参阅 gc.repackFilter，指定的位置将用于创建包含过滤掉的对象的 packfile。警告： 指定的位置应可访问，例如使用 Git 备用机制，否则仓库可能会被 Git 视为损坏，因为它可能无法访问该 packfile 中的对象。请参阅 git-repack[1] 的 --filter-to=<dir> 选项和 gitrepository-layout[5] 的 objects/info/alternates 部分。

gc.rerereResolved

当运行 git rerere gc 时，您之前解决的冲突合并记录将保留此天数。您也可以使用更具可读性的“1.month.ago”等。默认值为 60 天。请参阅 git-rerere[1]。

gc.rerereUnresolved

当运行 git rerere gc 时，您尚未解决的冲突合并记录将保留此天数。您也可以使用更具可读性的“1.month.ago”等。默认值为 15 天。请参阅 git-rerere[1]。

注意事项

git gc 会非常努力地不删除仓库中任何地方引用的对象。特别是，它不仅会保留您当前分支和标签集引用的对象，还会保留索引、远程跟踪分支、引用日志（可能引用稍后修改或回溯的分支中的提交）以及 refs/* 命名空间中的所有其他对象。请注意，附加到对象的注释（通过 git notes 创建的注释）不会有助于保持对象的存活。如果您期望某些对象被删除但它们没有，请检查所有这些位置并确定在您的情况下删除这些引用是否有意义。

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

  1. 任何修改时间比 --prune 日期新的对象都将被保留，以及从它可达的所有对象。

  2. 大多数向数据库添加对象的操作会在对象已存在时更新其修改时间，以便应用 #1。

然而，这些功能未能提供完整的解决方案，因此并发运行命令的用户必须承受一定的损坏风险（实践中这种风险似乎很低）。

钩子

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

另请参阅

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

GIT

Git[1] 套件的一部分

scroll-to-top