Git 中文参考（六）（7）https://developer.aliyun.com/article/1565808
OPTIONS
-d
除了未跟踪的文件之外，删除未跟踪的目录。如果未跟踪的目录由不同的 Git 存储库管理，则默认情况下不会删除它。如果您确实要删除此类目录，请使用-f 选项两次。
-f
--force
如果 Git 配置变量 clean.requireForce 未设置为 false， git clean 将拒绝删除文件或目录，除非给出-f，-n 或-i。除非给出第二个-f，否则 Git 将拒绝使用.git 子目录或文件删除目录。
-i
--interactive
显示将要执行的操作并以交互方式清理文件。有关详细信息，请参阅“交互模式”
-n
--dry-run
不要删除任何东西，只显示将要做的事情。
-q
--quiet
保持安静，仅报告错误，但不报告成功删除的文件。
-e <pattern>
--exclude=<pattern>
除了在.gitignore（每个目录）和$ GIT_DIR / info / exclude 中找到的那些之外，还要考虑这些模式在有效的忽略规则集中。
-x
不要使用从.gitignore（每个目录）和$ GIT_DIR / info / exclude 读取的标准忽略规则，但仍然使用-e选项给出的忽略规则。这允许删除所有未跟踪的文件，包括构建产品。这可以使用（可能与 git reset 一起使用）来创建一个 pristine 工作目录来测试一个干净的构建。
-X
仅删除 Git 忽略的文件。这可能有助于从头开始重建所有内容，但保留手动创建的文件。
互动模式
当命令进入交互模式时，它显示要清理的文件和目录，并进入其交互式命令循环。
命令循环显示可用的子命令列表，并给出提示“What now>”。通常，当提示以单个 >结束时。 ，您只能选择给定的一个选项并输入 return，如下所示：
*** Commands *** 1: clean 2: filter by pattern 3: select by numbers 4: ask each 5: quit 6: help What now> 1
只要选择是唯一的，您也可以说c或clean。
主命令循环有 6 个子命令。
clean
开始清理文件和目录，然后退出。
filter by pattern
这显示了要删除的文件和目录，并发出“输入忽略模式>>”提示。您可以输入以空格分隔的模式，以排除文件和目录的删除。例如。 “* .c * .h”将从删除中排除以“.c”和“.h”结尾的文件。如果对筛选结果感到满意，请按 ENTER（空）返回主菜单。
select by numbers
这显示了要删除的文件和目录，并发出“选择要删除的项目>>”提示。当提示以 double _>>结束时 _ 就像这样，你可以做多个选择，用空格或逗号连接起来。你也可以说范围。例如。 “2-5 7,9”从列表中选择 2,3,4,5,7,9。如果省略范围中的第二个数字，则选择所有剩余项目。例如。 “7-”从列表中选择 7,8,9。你可以说 * 来选择一切。此外，当您对筛选结果感到满意时，请按 ENTER（空）返回主菜单。
ask each
这将开始清理，您必须逐个确认才能删除项目。请注意，此操作不如上述两个操作有效。
quit
这样可以在不进行清洁的情况下退出。
help
显示交互式 git-clean 的简要用法。
也可以看看
GIT
部分 git [1] 套件
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 --amend或git 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 有两个功能可以显着缓解这个问题：
- 修改时间比
--prune日期更新的任何对象以及从中可以访问的所有对象。 - 将对象添加到数据库的大多数操作都会更新对象的修改时间（如果已存在），以便应用＃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] 套件
git-fsck
名称
git-fsck - 验证数据库中对象的连通性和有效性
概要
git fsck [--tags] [--root] [--unreachable] [--cache] [--no-reflogs] [--[no-]full] [--strict] [--verbose] [--lost-found] [--[no-]dangling] [--[no-]progress] [--connectivity-only] [--[no-]name-objects] [<object>*]
描述
验证数据库中对象的连接性和有效性。
OPTIONS
<object>
作为不可达性痕迹的头部对象的对象。
如果没有给出对象， git fsck 默认使用索引文件，refs命名空间中的所有 SHA-1 引用，以及所有 reflog（除非给出–no-reflogs）作为头。
--unreachable
打印出存在但无法从任何引用节点访问的对象。
--[no-]dangling
打印存在但永远不会 _ 直接 _ 使用的对象（默认）。 --no-dangling可用于从输出中省略此信息。
--root
报告根节点。
--tags
报告标签。
--cache
将索引中记录的任何对象也视为不可达性跟踪的头节点。
--no-reflogs
不要认为仅由 reflog 中的条目引用的提交是可访问的。此选项仅用于搜索曾经在 ref 中的提交，但现在不是，但仍在相应的 reflog 中。
--full
不仅检查 GIT_OBJECT_DIRECTORY（
）中的对象，还检查在
或GITDIR/objects）中的对象，还检查在GITALTERNATEOBJECTDIRECTORIES或 GIT_DIR / objects）中的对象，还检查在 GIT_ALTERNATE_OBJECT_DIRECTORIES 或 GIT_DIR / objects / info / alternates 中列出的备用对象池中找到的对象，以及在$ GIT_DIR / objects / pack 中找到的打包 Git 存档中找到的对象打包备用对象池中的子目录。这是默认值;你可以用–no-full 把它关掉。
--connectivity-only
仅检查标记，提交和树对象的连接。通过避免解压缩 blob，这会加速操作，但代价是丢失损坏的对象或其他有问题的问题。
--strict
启用更严格的检查，即捕获由 g + w 位集记录的文件模式，该模式由旧版本的 Git 创建。现有存储库（包括 Linux 内核，Git 本身和稀疏存储库）具有触发此检查的旧对象，但建议使用此标志检查新项目。
--verbose
说实话。
--lost-found
将悬空对象写入.git / lost-found / commit /或.git / lost-found / other /，具体取决于类型。如果对象是 blob，则将内容写入文件，而不是其对象名称。
--name-objects
当显示可到达对象的名称时，除了 SHA-1 之外还显示描述如何可以到达的名称，与 git-rev-parse [1] 兼容，例如HEAD@{1234567890}~25²:src/。
--[no-]progress
除非指定了–no-progress 或–verbose，否则默认情况下，当标准错误流附加到终端时，会报告进度状态。 - 即使标准错误流未定向到终端， - progress 也会强制进度状态。
讨论
git-fsck 测试 SHA-1 和一般对象的健全性，它完全跟踪产生的可达性和其他所有内容。它会打印出它找到的任何损坏（丢失或坏的对象），如果使用--unreachable标志，它还会打印出存在但无法从任何指定的头节点（或默认集）访问的对象，正如刚才提到的）。
您必须在备份或其他存档中找到任何损坏的对象（即，您可以删除它们并与其他某个站点一起执行 rsync ，希望其他人拥有您已损坏的对象）。
如果 core.commitGraph 为 true，则还将使用 git commit-graph verify 检查提交图文件。参见 git-commit-graph [1] 。
提取的诊断
expect dangling commits - potential heads - due to lack of head information
您没有指定任何节点作为头，因此无法区分非父级提交和根节点。
missing sha1 directory <dir>
缺少包含 sha1 对象的目录。
unreachable <type> <object>
< type>对象< object>，实际上并未在任何树或提交的提交中直接或间接引用。这可能意味着您没有指定另一个根节点或树已损坏。如果您没有错过根节点，那么您也可以删除无法访问的节点，因为它们无法使用。
missing <type> <object>
< type>对象< object>，被引用但不存在于数据库中。
dangling <type> <object>
< type>对象< object>，存在于数据库中但从不直接使用。悬挂提交可以是根节点。
hash mismatch <object>
数据库有一个对象，其哈希值与对象数据库值不匹配。这表明存在严重的数据完整性问题。
环境变量
GIT_OBJECT_DIRECTORY
用于指定对象数据库的根目录（通常为$ GIT_DIR / objects）
GIT_INDEX_FILE
用于指定索引的索引文件
GIT_ALTERNATE_OBJECT_DIRECTORIES
用于指定其他对象数据库根（通常未设置）
GIT
部分 git [1] 套件
git-reflog
名称
git-reflog - 管理 reflog 信息
概要
git reflog <subcommand> <options>
描述
该命令采用各种子命令，并根据子命令使用不同的选项：
git reflog [show] [log-options] [<ref>] git reflog expire [--expire=<time>] [--expire-unreachable=<time>] [--rewrite] [--updateref] [--stale-fix] [--dry-run | -n] [--verbose] [--all [--single-worktree] | <refs>…] git reflog delete [--rewrite] [--updateref] [--dry-run | -n] [--verbose] ref@{specifier}… git reflog exists <ref>
引用日志或“reflogs”记录在本地存储库中更新分支和其他引用的提示时。 Reflog 在各种 Git 命令中很有用，用于指定引用的旧值。例如，HEAD@{2}表示“HEAD 过去两次移动的地方”，master@{one.week.ago}表示“主要用于指向一周前的本地存储库”，依此类推。有关详细信息，请参阅 gitrevisions [7] 。
此命令管理 reflog 中记录的信息。
“show”子命令（在没有任何子命令的情况下也是默认命令）显示命令行中提供的引用的日志（或默认情况下为HEAD）。 reflog 包含所有最近的操作，此外HEAD reflog 记录分支切换。 git reflog show是git log -g --abbrev-commit --pretty=oneline的别名;有关详细信息，请参阅 git-log [1] 。
“expire”子命令修剪旧的 reflog 条目。超过expire时间的条目，或者早于expire-unreachable时间且当前提示无法访问的条目将从 reflog 中删除。这通常不会被最终用户直接使用 - 相反，请参阅 git-gc [1] 。
“delete”子命令从 reflog 中删除单个条目。其参数必须是 _ 精确 _ 条目（例如“git reflog delete master@{2}”）。最终用户通常也不直接使用此子命令。
“exists”子命令检查 ref 是否具有 reflog。如果 reflog 存在则退出为零状态，如果不存在则退出为非零状态。
OPTIONS
show的选项
git reflog show接受git log接受的任何选项。
expire的选项
--all
处理所有引用的 reflog。
--single-worktree
默认情况下，指定--all时，将处理来自所有工作树的 reflog。此选项仅将处理限制为来自当前工作树的 reflog。
--expire=<time>
修剪早于指定时间的条目。如果未指定此选项，则到期时间取自配置设置gc.reflogExpire，后者默认为 90 天。 --expire=all修剪条目，不论其年龄; --expire=never关闭可达条目的修剪（但参见--expire-unreachable）。
--expire-unreachable=<time>
修剪早于<time>的条目，无法从分支的当前提示访问。如果未指定此选项，则到期时间取自配置设置gc.reflogExpireUnreachable，后者默认为 30 天。 --expire-unreachable=all修剪无法访问的条目，无论其年龄如何; --expire-unreachable=never关闭无法访问的条目的早期修剪（但参见--expire）。
--updateref
如果前一个顶部条目被修剪，则更新对顶部 reflog 条目的值的引用（即< ref> @ {0}）。 （符号引用会忽略此选项。）
--rewrite
如果修剪了 reflog 条目的前任，则将其“旧”SHA-1 调整为等于其前面的条目的“新”SHA-1 字段。
--stale-fix
修剪任何指向“已损坏的提交”的 reflog 条目。破坏的提交是无法从任何参考提示访问的提交，它直接或间接地引用缺少的提交，树或 blob 对象。
该计算涉及遍历所有可到达对象，即它具有与 git prune 相同的成本。它主要用于修复使用旧版 Git 进行垃圾收集而导致的损坏，这些版本不保护 reflog 所引用的对象。
-n
--dry-run
不要删除任何条目;只是展示会被修剪的东西。
--verbose
在屏幕上打印额外信息。
delete的选项
git reflog delete接受选项--updateref，--rewrite，-n，--dry-run和--verbose，其含义与expire使用时的含义相同。
GIT
部分 git [1] 套件
Git 中文参考（六）（9）https://developer.aliyun.com/article/1565810
