设置和配置
获取和创建项目
基本快照
分支和合并
共享和更新项目
检查和比较
打补丁
调试
电子邮件
外部系统
服务器管理
指南
管理
底层命令
-
2.49.0
2025-03-14
- 2.47.1 → 2.48.1 没有变化
-
2.47.0
2024-10-06
- 2.43.1 → 2.46.3 没有变化
-
2.43.0
2023-11-20
- 2.42.1 → 2.42.4 没有变化
-
2.42.0
2023-08-21
- 2.41.1 → 2.41.3 没有变化
-
2.41.0
2023-06-01
- 2.38.1 → 2.40.4 没有变化
-
2.38.0
2022-10-02
- 2.37.1 → 2.37.7 没有变化
-
2.37.0
2022-06-27
- 2.31.1 → 2.36.6 没有变化
-
2.31.0
2021-03-15
- 2.30.1 → 2.30.9 没有变化
-
2.30.0
2020-12-27
- 2.24.1 → 2.29.3 没有变化
-
2.24.0
2019-11-04
- 2.22.1 → 2.23.4 没有变化
-
2.22.0
2019-06-07
- 2.21.1 → 2.21.4 没有变化
-
2.21.0
2019-02-24
- 2.20.1 → 2.20.5 没有变化
-
2.20.0
2018-12-09
- 2.19.1 → 2.19.6 没有变化
-
2.19.0
2018-09-10
- 2.18.1 → 2.18.5 没有变化
-
2.18.0
2018-06-21
- 2.13.7 → 2.17.6 没有变化
-
2.12.5
2017-09-22
-
2.11.4
2017-09-22
- 2.10.5 没有变化
-
2.9.5
2017-07-30
- 2.7.6 → 2.8.6 没有变化
-
2.6.7
2017-05-05
- 2.5.6 没有变化
-
2.4.12
2017-05-05
- 2.1.4 → 2.3.10 没有变化
-
2.0.5
2014-12-17
概要
git gc [--aggressive] [--auto] [--[no-]detach] [--quiet] [--prune=<date> | --no-prune] [--force] [--keep-largest-pack]
描述
在当前存储库中运行多个内务处理任务，例如压缩文件修订（以减少磁盘空间并提高性能）、删除可能从先前调用 git add 创建的无法访问的对象、打包引用、修剪引用日志、rerere 元数据或陈旧的工作树。 还可以更新辅助索引，例如 commit-graph。
运行创建对象的常见瓷器操作时，它们将检查自上次维护以来存储库是否已大幅增长，如果是，则自动运行 git gc。 请参阅下面的 gc.auto，了解如何禁用此行为。
仅当在不定期运行此类瓷器命令的情况下向存储库添加对象、进行一次性存储库优化，或者清理次优的大规模导入时，才需要手动运行 git gc。 有关导入案例的更多详细信息，请参阅 git-fast-import[1] 中的“PACKFILE OPTIMIZATION”部分。
选项
- --aggressive
-
通常，git gc 运行速度非常快，同时提供良好的磁盘空间利用率和性能。 此选项将使 git gc 更积极地优化存储库，但会花费更多时间。 这种优化的效果主要是持久的。 有关详细信息，请参阅下面的“AGGRESSIVE”部分。
- --auto
-
使用此选项，git gc 检查是否需要任何内务处理； 如果不需要，它将在不执行任何工作的情况下退出。
有关此启发式方法如何工作的更多信息，请参阅下面“配置”部分中的
gc.auto选项。一旦内务处理因超过配置选项（如
gc.auto和gc.autoPackLimit）的限制而被触发，所有其他内务处理任务（例如，rerere、工作树、reflog…）也将被执行。 - --[no-]detach
-
如果系统支持，则在后台运行。 此选项会覆盖
gc.autoDetach配置。 - --[no-]cruft
-
在过期无法访问的对象时，将它们单独打包到 cruft 包中，而不是将它们存储为松散对象。 默认情况下，
--cruft处于启用状态。 - --max-cruft-size=<n>
-
将无法访问的对象打包到 cruft 包中时，将新 cruft 包的大小限制为最多
<n>字节。 覆盖通过gc.maxCruftSize配置指定的任何值。 有关更多信息，请参阅 git-repack[1] 的--max-cruft-size选项。 - --expire-to=<dir>
-
将无法访问的对象打包到 cruft 包中时，将包含修剪对象的 cruft 包（如果有）写入目录
<dir>。 只有将此选项与--cruft一起使用时，此选项才有效。 有关更多信息，请参阅 git-repack[1] 的--expire-to选项。 - --prune=<date>
-
修剪早于 date 的松散对象（默认为 2 周前，可通过配置变量
gc.pruneExpire覆盖）。 --prune=now 修剪松散对象，无论它们的年龄如何，并且会增加在另一个进程同时写入存储库时损坏的风险； 请参阅下面的“注释”。 默认情况下，--prune 处于启用状态。 - --no-prune
-
不修剪任何松散对象。
- --quiet
-
禁止显示所有进度报告。
- --force
-
强制
git gc运行，即使此存储库上可能正在运行另一个git gc实例。 - --keep-largest-pack
-
除了最大的非 cruft 包、标记有
.keep文件的任何包以及任何 cruft 包之外，所有包都合并到一个包中。 使用此选项时，将忽略gc.bigPackThreshold。
AGGRESSIVE
当提供 --aggressive 选项时，将使用 -f 标志调用 git-repack[1]，这将依次将 --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，这是一个比默认
--window10 更积极的窗口大小。有关更多详细信息，请参阅 git-repack[1] 中
--window选项的文档。 - gc.auto
-
当存储库中大约有超过此数量的松散对象时，
git gc --auto将打包它们。 一些 Porcelain 命令使用此命令不时执行轻量级垃圾收集。 默认值为 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时，将保留大于此限制的所有非 cruft 包。 这与--keep-largest-pack非常相似，只是保留了满足阈值的所有非 cruft 包，而不仅仅是最大的包。 默认为零。 支持 k、m 或 g 的常用单位后缀。请注意，如果保留的包数超过 gc.autoPackLimit，则会忽略此配置变量，除了基本包之外的所有包都将被重新打包。 在此之后，包的数量应低于 gc.autoPackLimit，并且应再次遵守 gc.bigPackThreshold。
如果没有足够的内存来顺利运行
git repack，并且未设置gc.bigPackThreshold，则还会排除最大的包（这等同于运行带有--keep-largest-pack的git gc）。 - gc.writeCommitGraph
-
如果为 true，则在运行 git-gc[1] 时，gc 将重写 commit-graph 文件。 当使用
git gc --auto时，如果需要内务处理，则将更新 commit-graph。 默认为 true。 有关详细信息，请参阅 git-commit-graph[1]。 - gc.logExpiry
-
如果存在文件
gc.log，那么git gc --auto将会打印它的内容并以状态码 0 退出，而不会实际运行，除非该文件比 gc.logExpiry 指定的时间更旧。默认值为 "1.day"。有关指定此值的更多方法，请参见gc.pruneExpire。 - gc.packRefs
-
在一个仓库中运行
git pack-refs会导致低于 1.5.1.2 版本的 Git 无法通过诸如 HTTP 等哑传输方式克隆该仓库。此变量决定 git gc 是否运行git pack-refs。可以将其设置为notbare以在所有非裸仓库中启用它，或者可以将其设置为布尔值。默认值为true。 - gc.cruftPacks
-
将无法访问的对象存储在 cruft pack 中（参见 git-repack[1]），而不是作为松散对象。默认值为
true。 - gc.maxCruftSize
-
限制重新打包时新 cruft pack 的大小。如果除了
--max-cruft-size之外还指定了此选项，则命令行选项优先。参见 git-repack[1] 的--max-cruft-size选项。 - gc.pruneExpire
-
当运行 git gc 时，它将调用 prune --expire 2.weeks.ago（如果通过
gc.cruftPacks或--cruft使用 cruft pack，则会调用 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 移除早于此时刻的 reflog 条目；默认为 90 天。值 "now" 会立即过期所有条目，而 "never" 则完全禁止过期。如果在中间使用 "<pattern>"（例如 "refs/stash"），则该设置仅适用于与 <pattern> 匹配的 refs。
- gc.reflogExpireUnreachable
- gc.<pattern>.reflogExpireUnreachable
-
git reflog expire 移除早于此时刻且无法从当前 tip 访问的 reflog 条目；默认为 30 天。值 "now" 会立即过期所有条目，而 "never" 则完全禁止过期。如果在中间使用 "<pattern>"（例如 "refs/stash"），则该设置仅适用于与 <pattern> 匹配的 refs。
这些类型的条目通常在使用
git commit --amend或git rebase时创建，并且是发生在 amend 或 rebase 之前的提交。由于这些更改不是当前项目的一部分，因此大多数用户希望更快地使其过期，这就是默认值比gc.reflogExpire更激进的原因。 - gc.recentObjectsHook
-
在考虑是否删除对象时（无论是在生成 cruft pack 还是将无法访问的对象存储为松散对象），使用 shell 执行指定的命令。将其输出解释为对象 ID，Git 会将其视为“最近”的对象，而无论其年龄如何。通过将其 mtime 视为“现在”，输出中提到的任何对象（及其后代）都将被保留，而无论其真实年龄如何。
输出必须每行包含一个十六进制对象 ID，并且不包含其他内容。找不到在仓库中的对象将被忽略。支持多个 hook，但所有 hook 必须成功退出，否则操作（无论是生成 cruft pack 还是解压无法访问的对象）将会停止。
- gc.repackFilter
-
重新打包时，使用指定的过滤器将某些对象移动到单独的 packfile 中。参见 git-repack[1] 的
--filter=<filter-spec>选项。 - gc.repackFilterTo
-
重新打包并使用过滤器时（参见
gc.repackFilter），指定的 location 将用于创建包含过滤掉的对象的 packfile。警告：指定的 location 应该是可访问的，例如使用 Git alternates 机制，否则仓库可能会被 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]。
NOTES
git gc 会尽力不删除仓库中任何位置引用的对象。特别是，它不仅会保留当前分支和标签集引用的对象，还会保留索引、远程跟踪分支、reflog（可能引用后来被修改或回滚的分支中的提交）以及 refs/* 命名空间中的任何其他内容引用的对象。请注意，附加到对象的注释（由 git notes 创建）无助于保持对象的存活。如果您期望删除某些对象但它们没有被删除，请检查所有这些位置，并确定在这种情况下删除这些引用是否有意义。
另一方面，当 git gc 与另一个进程同时运行时，存在删除另一个进程正在使用但尚未创建引用的对象的风险。这可能只是导致另一个进程失败，或者如果另一个进程稍后添加对已删除对象的引用，则可能损坏仓库。Git 有两个功能可以显著减轻此问题
-
任何修改时间比
--prune日期新的对象，以及可以从该对象访问的所有内容，都会被保留。 -
大多数将对象添加到数据库的操作都会更新对象的修改时间（如果该对象已经存在），以便应用 #1。
但是，这些功能无法提供完整的解决方案，因此并发运行命令的用户必须承担一些损坏风险（实际上这种风险似乎很低）。
HOOKS
git gc --auto 命令将运行 pre-auto-gc hook。有关更多信息，请参见 githooks[5]。
GIT
属于 git[1] 套件的一部分
