Setup and Config
Getting and Creating Projects
Basic Snapshotting
Branching and Merging
Sharing and Updating Projects
Inspection and Comparison
Patching
Debugging
External Systems
Server Admin
Guides
- gitattributes
- Command-line interface conventions
- Everyday Git
- Frequently Asked Questions (FAQ)
- Glossary
- Hooks
- gitignore
- gitmodules
- Revisions
- Submodules
- Tutorial
- Workflows
- All guides...
Administration
Plumbing Commands
- 2.47.1 no changes
- 2.47.0 10/06/24
- 2.43.1 → 2.46.2 no changes
- 2.43.0 11/20/23
- 2.42.1 → 2.42.3 no changes
- 2.42.0 08/21/23
- 2.41.1 → 2.41.2 no changes
- 2.41.0 06/01/23
- 2.38.1 → 2.40.3 no changes
- 2.38.0 10/02/22
- 2.37.1 → 2.37.7 no changes
- 2.37.0 06/27/22
- 2.31.1 → 2.36.6 no changes
- 2.31.0 03/15/21
- 2.30.1 → 2.30.9 no changes
- 2.30.0 12/27/20
- 2.24.1 → 2.29.3 no changes
- 2.24.0 11/04/19
- 2.22.1 → 2.23.4 no changes
- 2.22.0 06/07/19
- 2.21.1 → 2.21.4 no changes
- 2.21.0 02/24/19
- 2.20.1 → 2.20.5 no changes
- 2.20.0 12/09/18
- 2.19.1 → 2.19.6 no changes
- 2.19.0 09/10/18
- 2.18.1 → 2.18.5 no changes
- 2.18.0 06/21/18
- 2.13.7 → 2.17.6 no changes
- 2.12.5 09/22/17
- 2.11.4 09/22/17
- 2.10.5 no changes
- 2.9.5 07/30/17
- 2.7.6 → 2.8.6 no changes
- 2.6.7 05/05/17
- 2.5.6 no changes
- 2.4.12 05/05/17
- 2.1.4 → 2.3.10 no changes
- 2.0.5 12/17/14
概述
git gc [--aggressive] [--auto] [--[no-]detach] [--quiet] [--prune=<date> | --no-prune] [--force] [--keep-largest-pack]
描述
在当前版本库中执行一些内务管理任务,比如压缩文件修订(以减少磁盘空间并提高性能),移除之前调用 git add 所创建的不可达对象,打包引用,修剪引用日志、rerere metadata 或过时的工作区。也可以更新辅助索引,如提交图。
当运行创建对象的普通上层命令操作时,它们会检查仓库在上次维护后是否有大幅增长,如果有,就自动运行 git gc
。参见下面的 gc.auto
以了解如何禁用这一行为。
手动运行 git gc
应该只在向仓库添加对象而不定期运行这种上层命令时才需要,以进行一次性的仓库优化,或者例如清理次优的大规模导入。关于导入情况的更多细节,请参见 git-fast-import[1] 中的 “包装文件优化” 部分。
选项
- --aggressive
-
通常,git gc 运行得非常快,同时提供良好的磁盘空间利用率和性能。 这个选项会使 git gc 更积极地优化仓库,代价是花费更多的时间。 这种优化的效果大多是持续性的。详情见下面的 "AGGRESSIVE" 部分。
- --auto
-
有了这个选项,git gc 就会检查是否需要任何内务处理;如果不需要,它就会退出,不执行任何工作。
关于这个启发式的工作原理,请看下面 “配置” 部分的
gc.auto
选项。一旦超过配置选项如
gc.auto
和gc.autoPackLimit
的限制而触发内务管理,所有其他内务管理任务(如 reere、working trees、reflog…)也将被执行。 - --[no-]detach
-
Run in the background if the system supports it. This option overrides the
gc.autoDetach
config. - --[no-]cruft
-
当无法到达的对象过期时,将它们单独打包到一个 cruft 包中,而不是将它们作为散装对象存储。
--cruft
是默认开启的。 - --max-cruft-size=<n>
-
在将无法访问的对象打包到 Cruft 包时,限制新 Cruft 包的大小最多为
<n>
字节。覆盖通过gc.maxCruftSize
配置指定的任何值。参见 git-repack[1] 的 `--max-cruft-size`选项了解更多。 - --prune=<日期>
-
修剪超过日期的松散对象(默认是 2 周前,可由配置变量
gc.pruneExpire
覆盖)。 --prune=now 删减松散对象,无论其年龄大小,如果有其他进程同时向仓库写入,则会增加损坏的风险;见下面的 “注意事项”。--prune 默认是打开的。 - --no-prune
-
不要修剪任何松散的对象。
- --quiet
-
抑制所有进度报告。
- --force
-
强制
git gc
运行,即使这个仓库可能有另一个git gc
实例在运行。 - --keep-largest-pack
-
除了最大的非破坏性包,任何标有
.keep
文件的包,以及任何破坏性的包,都会被合并为一个包。当使用这个选项时,gc.bigPackThreshold
被忽略。
侵略的
当提供 --aggressive
选项时,git-repack[1] 将被调用,并带有 -f
标志,这又将把 --no-reuse-delta
传递给 git-pack-objects[1]。这将丢弃任何现有的 delta 并重新计算,代价是在重新打包上花费更多的时间。
这方面的影响主要是持久性的,例如,当包和松散对象被凝聚成另一个包时,该包中现有的 delta 可能会被重新使用,但也有各种情况,我们可能会从一个较新的包中挑选一个次优 delta。
此外,提供 --aggressive
将调整传递给 git-repack[1] 的 --depth
和 --window
选项。见下面的 gc.aggressiveDepth
和 gc.aggressiveWindow
设置。通过使用较大的窗口尺寸,我们更有可能找到更多的最佳 deltas。
在没有运行定制的性能基准的情况下,在一个给定的仓库上使用这个选项可能是不值得的。它需要更多的时间,而由此产生的空间/延迟优化可能值得也可能不值得。对于大多数用户和他们的仓库来说,完全不使用这个选项是正确的权衡。
配置
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
注释
git gc 非常努力地不删除在你的仓库中任何地方被引用的对象。特别是,它不仅会保留当前分支和标记集所引用的对象,还会保留索引、远程跟踪分支、 引用日志(可能引用了后来被修改或回绕的分支中的提交)以及 refs/* 名称空间中的任何其他对象。请注意,附在一个对象上的注释(由 git notes 创建的那种)并不有助于保持该对象的活力。如果你期待一些对象被删除,而它们没有被删除,请检查所有这些位置,并决定在你的情况下,删除这些引用是否有意义。
另一方面,当 git gc 与另一个进程同时运行时,它有可能删除另一个进程正在使用但还没有创建引用的对象。这可能会导致其他进程失败,或者如果其他进程后来添加了对被删除对象的引用,则可能会破坏仓库。Git 有两个功能可以大大缓解这个问题:
-
任何修改时间早于
--prune
日期的对象都会被保留,同时也会保留所有可以到达的对象。 -
大多数向数据库添加对象的操作都会更新对象的修改时间,如果它已经存在,那么 #1 就适用。
然而,这些功能并不是一个完整的解决方案,所以同时运行命令的用户不得不忍受一些损坏的风险(在实践中似乎很低)。
钩子
git gc --auto 命令将运行 pre-auto-gc 钩子。 更多信息请参见 githooks[5]。
GIT
属于 git[1] 文档