git-config

获取和设置仓库或全局选项

概要

[verse]
'git config list' [<file-option>] [<display-option>] [--includes]
'git config get' [<file-option>] [<display-option>] [--includes] [--all] [--regexp] [--value=<pattern>] [--fixed-value] [--default=<default>] [--url=<url>] <name>
'git config set' [<file-option>] [--type=<type>] [--all] [--value=<pattern>] [--fixed-value] <name> <value>
'git config unset' [<file-option>] [--all] [--value=<pattern>] [--fixed-value] <name>
'git config rename-section' [<file-option>] <old-name> <new-name>
'git config remove-section' [<file-option>] <name>
'git config edit' [<file-option>]
'git config' [<file-option>] --get-colorbool <name> [<stdout-is-tty>]

描述

你可以使用此命令查询/设置/替换/取消设置选项。名称实际上是用点分隔的节和键，值会被转义。

可以使用 --append 选项为一个选项添加多行。如果你想更新或取消设置一个可能出现在多行的选项，需要给出 --value=<pattern>（这是一个扩展正则表达式，除非给出了 --fixed-value 选项）。只有匹配该模式的现有值才会被更新或取消设置。如果你想处理不匹配模式的行，只需在前面加上一个感叹号（另见 <<EXAMPLES>>），但请注意这仅在未使用 --fixed-value 选项时有效。

--type=<type> 选项指示 'git config' 确保传入和传出的值在给定的 <type> 下可以被规范化。如果未给出 --type=<type>，则不会执行规范化。调用者可以使用 --no-type 取消已设置的 --type 说明符。

读取时，默认从系统、全局和仓库本地配置文件中读取值，可以使用 --system、--global、--local、--worktree 和 --file <filename> 选项指示命令仅从该位置读取（见 <<FILES>>）。

写入时，默认将新值写入仓库本地配置文件，可以使用 --system、--global、--worktree、--file <filename> 选项指示命令写入该位置（可以使用 --local，但这是默认值）。

此命令在出错时将以非零状态退出。一些退出码为：

• 节或键无效 (ret=1)，
• 未提供节或名称 (ret=2)，
• 配置文件无效 (ret=3)，
• 配置文件不可写 (ret=4)，
• 你尝试取消设置一个不存在的选项 (ret=5)，
• 你尝试取消设置/设置一个匹配多行的选项 (ret=5)，或
• 你尝试使用无效的正则表达式 (ret=6)。

成功时，命令返回退出码 0。

可以使用 git help --config 命令获取所有可用配置变量的列表。

选项

--value=<pattern>

--no-value

在 get、set 和 unset 中，仅匹配 <pattern>。除非给出 --fixed-value，否则该模式是扩展正则表达式。 + 使用 --no-value 取消设置 <pattern>。

--fixed-value:: 与 --value=<pattern> 一起使用时，将 <pattern> 视为精确字符串而非正则表达式。这将限制匹配的名称/值对仅为值完全等于 <pattern> 的那些。

--type <type>:: 'git config' 将确保任何输入或输出在给定的类型约束下有效，并将传出值规范化为 <type> 的规范形式。 + 有效的 <type> 包括： +

• 'bool'：将值 true、yes、on 和正数规范化为 "true"，将值 false、no、off 和 0 规范化为 "false"。
• 'int'：将值规范化为简单的十进制数。可选的后缀 'k'、'm' 或 'g' 将导致值在输入时乘以 1024、1048576 或 1073741824。
• 'bool-or-int'：根据上述 'bool' 或 'int' 进行规范化。
• 'path'：通过将前导 ~ 扩展为 $HOME 的值，将 ~user 扩展为指定用户的主目录来进行规范化。此说明符在设置值时无效（但你可以从命令行使用 git config section.variable ~/ 让 shell 进行扩展。）
• 'expiry-date'：通过将固定或相对日期字符串转换为时间戳来进行规范化。此说明符在设置值时无效。
• 'color'：获取值时，通过转换为 ANSI 颜色转义序列来进行规范化。设置值时，会执行健全性检查以确保给定值可以作为 ANSI 颜色进行规范化，但会按原样写入。

如果命令处于 list 模式，则 --type <type> 参数将应用于每个列出的配置值。如果值无法成功以该格式解析，则将从列表中省略。

--bool:: --int:: --bool-or-int:: --path:: --expiry-date:: 选择类型说明符的历史选项。建议使用 --type（见上文）。

--no-type:: 取消先前设置的类型说明符（如果之前已设置）。此选项请求 'git config' 不规范化检索到的变量。--no-type 在没有 --type=<type> 或 --<type> 时无效。

-z:: --null:: 对于所有输出值和/或键的选项，始终以空字符（而不是换行符）结束值。使用换行符作为键和值之间的分隔符。这允许安全地解析输出，而不会被例如包含换行符的值所混淆。

--name-only:: 仅为 list 或 get 输出配置变量的名称。

--show-names

--no-show-names

使用 get 时，除了显示值还显示配置键。默认为 --no-show-names，除非给出了 --url 且 <name> 中没有子节。

--show-origin:: 在所有查询的配置选项输出中附加来源类型（文件、标准输入、blob、命令行）和实际来源（配置文件路径、ref 或 blob id（如适用））。

--show-scope:: 类似于 --show-origin，在所有查询的配置选项输出中附加该值的作用域（worktree、local、global、system、command）。

--get-colorbool <name> [<stdout-is-tty>]::

查找 `<name>`（例如 `color.diff`）的颜色设置并输出 "true" 或 "false"。`<stdout-is-tty>` 应为 "true" 或 "false"，当配置为 "auto" 时会被考虑在内。如果 `<stdout-is-tty>` 缺失，则检查命令本身的标准输出，如果使用颜色则以状态 0 退出，否则以状态 1 退出。当 `name` 的颜色设置未定义时，命令使用 `color.ui` 作为后备。

--includes:: --no-includes:: 查找值时遵循配置文件中的 include.* 指令。当给出特定文件时（例如使用 --file、--global 等）默认为 off，搜索所有配置文件时默认为 on。

--default <value>:: 使用 get 时，如果未找到请求的变量，则表现为 <value> 是分配给该变量的值。

示例

假设 .git/config 如下：

#
# This is the config file, and
# a '#' or ';' character indicates
# a comment
#

; core variables
[core]
	; Don't trust file modes
	filemode = false

; Our diff algorithm
[diff]
	external = /usr/local/bin/diff-wrapper
	renames = true

; Proxy settings
[core]
	gitproxy=proxy-command for kernel.org
	gitproxy=default-proxy ; for all the rest

; HTTP
[http]
	sslVerify
[http "https://weak.example.com"]
	sslVerify = false
## COMMANDS

list::
	列出配置文件中设置的所有变量及其值。

get::
	发出指定键的值。如果键在配置中出现多次，发出最后一个值。如果指定了 `--all`，发出与键关联的所有值。如果键不存在，返回错误代码 1。

set::
	为一个或多个配置选项设置值。默认情况下，此命令拒绝写入多值配置选项。传递 `--all` 将用新值替换所有多值配置选项，而 `--value=` 将替换所有值匹配给定模式的配置选项。

unset::
	取消设置一个或多个配置选项的值。默认情况下，此命令拒绝取消设置多值键。传递 `--all` 将取消设置所有多值配置选项，而 `--value` 将取消设置所有值匹配给定模式的配置选项。

rename-section::
	将给定的节重命名为新名称。

remove-section::
	从配置文件中删除给定的节。

edit::
	打开编辑器以修改指定的配置文件；可以是 `--system`、`--global`、`--local`（默认）、`--worktree` 或 `--file <config-file>`。

[[OPTIONS]]

## 已弃用模式

以下模式已被弃用，推荐使用子命令。建议迁移到新语法。

'git config <name>'::
	已被 `git config get <name>` 替代。

'git config <name> <value> [<value-pattern>]'::
	已被 `git config set [--value=<pattern>] <name> <value>` 替代。

-l::
--list::
	已被 `git config list` 替代。

--get <name> [<value-pattern>]::
	已被 `git config get [--value=<pattern>] <name>` 替代。

--get-all <name> [<value-pattern>]::
	已被 `git config get [--value=<pattern>] --all <name>` 替代。

--get-regexp <name-regexp>::
	已被 `git config get --all --show-names --regexp <name-regexp>` 替代。

--get-urlmatch <name> <URL>::
	已被 `git config get --url=<URL> <name>` 替代。

--get-color <name> [<default>]::
	已被 `git config get --type=color [--default=<default>] <name>` 替代。

--add <name> <value>::
	已被 `git config set --append <name> <value>` 替代。

--unset <name> [<value-pattern>]::
	已被 `git config unset [--value=<pattern>] <name>` 替代。

--unset-all <name> [<value-pattern>]::
	已被 `git config unset [--value=<pattern>] --all <name>` 替代。

--rename-section <old-name> <new-name>::
	已被 `git config rename-section <old-name> <new-name>` 替代。

--remove-section <name>::
	已被 `git config remove-section <name>` 替代。

-e::
--edit::
	已被 `git config edit` 替代。

## 配置

`pager.config` 仅在列出配置时生效，即使用 `list` 或 `get` 可能返回多个结果时。默认使用分页器。

[[FILES]]

## 文件

默认情况下，'git config' 将从多个文件中读取配置选项：

$(prefix)/etc/gitconfig::
	系统级配置文件。

$XDG_CONFIG_HOME/git/config::
~/.gitconfig::
	用户特定的配置文件。当 XDG_CONFIG_HOME 环境变量未设置或为空时，使用 $HOME/.config/ 作为 $XDG_CONFIG_HOME。
+
这些也称为"全局"配置文件。如果两个文件都存在，则按上述顺序读取两个文件。

$GIT_DIR/config::
	仓库特定的配置文件。

$GIT_DIR/config.worktree::
	这是可选的，仅在 $GIT_DIR/config 中存在 `extensions.worktreeConfig` 时才会搜索。

你还可以在运行任何 git 命令时使用 `-c` 选项提供额外的配置参数。详见 [git(1)](/git)。

将从所有可用的这些文件中读取选项。如果全局或系统级配置文件缺失或不可读，它们将被忽略。如果仓库配置文件缺失或不可读，'git config' 将以非零错误代码退出。如果文件不可读会产生错误消息，但如果文件缺失则不会。

文件按上述顺序读取，最后找到的值优先于先前读取的值。当取多个值时，将使用所有文件中某个键的所有值。

默认情况下，选项仅写入仓库特定的配置文件。请注意，这也影响 `set` 和 `unset` 等选项。*'git config' 一次只会更改一个文件*。

你可以通过使用 `--file` 选项指定文件路径，或使用 `--system`、`--global`、`--local` 或 `--worktree` 指定配置作用域来限制读取或写入的配置源。有关更多信息，请参见上面的 <<OPTIONS>>。

[[SCOPES]]

## 作用域

每个配置源都属于一个配置作用域。这些作用域是：

system::
	$(prefix)/etc/gitconfig

global::
	$XDG_CONFIG_HOME/git/config
+
~/.gitconfig

local::
	$GIT_DIR/config

worktree::
	$GIT_DIR/config.worktree

command::
	GIT_CONFIG_{COUNT,KEY,VALUE} 环境变量（见下面的 <<ENVIRONMENT>>）
+
`-c` 选项

除了 'command' 之外，每个作用域对应一个命令行选项：`--system`、`--global`、`--local`、`--worktree`。

读取选项时，指定作用域将仅从该作用域内的文件读取选项。写入选项时，指定作用域将写入该作用域内的文件（而不是仓库特定的配置文件）。完整描述请参见上面的 <<OPTIONS>>。

大多数配置选项无论在哪个作用域定义都会被遵循，但某些选项仅在特定作用域中生效。有关完整详情，请参阅各自选项的文档。

### 受保护的配置
受保护的配置指的是 'system'、'global' 和 'command' 作用域。出于安全原因，某些选项仅在受保护的配置中指定时才会被遵循，否则将被忽略。

Git 将这些作用域视为由用户或受信任的管理员控制。这是因为控制这些作用域的攻击者可以在不使用 Git 的情况下造成重大损害，因此假定用户的环境会保护这些作用域免受攻击者的侵害。

[[ENVIRONMENT]]

## 环境

GIT_CONFIG_GLOBAL::
GIT_CONFIG_SYSTEM::
	从给定的文件中获取配置，而不是从全局或系统级配置中获取。详见 [git(1)](/git)。

GIT_CONFIG_NOSYSTEM::
	是否跳过读取系统级 $(prefix)/etc/gitconfig 文件中的设置。详见 [git(1)](/git)。

另见 <<FILES>>。

GIT_CONFIG_COUNT::
GIT_CONFIG_KEY_<n>::
GIT_CONFIG_VALUE_<n>::
	如果 GIT_CONFIG_COUNT 设置为正数，则所有环境变量对 GIT_CONFIG_KEY_<n> 和 GIT_CONFIG_VALUE_<n>（直到该数字）将被添加到进程的运行时配置中。配置对是从零开始索引的。任何缺失的键或值都被视为错误。空的 GIT_CONFIG_COUNT 与 GIT_CONFIG_COUNT=0 相同，即不处理任何对。这些环境变量将覆盖配置文件中的值，但会被通过 `git -c` 传递的任何显式选项覆盖。
+
这在你希望用通用配置启动多个 git 命令但不能依赖配置文件的情况下很有用，例如在编写脚本时。

GIT_CONFIG::
	如果没有为 `git config` 提供 `--file` 选项，则使用 `GIT_CONFIG` 给定的文件，就像通过 `--file` 提供的一样。此变量对其他 Git 命令没有影响，主要是为了历史兼容性；通常没有理由使用它而不是 `--file` 选项。

[[EXAMPLES]]

## cookieFile = /tmp/cookie.txt

你可以使用以下命令将 filemode 设置为 true

% git config set core.filemode true

假设的代理命令条目实际上有一个后缀来区分它们适用于哪个 URL。以下是将 kernel.org 的条目更改为 "ssh" 的方法。

## % git config set --value='for kernel.org$' core.gitproxy '"ssh" for kernel.org'

这确保只有 kernel.org 的键/值对被替换。

要删除 renames 的条目，执行

% git config unset diff.renames

如果你想删除一个多变量（如上面的 core.gitproxy）的条目，你必须提供一个匹配恰好一行值的正则表达式。

要查询给定键的值，执行

## % git config get core.filemode

或者，查询一个多变量：

% git config get --value="for kernel.org$" core.gitproxy

如果你想了解一个多变量的所有值，执行：

## % git config get --all --show-names core.gitproxy

如果你喜欢冒险，可以用以下命令替换*所有* core.gitproxy

% git config set --all core.gitproxy ssh

然而，如果你真的只想替换默认代理的行，即没有 "for ..." 后缀的那行，执行类似这样的操作：

## % git config set --value='! for ' core.gitproxy ssh

要实际匹配只有感叹号的值，你需要

% git config set --value='[!]' section.key value

要添加一个新代理而不改变任何现有代理，使用

## % git config set --append core.gitproxy '"proxy-command" for example.com'

在脚本中使用自定义颜色的示例：

#!/bin/sh WS=$(git config get --type=color --default="blue reverse" color.diff.whitespace) RESET=$(git config get --type=color --default="reset" "")

echo "${WS}your whitespace color or blue reverse${RESET}"

对于 https://weak.example.com 中的 URL，http.sslVerify 设置为 false，而对于所有其他 URL 则设置为 true：

% git config get --type=bool --url=https://good.example.com http.sslverify
true
% git config get --type=bool --url=https://weak.example.com http.sslverify
false
% git config get --url=https://weak.example.com http
http.cookieFile /tmp/cookie.txt

## http.sslverify false



## 配置文件

Git 配置文件包含许多影响 Git 命令行为的变量。每个仓库中的 `.git/config` 文件和可选的 `config.worktree`（参见 [git-worktree(1)](/git-worktree) 的"配置文件"部分）用于存储该仓库的配置，而 `$HOME/.gitconfig` 用作存储每个用户的配置，作为 `.git/config` 文件的后备值。文件 `/etc/gitconfig` 可用于存储系统级默认配置。

配置变量被 Git 底层命令和 porcelain 命令使用。变量被分为多个节，其中变量本身的完全限定名称是最后一个点分隔的段，节名是最后一个点之前的所有内容。变量名不区分大小写，仅允许字母数字字符和 `-`，且必须以字母字符开头。某些变量可能出现多次；我们称这种变量为多值变量。

### 语法
语法相当灵活和宽松。空白字符（在此上下文中是空格字符 (SP) 和水平制表符 (HT)）大多被忽略。`#` 和 `;` 字符开始注释直到行尾。空行被忽略。

该文件由节和变量组成。节以方括号中的节名开始，持续到下一个节开始。节名不区分大小写。节名中仅允许字母数字字符、`-` 和 `.`。每个变量必须属于某个节，这意味着在第一个变量设置之前必须有一个节头。

节可以进一步分为子节。要开始一个子节，请将其名称放在双引号中，用空格与节名隔开，放在节头中，如下面的示例：

[section "subsection"]

子节名称区分大小写，可以包含除换行符和空字节之外的任何字符。双引号 `"` 和反斜杠可以通过分别转义为 `\"` 和 `\\` 来包含。在读取时，其他字符前面的反斜杠会被丢弃；例如，`\t` 被读为 `t`，`\0` 被读为 `0`。节头不能跨越多行。变量可以直接属于一个节或属于一个给定的子节。你可以有 `[section]` 如果你有 `[section "subsection"]`，但你不需要这样做。

还有一个已弃用的 `[section.subsection]` 语法。使用此语法时，子节名称会被转换为小写，并且也是区分大小写进行比较的。这些子节名称遵循与节名相同的限制。

所有其他行（以及节头之后的行的其余部分）被识别为设置变量，格式为 'name = value'（或仅 'name'，这是表示变量为布尔值 "true" 的简写）。变量名不区分大小写，仅允许字母数字字符和 `-`，且必须以字母字符开头。

变量名、`=` 和 `value` 周围的空白字符会被丢弃。'value' 内部的空白字符会原样保留。以 `#` 或 `;` 开头并延伸到行尾的注释会被丢弃。定义值的行可以通过以反斜杠 (`\`) 结尾来继续到下一行；反斜杠和行尾字符会被丢弃。

如果 `value` 需要包含前导或尾随空白字符，它必须用双引号 (`"`) 括起来。在双引号内，双引号 (`"`) 和反斜杠 (`\`) 字符必须被转义：使用 `\"` 表示 `"`，使用 `\\` 表示 `\`。

以下转义序列（除 `\"` 和 `\\` 之外）被识别：`\n` 表示换行符 (NL)，`\t` 表示水平制表符 (HT, TAB)，`\b` 表示退格 (BS)。其他字符转义序列（包括八进制转义序列）无效。


### 包含
`include` 和 `includeIf` 节允许你从另一个源包含配置指令。这些节的行为彼此相同，不同之处在于如果 `includeIf` 节的条件不为真，则可能会被忽略；请参阅下面的"条件包含"。

你可以通过将特殊的 `include.path`（或 `includeIf.*.path`）变量设置为要包含的文件名来从另一个文件包含配置文件。该变量接受路径名作为其值，并且会进行波浪号扩展。这些变量可以多次给出。

包含文件的内容会立即插入，就像它们在包含指令的位置被找到一样。如果变量的值是相对路径，则该路径被视为相对于找到包含指令的配置文件。有关示例，请参见下文。

### 条件包含
你可以通过设置 `includeIf.<condition>.path` 变量为要包含的文件名来有条件地从另一个文件包含配置文件。

条件以关键字开头，后跟冒号和一些数据，其格式和含义取决于关键字。支持的关键字是：

`gitdir`::
	关键字 `gitdir` 和冒号后面的数据用作 glob 模式。如果 .git 目录的位置匹配该模式，则包含条件被满足。
+
.git 位置可能被自动发现，或来自 `$GIT_DIR` 环境变量。如果仓库是通过 .git 文件自动发现的（例如来自子模块或链接的工作树），.git 位置将是 .git 目录的最终位置，而不是 .git 文件所在的位置。
+
该模式可以包含标准的 globbing 通配符和两个额外的通配符 `**/` 和 `/**`，它们可以匹配多个路径组件。详情请参阅 [gitignore(5)](/gitignore)。为方便起见：

 * 如果模式以 `~/` 开头，`~` 将被替换为环境变量 `HOME` 的内容。

 * 如果模式以 `./` 开头，它将被替换为包含当前配置文件的目录。

 * 如果模式不以 `~/`、`./` 或 `/` 开头，`**/` 将自动前置。例如，模式 `foo/bar` 变为 `**/foo/bar`，将匹配 `/any/path/to/foo/bar`。

 * 如果模式以 `/` 结尾，`**` 将自动添加。例如，模式 `foo/` 变为 `foo/**`。换句话说，它匹配 "foo" 及其内部的所有内容，递归地。

`gitdir/i`::
	这与 `gitdir` 相同，只是匹配是不区分大小写的（例如在不区分大小写的文件系统上）

`onbranch`::
	关键字 `onbranch` 和冒号后面的数据被视为具有标准 globbing 通配符和两个额外通配符 `**/` 和 `/**` 的模式，它们可以匹配多个路径组件。如果我们在一个工作树中，当前签出的分支名称匹配该模式，则包含条件被满足。
+
如果模式以 `/` 结尾，`**` 将自动添加。例如，模式 `foo/` 变为 `foo/**`。换句话说，它匹配所有以 `foo/` 开头的分支。如果你的分支按层次结构组织，并且你希望将配置应用于该层次结构中的所有分支，这很有用。

`hasconfig:remote.*.url`::
	此关键字和冒号后面的数据被视为具有标准 globbing 通配符和两个额外通配符 `**/` 和 `/**` 的模式，它们可以匹配多个组件。第一次看到此关键字时，将扫描其余配置文件以查找远程 URL（不应用任何值）。如果存在至少一个匹配此模式的远程 URL，则包含条件被满足。
+
此选项包含的文件（直接或间接）不允许包含远程 URL。
+
请注意，与其他 includeIf 条件不同，解析此条件依赖于在读取条件时尚未知的信息。一个典型的用例是此选项作为系统级或全局级配置存在，而远程 URL 在本地级配置中；因此在解析此条件时需要提前扫描。为了避免潜在包含的文件影响这些文件是否被潜在包含的鸡生蛋问题，Git 通过禁止这些文件影响这些条件的解析来打破循环（从而禁止它们声明远程 URL）。
+
至于此关键字的命名，它是为了与支持更多基于变量的包含条件的命名方案的前向兼容，但目前 Git 仅支持上述确切关键字。

关于通过 `gitdir` 和 `gitdir/i` 匹配的更多说明：

 * `$GIT_DIR` 中的符号链接在匹配之前不会被解析。

 * `$GIT_DIR` 之外的路径的符号链接版本和 realpath 版本都将被匹配。例如，如果 ~/git 是 /mnt/storage/git 的符号链接，`gitdir:~/git` 和 `gitdir:/mnt/storage/git` 都将匹配。
+
这在此功能的初始版本 v2.13.0 中并非如此，该版本仅匹配 realpath 版本。希望与此功能的初始版本兼容的配置需要仅指定 realpath 版本，或同时指定两个版本。

 * 请注意，"../" 不是特殊的，将按字面意思匹配，这不太可能是你想要的。

### 示例

Core variables

[core] ; Don't trust file modes filemode = false

Our diff algorithm

[diff] external = /usr/local/bin/diff-wrapper renames = true

[branch "devel"] remote = origin merge = refs/heads/devel

Proxy settings

[core] gitProxy="ssh" for "kernel.org" gitProxy=default-proxy ; for the rest

[include] path = /path/to/foo.inc ; include by absolute path path = foo.inc ; find "foo.inc" relative to the current file path = ~/foo.inc ; find "foo.inc" in your $HOME directory

; include if $GIT_DIR is /path/to/foo/.git [includeIf "gitdir:/path/to/foo/.git"] path = /path/to/foo.inc

; include for all repositories inside /path/to/group [includeIf "gitdir:/path/to/group/"] path = /path/to/foo.inc

; include for all repositories inside $HOME/to/group [includeIf "gitdir:~/to/group/"] path = /path/to/foo.inc

; relative paths are always relative to the including ; file (if the condition is true); their location is not ; affected by the condition [includeIf "gitdir:/path/to/group/"] path = foo.inc

; include only if we are in a worktree where foo-branch is ; currently checked out [includeIf "onbranch:foo-branch"] path = foo.inc

; include only if a remote with the given URL exists (note ; that such a URL may be provided later in a file or in a ; file read after this file is read, as seen in this example) [includeIf "hasconfig:remote.*.url:https://example.com/**"] path = foo.inc [remote "origin"]

url = https://example.com/git

值

许多变量的值被视为简单字符串，但有些变量接受特定类型的值，并且有关于如何拼写它们的规则。

boolean::

   当一个变量被说成接受布尔值时，许多同义词被接受为 'true' 和 'false'；这些都是不区分大小写的。

true;; 布尔真文字是 `yes`、`on`、`true` 和 `1`。此外，没有 `= <value>` 定义的变量被视为 true。

false;; 布尔假文字是 `no`、`off`、`false`、`0` 和空字符串。

使用 --type=bool 类型说明符将值转换为规范形式时，'git config' 将确保输出为 "true" 或 "false"（小写拼写）。

integer:: 指定各种大小的许多变量的值可以用 k、M 等后缀，表示"将数字乘以 1024"、"乘以 1024x1024"等。

color:: 接受颜色的变量的值是颜色列表（最多两个，一个用于前景，一个用于背景）和属性（任意多个），用空格分隔。 + 接受的基本颜色是 normal、black、red、green、yellow、blue、magenta、cyan、white 和 default。给出的第一个颜色是前景；第二个是背景。除了 normal 和 default 之外的所有基本颜色都有一个明亮变体，可以通过在颜色前加上 bright 来指定，如 brightred。 + 颜色 normal 不改变颜色。它与空字符串相同，但可以在单独指定背景颜色时用作前景颜色（例如 "normal red"）。 + 颜色 default 显式地将颜色重置为终端默认值，例如用于指定清除的背景。虽然它因终端而异，但这通常与设置为 "white black" 不同。 + 颜色也可以用 0 到 255 之间的数字给出；这些使用 ANSI 256 色模式（但请注意并非所有终端都支持此功能）。如果你的终端支持，你也可以指定 24 位 RGB 值为十六进制，如 #ff0ab3，或 12 位 RGB 值如 #f1b，它等同于 24 位颜色 #ff11bb。 + 接受的属性是 bold、dim、ul、blink、reverse、italic 和 strike（用于删除线字母）。任何属性相对于颜色的位置（之前、之后或中间）无关紧要。特定属性可以通过在前面加上 no 或 no- 来关闭（例如 noreverse、no-ul 等）。 + 伪属性 reset 在应用指定的着色之前重置所有颜色和属性。例如，reset green 将产生绿色前景和默认背景，没有任何活动属性。 + 空颜色字符串不会产生任何颜色效果。这可用于在不完全禁用颜色的情况下避免为特定元素着色。 + 对于 git 的预定义颜色槽，属性意味着在彩色输出中的每个项目开始时重置。因此将 color.decorate.branch 设置为 black 将以纯 black 绘制该分支名称，即使同一输出行上的前一个内容（例如 log --decorate 输出中分支名称列表之前的左括号）设置为用 bold 或其他属性绘制。但是，自定义日志格式可能执行更复杂和分层的着色，否定形式在那里可能有用。

pathname:: 接受路径名值的变量可以给定一个以 "~/" 或 "~user/" 开头的字符串，对该字符串会进行通常的波浪号扩展：~/ 扩展为 $HOME 的值，~user/ 扩展为指定用户的主目录。 + 如果路径以 %(prefix)/ 开头，其余部分被解释为相对于 Git 的"运行时前缀"的路径，即相对于 Git 本身安装的位置。例如，%(prefix)/bin/ 指的是 Git 可执行文件本身所在的目录。如果 Git 在编译时没有运行时前缀支持，则将替换编译时的前缀。在不太可能的情况下，如果需要指定不应被扩展的字面路径，它需要以 ./ 为前缀，如：./%(prefix)/bin。 + 如果以 :(optional) 为前缀，如果命名的路径不存在，配置变量将被视为不存在。

变量

请注意，此列表不是全面的，也不一定完整。对于特定于命令的变量，你将在适当的手册页中找到更详细的描述。

其他与 git 相关的工具可能并且确实使用它们自己的变量。在为你自己的工具发明新变量时，请确保它们的名称不会与 Git 本身和其他流行工具使用的名称冲突，并在你的文档中描述它们。

add.ignoreErrors:: add.ignore-errors（已弃用）:: 告诉 git add 在某些文件由于索引错误而无法添加时继续添加文件。 ifdef::git-add[] 等同于 --ignore-errors 选项。 endif::git-add[] ifndef::git-add[] 等同于 git-add(1) 的 --ignore-errors 选项。 endif::git-add[] add.ignore-errors 已弃用，因为它不遵循配置变量的通常命名约定。

advice.*:: 这些变量控制各种旨在帮助新用户的可选帮助消息。当未配置时，Git 将给出消息以及如何消除它的说明。你可以通过将相应的变量设置为 false 来告诉 Git 你已理解该问题并且不再需要特定的帮助消息。 + 由于这些消息旨在帮助人类用户，它们被输出到标准错误。当将 Git 作为子进程运行的工具发现它们具有破坏性时，它们可以在环境中设置 GIT_ADVICE=0 来消除所有建议消息。

+

• 0 或 false - 禁用目标。
• 1 或 true - 写入 STDERR。
• [2-9] - 写入已打开的文件描述符。
• <absolute-pathname> - 以追加模式写入文件。如果目标已存在且是目录，则跟踪将写入给定目录下的文件（每个进程一个）。
• af_unix:[<socket-type>:]<absolute-pathname> - 写入 Unix DomainSocket（在支持它们的平台上）。Socket 类型可以是 stream 或 dgram；如果省略，Git 将

改用 branch。

alias.:: alias..command:: git(1) 命令包装器的命令别名。可以使用两种语法定义别名：

你在 command 中定义别名的操作。

示例：

command = commit --amend

定义 Git 别名后，例如，+ $ git config --global alias.last "cat-file commit HEAD" # Which is equivalent to $ git config --global alias.last.command "cat-file commit HEAD" + git last 等同于 git cat-file commit HEAD。 + 为避免混淆和脚本使用问题，隐藏现有 Git 命令的别名将被忽略，但已弃用的命令除外。参数按空格分割，支持通常的 shell 引用和转义。可以使用引号对或反斜杠来引用它们。 + 请注意，别名的第一个词不一定必须是命令。它可以是传递给 git 调用的命令行选项。特别是与 -c 一起使用以传递一次性配置或与 -p 一起使用以强制分页时很有用。例如，可以定义 loud-rebase = -c verbose=true rebase，使得运行 git loud-rebase 等同于 git -c verbose=true rebase。此外，ps = -p status 将是一个有用的别名，因为 git ps 将对 git status 的输出进行分页，而原始命令不会。 + 如果别名扩展以前缀感叹号开头，它将被视为 shell 命令。例如，定义 alias.new = !gitk --all --not ORIG_HEAD，调用 git new 等同于运行 shell 命令 gitk --all --not ORIG_HEAD。注意： +

• Shell 命令将从仓库的顶级目录执行，该目录不一定是当前目录。
• GIT_PREFIX 被设置为从原始当前目录运行 git rev-parse --show-prefix 返回的值。参见 git-rev-parse(1)。
• Shell 命令别名始终接收提供给 Git 命令行的任何额外参数作为位置参数。 ** 如果你的 shell 别名是包含多个命令的"单行"脚本（例如在管道中）、引用多个参数或无法处理添加到末尾的位置参数，则应注意。例如：alias.cmd = "!echo $1 | grep $2" 作为 git cmd 1 2 调用将被执行为 'echo $1 | grep $2 1 2'，这不是你想要的。 ** 处理此问题的一种方便方法是将脚本操作写在内联函数中，然后用命令行中的任何参数调用它。例如 alias.cmd = "!c() { echo $1 | grep $2 ; }; c" 将正确执行前面的示例。 ** 设置 GIT_TRACE=1 可以帮助你调试别名运行的命令。

am.keepcr:: 如果为 true，git-am(1) 将使用参数 --keep-cr 调用 git-mailsplit(1) 处理 mbox 格式的补丁。在这种情况下，git-mailsplit(1) 将不会从以 \r\n 结尾的行中移除 \r。可以通过从命令行给出 --no-keep-cr 来覆盖。

am.threeWay:: 默认情况下，如果补丁不能干净地应用，git-am(1) 将失败。当设置为 true 时，此设置告诉 git-am(1) 在补丁记录了它应该应用的 blob 的身份并且我们在本地有这些 blob 时回退到三方合并（等同于从命令行给出 --3way 选项）。默认为 false。

am.messageId:: 使用 git-am(1) 时，基于电子邮件头向提交添加 Message-ID 尾部（参见 git-interpret-trailers(1)）。另见 --message-id 和 --no-message-id 选项。

apply.ignoreWhitespace:: 设置为 'change' 时，告诉 'git apply' 忽略空白更改，与 --ignore-space-change 选项相同。设置为 no、none、never、false 之一时，告诉 'git apply' 尊重所有空白差异。参见 git-apply(1)。

apply.whitespace:: 告诉 'git apply' 如何处理空白，与 --whitespace 选项相同。参见 git-apply(1)。

attr.tree:: 对仓库中树的引用，用于从中读取属性，而不是工作树中的 .gitattributes 文件。如果该值无法解析为有效的树对象，则使用空树。当使用 GIT_ATTR_SOURCE 环境变量或 --attr-source 命令行选项时，此配置变量无效。 命令行选项时，此配置变量无效。

TIP

bitmapPseudoMerge.* 中的配置选项被认为是

实验性的，可能会在未来更改或完全移除。有关伪合并位图功能的更多信息，请参阅 gitpacking(7) 的"伪合并位图"部分。

bitmapPseudoMerge.<name>.pattern:: 用于匹配引用名称的正则表达式。匹配此模式的引用指向的提交（并满足以下标准，如 bitmapPseudoMerge.<name>.sampleRate 和 bitmapPseudoMerge.<name>.threshold）将被考虑包含在伪合并位图中。 + 提交根据指向给定提交的任何引用是否匹配模式（扩展正则表达式）被分组到伪合并组中。 + 在伪合并组中，提交可以基于模式中的捕获组进一步分组为子组。这些子分组通过连接正则表达式中的任何捕获组形成，中间用 '-' 连接。 + 例如，如果模式是 refs/tags/，则所有标签（假设它们满足以下标准）将被视为同一伪合并组的候选项。然而，如果模式是 refs/remotes/([0-9])+/tags/，则来自不同远程的标签将根据远程编号被分组到单独的伪合并组中。

bitmapPseudoMerge.<name>.decay:: 确定连续伪合并位图组大小递减的速率。必须为非负数。此参数可以被认为是函数 f(n) = C * n^-k 中的 k，其中 f(n) 是第 n 个组的大小。 + 将衰减率设置为 0 将导致所有组大小相同。将衰减率设置为 1 将导致第 n 个组是初始组大小的 1/n。更高的衰减率值会导致连续组以递增速率缩小。默认为 1。 + 如果所有组大小相同，包含较新提交的组可能比较早的组使用频率更低，因为指向较新提交的引用比指向旧提交的引用更新更频繁。

bitmapPseudoMerge.<name>.sampleRate:: 确定选择包含在不稳定伪合并位图中的非位图化提交（在引用提示中）的比例。必须大于 0 且小于或等于 1。默认为 1。

bitmapPseudoMerge.<name>.threshold:: 确定作为不稳定伪合并位图候选项的非位图化提交（在引用提示中，如上）的最小年龄。默认为 1.week.ago。

bitmapPseudoMerge.<name>.maxMerges:: 确定提交可以分布在其间的伪合并提交的最大数量。 + 对于模式不包含任何捕获组的伪合并组，此设置应用于所有匹配正则表达式的提交。对于具有一个或多个捕获组的模式，此设置应用于每个不同的捕获组。 + 例如，如果您的捕获组是 refs/tags/，则此设置将所有标签分配到最多 maxMerges 个伪合并提交中。然而，如果您的捕获组是 refs/remotes/([0-9]+)/tags/，则此设置将分别应用于每个远程的标签集。 + 必须为非负数。默认值为 64。

bitmapPseudoMerge.<name>.stableThreshold:: 确定作为稳定伪合并位图候选项的提交（在引用提示中，如上，但稳定提交即使已被位图覆盖仍被视为候选项）的最小年龄。默认为 1.month.ago。 + 将此阈值设置为较小的值（例如 1.week.ago）将导致生成更多稳定组（这会产生一次性生成成本），但这些组可能会随时间变得过时。使用较大的值会产生相反的代价（更少但更有用的稳定组）。

bitmapPseudoMerge.<name>.stableSize:: 确定稳定伪合并位图的大小（以提交数为单位）。默认为 512。

blame.blankBoundary:: 在 git-blame(1) 中为边界提交显示空白提交对象名称。此选项默认为 false。

blame.coloring:: 这决定了应用于 blame 输出的配色方案。可以是 'repeatedLines'、'highlightRecent' 或 'none'（默认值）。

blame.date:: 指定在 git-blame(1) 中输出日期使用的格式。如果未设置，则使用 iso 格式。有关支持的值，请参见 git-log(1) 中 --date 选项的讨论。

blame.showEmail:: 在 git-blame(1) 中显示作者电子邮件而不是作者姓名。此选项默认为 false。

blame.showRoot:: 在 git-blame(1) 中不将根提交视为边界。此选项默认为 false。

blame.ignoreRevsFile:: 在 git-blame(1) 中忽略文件中列出的修订，每行一个未缩写的对象名称。以 # 开头的空白和注释会被忽略。此选项可以重复多次。空文件名将重置忽略的修订列表。此选项将在命令行选项 --ignore-revs-file 之前处理。

blame.markUnblamableLines:: 在 git-blame(1) 的输出中，用 '*' 标记被我们无法归因于另一个提交的忽略修订更改的行。

blame.markIgnoredLines:: 在 git-blame(1) 的输出中，用 '?' 标记被忽略的修订更改的行，这些行被归因于另一个提交。

branch.autoSetupMerge:: 告诉 git branch、git switch 和 git checkout 设置新分支，以便 git-pull(1) 将适当地从起点分支合并。请注意，即使未设置此选项，也可以使用 --track 和 --no-track 选项按分支选择此行为。此选项默认为 true。有效设置为： false;; 不进行自动设置 true;; 当起点是远程跟踪分支时进行自动设置 always;; 当起点是本地分支或远程跟踪分支时进行自动设置 inherit;; 如果起点有跟踪配置，则将其复制到新分支 simple;; 仅当起点是远程跟踪分支且新分支与远程分支同名时才进行自动设置

branch.autoSetupRebase:: 当使用 git branch、git switch 或 git checkout 创建跟踪另一个分支的新分支时，此变量告诉 Git 设置拉取为变基而不是合并（参见 branch.<name>.rebase）。有效设置为： never;; 从不自动设置为 true。 local;; 对于其他本地分支的跟踪分支，设置为 true。 remote;; 对于远程跟踪分支的跟踪分支，设置为 true。 always;; 对所有跟踪分支设置为 true。

有关如何设置分支跟踪另一个分支的详情，请参见 branch.autoSetupMerge。此选项默认为 never。

branch.sort:: 此变量控制 git-branch(1) 显示分支时的排序顺序。如果没有提供 --sort=<value> 选项，则此变量的值将用作默认值。有关有效值，请参见 git-for-each-ref(1) 字段名。

branch.<name>.remote:: 当在分支 <name> 上时，它告诉 git fetch 和 git push 从哪个远程获取或推送到哪个远程。推送的远程可以通过 remote.pushDefault（对所有分支）覆盖。当前分支推送的远程可以进一步通过 branch.<name>.pushRemote 覆盖。如果没有配置远程，或者你不在任何分支上并且仓库中定义了多个远程，则默认为 origin 用于获取，remote.pushDefault 用于推送。此外，.（句点）是当前本地仓库（点仓库），请参见下面 branch.<name>.merge 的最后说明。

branch.<name>.pushRemote:: 当在分支 <name> 上时，它覆盖 branch.<name>.remote 用于推送。它还覆盖 remote.pushDefault 用于从分支 <name> 推送。当你从一个地方（例如你的上游）拉取并推送到另一个地方（例如你自己的发布仓库）时，你会想要设置 remote.pushDefault 来指定所有分支推送的远程，并使用此选项为特定分支覆盖它。

branch.<name>.merge:: 与 branch.<name>.remote 一起定义给定分支的上游分支。它告诉 git fetch/git pull/git rebase 合并哪个分支，还可以影响 git push（见 push.default）。当在分支 <name> 上时，它告诉 git fetch 要标记为在 FETCH_HEAD 中合并的默认 refspec。该值像 refspec 的远程部分一样处理，并且必须匹配从 branch.<name>.remote 给定的远程获取的 ref。合并信息被 git pull（它首先调用 git fetch）用于查找要合并的默认分支。如果没有此选项，git pull 默认合并获取的第一个 refspec。指定多个值以获得章鱼合并。如果你希望设置 git pull 使其从本地仓库中的另一个分支合并到 <name>，你可以将 branch.<name>.merge 指向所需的分支，并为 branch.<name>.remote 使用相对路径设置 .（句点）。

branch.<name>.mergeOptions:: 设置合并到分支 <name> 的默认选项。语法和支持的选项与 git-merge(1) 相同，但目前不支持包含空白字符的选项值。

branch.<name>.rebase:: 为 true 时，在获取的分支之上变基分支 <name>，而不是在运行 git pull 时合并来自默认远程的默认分支。有关以非特定分支的方式执行此操作，请参见 pull.rebase。 + 当为 merges（或仅 m）时，将 --rebase-merges 选项传递给 git rebase，以便本地合并提交包含在变基中（详见 git-rebase(1)）。 + 当值为 interactive（或仅 i）时，变基以交互模式运行。 + 注意：这是一个可能危险的操作；除非你理解其含义，否则不要使用它（详见 git-rebase(1)）。

branch.<name>.description:: 分支描述，可以用 git branch --edit-description 编辑。分支描述会自动添加到 format-patch 求职信或 request-pull 摘要中。

browser.<tool>.cmd:: 指定调用指定浏览器的命令。指定的命令在 shell 中求值，URL 作为参数传递。（参见 git-web{litdd}browse(1)。）

browser.<tool>.path:: 覆盖给定工具的路径，该工具可用于浏览 HTML 帮助（参见 git-help(1) 中的 -w 选项）或 gitweb 中的工作仓库（参见 git-instaweb(1)）。

bundle.*:: bundle.* 键可能出现在通过 git clone --bundle-uri 选项找到的包列表文件中。如果放在仓库配置文件中，这些键当前没有效果，但这在未来会改变。详见 bundle URI 设计文档。

bundle.version:: 此整数值公布包列表使用的包列表格式版本。当前唯一接受的值是 1。

bundle.mode:: 此字符串值应为 all 或 any。此值描述是需要所有公布的包才能完全理解包信息（any），还是列表中的任何包 URI 就足够了（any）。

bundle.heuristic:: 如果此字符串值的键存在，则包列表被设计为与增量 git fetch 命令良好配合。该启发式表示每个包有额外的键可用于帮助确定客户端应下载哪些包子集。当前唯一理解的值是 creationToken。

bundle.<id>.*:: bundle.<id>.* 键用于描述包列表中的单个项目，按 <id> 分组以进行标识。

bundle.<id>.uri:: 此字符串值定义了 Git 可以通过其访问此 <id> 内容的 URI。此 URI 可以是包文件或另一个包列表。

checkout.defaultRemote:: 当你运行 git checkout <something> 或 git switch <something> 并且只有一个远程时，它可能隐式地回退到签出和跟踪例如 origin/<something>。一旦你有多个具有 <something> 引用的远程，这就停止工作了。此设置允许设置首选远程的名称，在消除歧义时应始终获胜。典型用例是将其设置为 origin。 + 目前这被 git-switch(1) 和 git-checkout(1) 使用，当 git checkout <something> 或 git switch <something> 将签出另一个远程上的 <something> 分支时，以及被 git-worktree(1) 使用，当 git worktree add 引用远程分支时。此设置可能在未来用于其他类似签出的命令或功能。

checkout.guess:: 为 git checkout 和 git switch 中的 --guess 或 --no-guess 选项提供默认值。参见 git-switch(1) 和 git-checkout(1)。

checkout.workers:: 更新工作树时使用的并行工作线程数。默认为一个，即顺序执行。如果设置为小于一的值，Git 将使用与可用逻辑核心数一样多的工作线程。此设置和 checkout.thresholdForParallelism 影响所有执行签出的命令。例如 checkout、clone、reset、sparse-checkout 等。

checkout.thresholdForParallelism:: 在文件数量较少时运行并行签出，子进程启动和进程间通信的成本可能超过并行化收益。此设置允许你定义应尝试并行签出的最小文件数。默认为 100。

clean.requireForce:: 布尔值，使 git-clean 拒绝删除文件，除非给出 -f。默认为 true。

clone.defaultRemoteName:: 克隆仓库时创建的远程名称。默认为 origin。 ifdef::git-clone[] 可以通过传递 --origin 命令行选项来覆盖。 endif::[] ifndef::git-clone[] 可以通过向 git-clone(1) 传递 --origin 命令行选项来覆盖。 endif::[]

clone.rejectShallow:: 如果仓库是浅层的，则拒绝克隆；可以通过在命令行传递 --reject-shallow 选项来覆盖。 ifndef::git-clone[] 参见 git-clone(1)。 endif::[]

clone.filterSubmodules:: 如果提供了部分克隆过滤器（参见 git-rev-list(1) 中的 --filter）并且使用了 --recurse-submodules，则也将过滤器应用于子模块。

color.advice:: 布尔值，用于启用/禁用提示中的颜色（例如当推送失败时，参见 advice.* 获取列表）。可设置为 always、false（或 never）或 auto（或 true），在这种情况下颜色仅在错误输出到终端时使用。如果未设置，则使用 color.ui 的值（默认为 auto）。

color.advice.hint:: 使用自定义颜色显示提示。

color.blame.highlightRecent:: 指定 git blame --color-by-age 的行注释颜色，根据行的年龄而变化。 + 此设置应设置为逗号分隔的颜色和日期设置列表，以颜色开始和结束，日期应从最旧到最新设置。如果行在给定时间戳之前引入，则元数据将使用指定的颜色着色，覆盖较旧时间戳的颜色。 + 除了绝对时间戳外，相对时间戳也有效，例如 2.weeks.ago 可用于表示超过 2 周的内容。 + 默认为 blue,12 month ago,white,1 month ago,red，这会将超过一年的所有内容着色为蓝色，一个月到一年之间的最近更改保持白色，最近一个月内引入的行着色为红色。

color.blame.repeatedLines:: 使用指定的颜色为 git blame --color-lines 的行注释着色，如果它们与前一行来自同一提交。默认为青色。

color.branch:: 布尔值，用于启用/禁用 git-branch(1) 输出中的颜色。可设置为 always、false（或 never）或 auto（或 true），在这种情况下颜色仅在输出到终端时使用。如果未设置，则使用 color.ui 的值（默认为 auto）。

color.branch.<slot>:: 使用自定义颜色为分支着色。<slot> 是以下之一：current（当前分支）、local（本地分支）、remote（refs/remotes/ 中的远程跟踪分支）、upstream（上游跟踪分支）、plain（其他引用）。

color.diff:: 是否使用 ANSI 转义序列为补丁添加颜色。如果设置为 always，git-diff(1)、git-log(1) 和 git-show(1) 将对所有补丁使用颜色。如果设置为 true 或 auto，这些命令仅在输出到终端时使用颜色。如果未设置，则使用 color.ui 的值（默认为 auto）。 + 这不影响 git-format-patch(1) 或 'git-diff-{asterisk}' 底层命令。可以通过命令行的 --color[=<when>] 选项覆盖。

color.diff.<slot>:: 使用自定义颜色为差异着色。<slot> 指定补丁的哪个部分使用指定的颜色，是以下之一：context（上下文文本 - plain 是历史同义词）、meta（元信息）、frag（块头）、'func'（块头中的函数）、old（删除的行）、new（添加的行）、commit（提交头）、whitespace（高亮空白错误）、oldMoved（删除的行）、newMoved（添加的行）、oldMovedDimmed、oldMovedAlternative、oldMovedAlternativeDimmed、newMovedDimmed、newMovedAlternative、newMovedAlternativeDimmed（详见 git-diff(1) 中 '--color-moved' 的 '<mode>' 设置）、contextDimmed、oldDimmed、newDimmed、contextBold、oldBold 和 newBold（详见 git-range-diff(1)）。

color.decorate.<slot>:: 使用自定义颜色为 'git log --decorate' 输出着色。<slot> 是以下之一：branch、remoteBranch、tag、stash 或 HEAD，分别用于本地分支、远程跟踪分支、标签、stash 和 HEAD，以及 grafted 用于嫁接的提交。

color.grep:: 设置为 always 时，始终高亮匹配。设置为 false（或 never）时，从不。设置为 true 或 auto 时，仅在输出写入终端时使用颜色。如果未设置，则使用 color.ui 的值（默认为 auto）。

color.grep.<slot>:: 使用自定义颜色为 grep 着色。<slot> 指定行的哪个部分使用指定的颜色，是以下之一

以及块之间的部分（--）

color.interactive:: 设置为 always 时，始终为交互式提示和显示使用颜色（例如 "git-add --interactive" 和 "git-clean --interactive" 使用的）。设置为 false（或 never）时，从不。设置为 true 或 auto 时，仅在输出到终端时使用颜色。如果未设置，则使用 color.ui 的值（默认为 auto）。

color.interactive.<slot>:: 使用自定义颜色为 'git add --interactive' 和 'git clean --interactive' 输出着色。<slot> 可以是 prompt、header、help 或 error，用于交互式命令的四种不同类型正常输出。

color.pager:: 布尔值，指定 auto 颜色模式是否应为发送到分页器的输出着色。默认为 true；如果您的分页器不理解 ANSI 颜色代码，请设置为 false。

color.push:: 布尔值，用于启用/禁用推送错误中的颜色。可设置为 always、false（或 never）或 auto（或 true），在这种情况下颜色仅在错误输出到终端时使用。如果未设置，则使用 color.ui 的值（默认为 auto）。

color.push.error:: 使用自定义颜色显示推送错误。

color.remote:: 如果设置，行首的关键字将被高亮。关键字是 "error"、"warning"、"hint" 和 "success"，匹配不区分大小写。可设置为 always、false（或 never）或 auto（或 true）。如果未设置，则使用 color.ui 的值（默认为 auto）。

color.remote.<slot>:: 使用自定义颜色为每个远程关键字着色。<slot> 可以是 hint、warning、success 或 error，匹配相应的关键字。

color.showBranch:: 布尔值，用于启用/禁用 git-show-branch(1) 输出中的颜色。可设置为 always、false（或 never）或 auto（或 true），在这种情况下颜色仅在输出到终端时使用。如果未设置，则使用 color.ui 的值（默认为 auto）。

color.status:: 布尔值，用于启用/禁用 git-status(1) 输出中的颜色。可设置为 always、false（或 never）或 auto（或 true），在这种情况下颜色仅在输出到终端时使用。如果未设置，则使用 color.ui 的值（默认为 auto）。

color.status.<slot>:: 使用自定义颜色为状态着色。<slot> 是以下之一：header（状态消息的标题文本）、added 或 updated（已添加但未提交的文件）、changed（已更改但未添加到索引的文件）、untracked（Git 未跟踪的文件）、branch（当前分支）、nobranch（显示 'no branch' 警告的颜色，默认为红色）、localBranch 或 remoteBranch（当分支和跟踪信息在状态短格式中显示时的本地和远程分支名称），或 unmerged（有未合并更改的文件）。

color.transport:: 布尔值，用于启用/禁用推送被拒绝时的颜色。可设置为 always、false（或 never）或 auto（或 true），在这种情况下颜色仅在错误输出到终端时使用。如果未设置，则使用 color.ui 的值（默认为 auto）。

color.transport.rejected:: 使用自定义颜色显示推送被拒绝时。

color.ui:: 此变量确定控制每个命令系列颜色使用的变量（如 color.diff 和 color.grep）的默认值。随着更多命令学会为 --color 选项设置默认值，其范围将扩大。如果您希望 Git 命令在未通过其他配置或 --color 选项显式启用时不使用颜色，请设置为 false 或 never。如果您希望所有非机器消费的输出使用颜色，请设置为 always；如果您希望此类输出在写入终端时使用颜色，请设置为 true 或 auto（这是 Git 1.8.4 以来的默认值）。

column.ui:: 指定支持的命令是否应以列输出。此变量由空格或逗号分隔的标记列表组成： + 这些选项控制何时启用该功能（默认为 'never'）：

如果输出到终端则以列显示

这些选项控制布局（默认为 'column'）。设置任何这些都暗示 'always'，如果没有设置 'always'、'never' 或 'auto' 中的任何一个

以单列显示

最后，这些选项可以与布局选项组合（默认为 'nodense')：

使列大小相等

column.branch:: 指定是否在 git branch 中以列输出分支列表。详见 column.ui。

column.clean:: 指定在 git clean -i 中列出项目时的布局，始终以列显示文件和目录。详见 column.ui。

column.status:: 指定是否在 git status 中以列输出未跟踪文件。详见 column.ui。

column.tag:: 指定是否在 git tag 中以列输出标签列表。详见 column.ui。

ifdef::git-commit[] :see-git-commit: endif::git-commit[] ifndef::git-commit[] :see-git-commit: See git-commit(1) for details. endif::git-commit[] cleanup:: 此设置覆盖 git commit 中 --cleanup 选项的默认值。{see-git-commit} 当您希望始终保留在日志消息中以注释字符（core.commentChar，默认为 #）开头的行时，更改默认值可能很有用，在这种情况下您可以执行 git config cleanup whitespace（请注意，如果您这样做，您需要自己删除提交日志模板中以注释字符开头的帮助行）。

gpgSign:: 布尔值，指定是否所有提交都应进行 GPG 签名。在执行变基等操作时使用此选项可能导致大量提交被签名。使用代理来避免多次输入 GPG 密码可能很方便。

status:: 布尔值，用于启用/禁用在使用编辑器准备提交消息时将状态信息包含在提交消息模板中。默认为 true。

template:: 指定用作新提交消息模板的文件路径名。

verbose:: 布尔值或整数，指定 git commit 的详细级别。

commitGraph.generationVersion:: 指定写入或读取提交图文件时使用的代数版本类型。如果指定版本 1，则不会写入或读取修正的提交日期。默认为 2。

commitGraph.maxNewFilters:: 指定 git commit-graph write 的 --max-new-filters 选项的默认值（参见 git-commit-graph(1)）。

commitGraph.changedPaths:: 如果为 true，则 git commit-graph write 将默认计算并写入更改路径布隆过滤器，等同于传递 --changed-paths。如果为 false 或未设置，则仅在当前提交图文件中已存在过滤器时才会在 git commit-graph write 期间写入更改路径布隆过滤器。这与不带任何 --[no-]changed-paths 选项的 git commit-graph write 的默认行为匹配。要重写不带任何过滤器的提交图文件，请使用 --no-changed-paths 选项。命令行选项 --[no-]changed-paths 始终优先于此配置。默认为未设置。

commitGraph.readChangedPaths:: 已弃用。如果为 true，等同于 commitGraph.changedPathsVersion=-1；如果为 false，等同于 commitGraph.changedPathsVersion=0。（如果 commitGraph.changedPathVersion 也已设置，则 commitGraph.changedPathsVersion 优先。）

commitGraph.changedPathsVersion:: 指定 Git 将读取和写入的更改路径布隆过滤器的版本。可以是 -1、0、1 或 2。请注意，大于 1 的值可能与尚未理解这些版本的旧版 Git 不兼容。在混合版本环境中操作时请谨慎使用。 + 默认为 -1。 + 如果为 -1，Git 将使用仓库中的更改路径布隆过滤器版本，如果没有则默认为 1。 + 如果为 0，Git 将不会读取任何布隆过滤器，并在被指示写入时写入版本 1 布隆过滤器。 + 如果为 1，Git 将仅读取版本 1 布隆过滤器，并写入版本 1 布隆过滤器。 + 如果为 2，Git 将仅读取版本 2 布隆过滤器，并写入版本 2 布隆过滤器。 + 参见 git-commit-graph(1) 获取更多信息。

completion.commands:: 这仅由 git-completion.bash 用于从完成命令列表中添加或删除命令。通常只完成 porcelain 命令和少数其他选定命令。您可以在此变量中添加更多命令，用空格分隔。在命令前加上 '-' 将从现有列表中删除它。

core.fileMode:: 告诉 Git 是否应尊重工作树中文件的可执行位。 + 某些文件系统在签出标记为可执行的文件时会丢失可执行位，或签出不可执行文件时设置可执行位。git-clone(1) 或 git-init(1) 会探测文件系统以查看是否正确处理可执行位，并根据需要自动设置此变量。 + 然而，仓库可能位于正确处理文件模式的文件系统上，创建时此变量设置为 'true'，但后来可能从另一个丢失文件模式的环境访问（例如通过 CIFS 挂载导出 ext4，使用 Windows 版 Git 或 Eclipse 访问 Cygwin 创建的仓库）。在这种情况下，可能需要将此变量设置为 'false'。参见 git-update-index(1)。 + 默认为 true（当配置文件中未指定 core.filemode 时）。

core.hideDotFiles:: （仅 Windows）如果为 true，将名称以点开头的新创建目录和文件标记为隐藏。如果为 'dotGitOnly'，则仅隐藏 .git/ 目录，不隐藏其他以点开头的文件。默认模式为 'dotGitOnly'。

core.ignoreCase:: 内部变量，启用各种解决方法以使 Git 在不区分大小写的文件系统（如 APFS、HFS+、FAT、NTFS 等）上更好地工作。例如，如果目录列表在 Git 期望 "Makefile" 时找到 "makefile"，Git 将假定它实际上是同一个文件，并继续将其记为 "Makefile"。 + 默认为 false，但 git-clone(1) 或 git-init(1) 会在创建仓库时探测并在适当时将 core.ignoreCase 设置为 true。 + Git 依赖于此变量为您的操作系统和文件系统的正确配置。修改此值可能导致意外行为。

core.precomposeUnicode:: 此选项仅由 Git 的 Mac OS 实现使用。当 core.precomposeUnicode=true 时，Git 会还原 Mac OS 对文件名进行的 Unicode 分解。在 Mac OS 和 Linux 或 Windows 之间共享仓库时很有用。（需要 Git for Windows 1.7.10 或更高版本，或 cygwin 1.7 下的 Git。）当为 false 时，文件名由 Git 完全透明处理，这与旧版本 Git 向后兼容。

core.protectHFS:: 如果设置为 true，不允许签出路径在 HFS+ 文件系统上被视为等同于 .git 的路径。在 Mac OS 上默认为 true，其他地方为 false。

core.protectNTFS:: 如果设置为 true，不允许签出会在 NTFS 文件系统上引起问题的路径，例如与 8.3 "短" 名称冲突。在 Windows 上默认为 true，其他地方为 false。

core.fsmonitor:: 如果设置为 true，为此工作目录启用内置文件系统监控守护进程（git-fsmonitor{litdd}daemon(1)）。 + 与基于钩子的文件系统监控器类似，内置文件系统监控器可以加速需要刷新 Git 索引的 Git 命令（例如 git status）在具有许多文件的工作目录中。内置监控器消除了安装和维护外部第三方工具的需要。 + 内置文件系统监控器目前仅在有限的支持平台上可用。目前包括 Windows 和 MacOS。 + 否则，此变量包含 "fsmonitor" 钩子命令的路径名。 + 此钩子命令用于识别自请求日期/时间以来可能已更改的所有文件。此信息用于通过避免扫描未更改的文件来加速 Git。 + 参见 githooks(5) 的 "fsmonitor-watchman" 部分。 + 请注意，如果您同时使用多个版本的 Git，例如命令行中的一个版本和 IDE 工具中的另一个版本，则 core.fsmonitor 的定义已扩展为允许布尔值以及钩子路径名。Git 2.35.1 及更早版本将不理解布尔值，并将 "true" 或 "false" 值视为要调用的钩子路径名。 调用。Git 2.26 到 2.35.1 版本默认使用钩子协议 V2，如果没有 fsmonitor 则回退到完整扫描。2.26 之前的 Git 版本默认使用钩子协议 V1，并且会静默假定没有更改可报告（不扫描），因此状态命令可能报告不完整的结果。因此，最好在使用内置文件系统监控器之前升级所有 Git 版本。

core.fsmonitorHookVersion:: 设置调用 "fsmonitor" 钩子时使用的协议版本。 + 目前有版本 1 和 2。未设置时，将首先尝试版本 2，如果失败则尝试版本 1。版本 1 使用时间戳作为输入来确定自该时间以来哪些文件发生了更改，但某些监控器（如 Watchman）在与时间戳一起使用时存在竞争条件。版本 2 使用不透明字符串，以便监控器可以返回可用于确定哪些文件已更改的内容，而不会出现竞争条件。

core.trustctime:: 如果为 false，则忽略索引和工作树之间的 ctime 差异；当 inode 更改时间被 Git 以外的某些内容（文件系统爬虫和某些备份系统）定期修改时很有用。参见 git-update-index(1)。默认为 true。

core.splitIndex:: 如果为 true，将使用索引的 split-index 功能。参见 git-update-index(1)。默认为 false。

core.untrackedCache:: 确定如何处理索引的未跟踪缓存功能。如果此变量未设置或设置为 keep，它将被保留。如果设置为 true，它将自动添加。如果设置为 false，它将自动被移除。在设置为 true 之前，你应该检查 mtime 在你的系统上是否正常工作。参见 git-update-index(1)。默认为 keep，除非启用了 feature.manyFiles，这会将此设置默认为 true。

core.checkStat:: 当缺失或设置为 default 时，会检查 stat 结构中的许多字段以检测文件自 Git 上次查看以来是否被修改。当此配置变量设置为 minimal 时，mtime 和 ctime 的亚秒部分、文件所有者的 uid 和 gid、inode 号（以及设备号，如果 Git 编译为使用它）将从这些字段的检查中排除，只留下 mtime 的整秒部分（以及 ctime，如果设置了 core.trustCtime）和文件大小被检查。 + 有些 Git 实现在某些字段中不会留下可用的值（例如 JGit）；通过将这些字段排除在比较之外，minimal 模式可能有助于在同一仓库同时被这些其他系统使用时的互操作性。

core.quotePath:: 输出路径的命令（例如 'ls-files'、'diff'）将通过将路径名括在双引号中并用反斜杠转义那些字符来引用路径名中的"异常"字符，其方式与 C 转义控制字符（例如 \t 表示 TAB，\n 表示 LF，\\ 表示反斜杠）或值大于 0x80 的字节（例如八进制 \302\265 表示 UTF-8 中的 "micro"）相同。如果此变量设置为 false，高于 0x80 的字节不再被视为"异常"。双引号、反斜杠和控制字符无论此变量的设置如何都会被转义。简单的空格字符不被视为"异常"。许多命令可以使用 -z 选项完全按原样输出路径名。默认值为 true。

core.eol:: 设置在工作目录中标记为文本的文件使用的行结束类型（通过设置 text 属性，或通过设置 text=auto 并且 Git 自动检测内容为文本）。可选值为 'lf'、'crlf' 和 'native'（使用平台的原生行结束符）。默认值为 native。有关行结束转换的更多信息，请参见 gitattributes(5)。请注意，如果 core.autocrlf 设置为 true 或 input，则此值会被忽略。

core.safecrlf:: 如果为 true，当行结束转换处于活动状态时，Git 会检查转换 CRLF 是否可逆。Git 将验证命令是否直接或间接修改了工作树中的文件。 例如，提交一个文件然后签出同一个文件应该在工作树中产生原始文件。如果对于当前 core.autocrlf 设置不是这种情况，Git 将拒绝该文件。该变量可以设置为 "warn"，在这种情况下 Git 只会警告不可逆的转换但继续操作。 + CRLF 转换有轻微的数据损坏风险。启用后，Git 将在提交期间将 CRLF 转换为 LF，在签出期间将 LF 转换为 CRLF。在提交前包含 LF 和 CRLF 混合的文件无法由 Git 重新创建。对于文本文件，这是正确的做法：它纠正行结束符，使仓库中只有 LF 行结束符。但对于被错误分类为文本的二进制文件，转换可能会损坏数据。 + 如果您及早发现此类损坏，可以通过在 .gitattributes 中显式设置转换类型来轻松修复。提交后，您在工作树中仍有原始文件，该文件尚未损坏。您可以显式告诉 Git 该文件是二进制文件，Git 将适当处理该文件。 + 不幸的是，清理具有混合行结束符的文本文件的预期效果和损坏二进制文件的不良效果无法区分。在两种情况下，CRLF 都以不可逆的方式被移除。对于文本文件，这是正确的做法，因为 CRLF 是行结束符，而对于二进制文件，转换 CRLF 会损坏数据。 + 请注意，此安全检查并不意味着签出会为 core.eol 和 core.autocrlf 的不同设置生成与原始文件相同的文件，而仅适用于当前设置。例如，使用 core.eol=lf 将接受包含 LF 的文本文件，稍后可以使用 core.eol=crlf 签出，在这种情况下，结果文件将包含 CRLF，尽管原始文件包含 LF。然而，在两个工作树中，行结束符将是一致的，即全部为 LF 或全部为 CRLF，但不会混合。具有混合行结束符的文件将被 core.safecrlf 机制报告。

core.autocrlf:: 将此变量设置为 "true" 与在所有文件上设置 text 属性为 "auto" 并将 core.eol 设置为 "crlf" 相同。如果你想在工作目录中使用 CRLF 行结束符而仓库使用 LF 行结束符，请设置为 true。此变量可以设置为 'input'，此时不执行输出转换。

core.checkRoundtripEncoding:: 以逗号和/或空格分隔的编码列表，如果在 working-tree-encoding 属性中使用，Git 将对这些编码执行 UTF-8 往返检查（参见 gitattributes(5)）。默认值为 SHIFT-JIS。

core.symlinks:: 如果为 false，符号链接将作为包含链接文本的小纯文件签出。git-update-index(1) 和 git-add(1) 不会将记录的类型更改为常规文件。在不支持符号链接的文件系统（如 FAT）上很有用。 + 默认为 true，但 git-clone(1) 或 git-init(1) 会在创建仓库时探测并在适当时将 core.symlinks 设置为 false。

core.gitProxy:: 使用 Git 协议获取时，要执行的"代理命令"（格式为 'command host port'），而不是建立到远程服务器的直接连接。如果变量值为 "COMMAND for DOMAIN" 格式，则该命令仅应用于以指定域字符串结尾的主机名。此变量可以多次设置，并按给定顺序匹配；第一个匹配的获胜。 + 可以被 GIT_PROXY_COMMAND 环境变量覆盖（它始终普遍应用，没有特殊的 "for" 处理）。 + 特殊字符串 none 可以用作代理命令，以指定不将代理用于给定的域模式。这对于将防火墙内的服务器排除在代理使用之外很有用，同时对外部域默认使用通用代理。

core.sshCommand:: 如果设置了此变量，git fetch 和 git push 将在需要连接到远程系统时使用指定的命令而不是 ssh。该命令的格式与 GIT_SSH_COMMAND 环境变量相同，并在设置环境变量时被覆盖。

core.ignoreStat:: 如果为 true，Git 将通过为那些在索引和工作树中都相同更新的跟踪文件设置 "assume-unchanged" 位来避免使用 lstat() 调用检测文件是否已更改。 + 当文件在 Git 之外被修改时，用户需要显式地暂存修改的文件（例如参见 git-update-index(1) 中的 '示例' 部分）。Git 通常不会检测到这些文件的更改。 + 这在 lstat() 调用非常慢的系统上很有用，例如 CIFS/Microsoft Windows。 + 默认为 false。

core.preferSymlinkRefs:: 对于 HEAD 和其他符号引用文件，使用符号链接而不是默认的 "symref" 格式。这有时是与期望 HEAD 为符号链接的旧脚本一起工作所必需的。 + 此配置已弃用，将在 Git 3.0 中移除。符号引用将始终作为文本 symref 写入。

core.alternateRefsCommand:: 当从 alternate 公告可用历史的提示时，使用 shell 执行指定的命令而不是 git-for-each-ref(1)。第一个参数是 alternate 的绝对路径。输出必须每行包含一个十六进制对象 id（即与 git for-each-ref --format='%(objectname)' 产生的相同）。 + 请注意，通常不能将 git for-each-ref 直接放入配置值中，因为它不接受仓库路径作为参数（但您可以将上述命令包装在 shell 脚本中）。

core.alternateRefsPrefixes:: 从 alternate 列出引用时，仅列出以给定前缀开头的引用。前缀匹配方式与作为 git-for-each-ref(1) 的参数相同。要列出多个前缀，请用空格分隔。如果设置了 core.alternateRefsCommand，则设置 core.alternateRefsPrefixes 无效。

core.bare:: 如果为 true，则假定此仓库为"裸"仓库，没有关联的工作目录。如果是这种情况，许多需要工作目录的命令将被禁用，例如 git-add(1) 或 git-merge(1)。 + 此设置由 git-clone(1) 或 git-init(1) 在创建仓库时自动猜测。默认情况下，以 "/.git" 结尾的仓库假定为非裸仓库（bare = false），而所有其他仓库假定为裸仓库（bare = true）。

core.worktree:: 设置工作树根目录的路径。如果设置了 GIT_COMMON_DIR 环境变量，则 core.worktree 被忽略且不用于确定工作树的根目录。这可以被 GIT_WORK_TREE 环境变量和 --work-tree 命令行选项覆盖。该值可以是绝对路径或相对于 .git 目录的路径，该目录由 --git-dir 或 GIT_DIR 指定，或自动发现。如果指定了 --git-dir 或 GIT_DIR 但未指定 --work-tree、GIT_WORK_TREE 和 core.worktree，则当前工作目录被视为工作树的顶层。 + 请注意，即使在目录的 ".git" 子目录中的配置文件中设置此变量并且其值与后者目录不同（例如 "/path/to/.git/config" 的 core.worktree 设置为 "/different/path"），此变量也会被尊重，这很可能是配置错误。在 "/path/to" 目录中运行 Git 命令仍将使用 "/different/path" 作为工作树的根目录，并可能导致 混乱，除非你知道你在做什么（例如，你正在创建同一索引的只读快照到与仓库通常工作树不同的位置）。

core.lockfilePid:: 如果为 true，Git 将在锁文件旁边创建 PID 文件。当锁获取失败且 PID 文件存在时，Git 可以提供有关持有锁的进程的额外诊断信息，包括它是否仍在运行。默认为 false。 + PID 文件的命名方式是在 .lock 后缀之前插入 ~pid。例如，如果锁文件是 index.lock，PID 文件将是 index~pid.lock。该文件包含格式为 pid <value> 的单行，后跟换行符。

core.logAllRefUpdates:: 启用 reflog。对引用 <ref> 的更新将被记录到文件 "$GIT_DIR/logs/<ref>" 中，通过追加新的和旧的 SHA-1、日期/时间和更新原因，但仅在文件存在时。如果此配置变量设置为 true，则会自动为分支头（即在 refs/heads/ 下）、远程引用（即在 refs/remotes/ 下）、笔记引用（即在 refs/notes/ 下）和符号引用 HEAD 创建缺失的 "$GIT_DIR/logs/<ref>" 文件。如果设置为 always，则会自动为 refs/ 下的任何引用创建缺失的 reflog。 + 此信息可用于确定"2 天前"哪个提交是分支的顶端。 + 在有关联工作目录的仓库中，此值默认为 true，在裸仓库中默认为 false。

core.repositoryFormatVersion:: 标识仓库格式和布局版本的内部变量。参见 gitrepository-layout(5)。

core.sharedRepository:: 当为 'group'（或 'true'）时，仓库可在组中的多个用户之间共享（确保所有文件和对象都是组可写的）。当为 'all'（或 'world' 或 'everybody'）时，仓库将被所有用户可读，此外还可被组共享。当为 'umask'（或 'false'）时，Git 将使用 umask(2) 报告的权限。当为 '0xxx'（其中 '0xxx' 是八进制数）时，仓库中的文件将具有此模式值。'0xxx' 将覆盖用户的 umask 值（而其他选项将仅覆盖用户 umask 值的请求部分）。示例：'0660' 将使仓库对所有者和组可读/写，但对其他人不可访问（等同于 'group'，除非 umask 为例如 '0022'）。'0640' 是组可读但不是组可写的仓库。参见 git-init(1)。默认为 false。

core.warnAmbiguousRefs:: 如果为 true，当你传递的引用名称不明确且可能匹配仓库中的多个引用时，Git 会警告你。默认为 true。

core.compression:: 整数 -1..9，表示默认压缩级别。-1 是 zlib 默认值。0 表示不压缩，1..9 是各种速度/大小权衡，9 最慢。如果设置，这将为其他压缩变量提供默认值，例如 core.looseCompression 和 pack.compression。

core.looseCompression:: 整数 -1..9，表示不在包文件中的对象的压缩级别。-1 是 zlib 默认值。0 表示不压缩，1..9 是各种速度/大小权衡，9 最慢。如果未设置，默认为 core.compression。如果也未设置，默认为 1（最佳速度）。

core.packedGitWindowSize:: 在单个映射操作中映射到内存中的包文件的字节数。较大的窗口大小可能允许你的系统更快地处理较少数量的大型包文件。较小的窗口大小由于对操作系统内存管理器的调用增加而会对性能产生负面影响，但在访问大量大型包文件时可能会提高性能。 + 如果在编译时设置了 NO_MMAP，默认为 1 MiB，否则在 32 位平台上为 32 MiB，在 64 位平台上为 1 GiB。这对所有用户/操作系统应该是合理的。您可能不需要调整此值。 + 支持常见的单位后缀 'k'、'm' 或 'g'。

core.packedGitLimit:: 从包文件同时映射到内存的最大字节数。如果 Git 需要一次访问超过此字节数来完成操作，它将取消映射现有区域以回收进程内的虚拟地址空间。 + 在 32 位平台上默认为 256 MiB，在 64 位平台上为 32 TiB（实际上无限制）。这对所有用户/操作系统应该是合理的，除了最大的项目。您可能不需要调整此值。 + 支持常见的单位后缀 'k'、'm' 或 'g'。

core.deltaBaseCacheLimit:: 每个线程为缓存可能被多个增量对象引用的基础对象而保留的最大字节数。通过将整个解压缩的基础对象存储在缓存中，Git 能够避免多次解包和解压缩频繁使用的基础对象。 + 在所有平台上默认为 96 MiB。这对所有用户/操作系统应该是合理的，除了最大的项目。您可能不需要调整此值。 + 支持常见的单位后缀 'k'、'm' 或 'g'。

core.bigFileThreshold:: 被视为"大"文件的大小，如下所述，这会改变许多 git 命令的行为，以及这些文件在仓库中的存储方式。默认为 512 MiB。支持常见的单位后缀 'k'、'm' 或 'g'。 + 超过配置限制的文件将： +

• 以压缩形式存储在包文件中，不尝试增量压缩。

默认限制主要考虑此用例。有了它，大多数项目的源代码和其他文本文件将进行增量压缩，但较大的二进制媒体文件不会。 + 存储大文件而不进行增量压缩可以避免过度的内存使用，代价是磁盘使用略有增加。 +

• 将被视为标记为 "binary"（参见 gitattributes(5)）。例如 git-log(1) 和 git-diff(1) 将不会计算超过此限制的文件的差异。

• 写入时通常会以流式传输，这避免了过度的内存使用，代价是一些固定开销。使用此功能的命令包括 git-archive(1)、git-fast-import(1)、git-index-pack(1)、git-unpack-objects(1) 和 git-fsck(1)。

core.excludesFile:: 指定包含描述不应被跟踪的路径的模式的文件的路径名，除了 .gitignore（每目录）和 .git/info/exclude。默认为 $XDG_CONFIG_HOME/git/ignore。如果 $XDG_CONFIG_HOME 未设置或为空，则使用 $HOME/.config/git/ignore。参见 gitignore(5)。

core.askPass:: 一些交互式询问密码的命令（例如 svn 和 http 接口）可以被告知使用通过此变量的值给出的外部程序。可以被 GIT_ASKPASS 环境变量覆盖。如果未设置，则回退到 SSH_ASKPASS 环境变量的值，如果也失败，则使用简单的密码提示。外部程序将获得适当的提示作为命令行参数，并将密码写入其 STDOUT。

core.attributesFile:: 指定包含属性的文件的路径名（参见 gitattributes(5)），除了 .gitattributes（每目录）和 .git/info/attributes。其默认值为 $XDG_CONFIG_HOME/git/attributes。如果 $XDG_CONFIG_HOME 未设置或为空，则使用 $HOME/.config/git/attributes。

core.hooksPath:: 默认情况下，Git 将在 $GIT_DIR/hooks 目录中查找你的钩子。将此设置为不同的路径，例如 /etc/git/hooks，Git 将尝试在该目录中查找你的钩子，例如 /etc/git/hooks/pre-receive 而不是 $GIT_DIR/hooks/pre-receive。 + 路径可以是绝对路径或相对路径。相对路径被视为相对于钩子运行的目录（参见 githooks(5) 的"描述"部分）。 + 此配置变量在您希望集中配置 Git 钩子而不是按仓库配置时很有用，或者作为更灵活和集中的替代方案来替代使用 init.templateDir 更改默认钩子。 + 您也可以通过将 core.hooksPath 设置为 /dev/null 来完全禁用所有钩子。这通常仅建议专家用户使用，并且按命令使用以下形式的配置参数：git -c core.hooksPath=/dev/null ...。

core.editor:: 诸如 commit 和 tag 之类允许您通过启动编辑器来编辑消息的命令，在设置了此变量且未设置环境变量 GIT_EDITOR 时使用此变量的值。参见 git-var(1)。

core.commentChar:: core.commentString:: 允许你编辑消息的命令（如 commit 和 tag）将以此字符开头的行视为注释，并在编辑器返回后删除它们（默认为 '#'）。 + ifndef::with-breaking-changes[] 如果设置为 "auto"，git-commit 将选择一个不是现有提交消息中任何行的起始字符的字符。对此值的支持已弃用，将在 Git 3.0 中移除，原因是以下限制：

* git notes 不遵循此设置

endif::with-breaking-changes[] 请注意，这两个变量是彼此的别名，在现代版本的 Git 中你可以自由地将字符串（例如 // 或 ⁑⁕⁑）与 commentChar 一起使用。v2.45.0 之前的 Git 版本将忽略 commentString，但会拒绝由超过单个 ASCII 字节组成的 commentChar 值。如果你计划将配置与旧版本和新版本的 Git 一起使用，你可能需要同时指定两者： + [core] # single character for older versions commentChar = "#" # string for newer versions (which will override commentChar # because it comes later in the file) commentString = "//"

core.filesRefLockTimeout:: 尝试锁定单个引用时重试的时间长度（以毫秒为单位）。值 0 表示根本不重试；-1 表示无限期尝试。默认为 100（即重试 100ms）。

core.packedRefsTimeout:: 尝试锁定 packed-refs 文件时重试的时间长度（以毫秒为单位）。值 0 表示根本不重试；-1 表示无限期尝试。默认为 1000（即重试 1 秒）。

core.pager:: Git 命令使用的文本查看器（例如 'less'）。该值旨在由 shell 解释。优先顺序是 $GIT_PAGER 环境变量，然后是 core.pager 配置，然后是 $PAGER，然后是编译时选择的默认值（通常是 'less'）。 + 当 LESS 环境变量未设置时，Git 将其设置为 FRX（如果 LESS 环境变量已设置，Git 完全不会更改它）。如果你想选择性地覆盖 Git 对 LESS 的默认设置，你可以将 core.pager 设置为例如 less -S。这将由 Git 传递给 shell，它将把最终命令转换为 LESS=FRX less -S。环境不设置 S 选项，但命令行设置了，指示 less 截断长行。类似地，将 core.pager 设置为 less -+F 将从命令行停用环境指定的 F 选项，停用 less 的"一屏即退"行为。可以为特定命令激活某些标志：例如，将 pager.blame 设置为 less -S 仅为 git blame 启用行截断。 + 同样，当 LV 环境变量未设置时，Git 将其设置为 -c。您可以通过导出另一个值的 LV 或将 core.pager 设置为 lv +c 来覆盖此设置。

core.whitespace:: 以逗号分隔的常见空白问题列表，用于注意。'git diff' 将使用 color.diff.whitespace 高亮它们，'git apply --whitespace=error' 将将它们视为错误。您可以在前面加上 - 来禁用任何一项（例如 -trailing-space）： +

• blank-at-eol 将行尾的尾随空白视为错误（默认启用）。
• space-before-tab 将行初始缩进部分中制表符前紧邻的空格字符视为错误（默认启用）。
• indent-with-non-tab 将使用空格字符而不是等效制表符缩进的行视为错误（默认未启用）。
• tab-in-indent 将行初始缩进部分中的制表符字符视为错误（默认未启用）。
• blank-at-eof 将文件末尾添加的空行视为错误（默认启用）。
• trailing-space 是涵盖 blank-at-eol 和 blank-at-eof 的简写。
• cr-at-eol 将行尾的回车符视为行终止符的一部分，即使用它时，如果此类回车符前的字符不是空白，则 trailing-space 不会触发（默认未启用）。
• incomplete-line 将缺少末尾换行符的文件最后一行视为错误（默认未启用）。
• tabwidth=<n> 告诉制表符占据多少字符位置；这与 indent-with-non-tab 以及 Git 修复 tab-in-indent 错误时相关。默认制表符宽度为 8。允许的值为 1 到 63。

core.fsync:: 以逗号分隔的仓库组件列表，在创建或修改时应通过 core.fsyncMethod 进行加固。您可以通过在前面加上 '-' 来禁用任何组件的加固。未加固的项目可能在系统非正常关闭时丢失。除非您有特殊要求，否则建议将此选项留空或选择 committed、added 或 all 之一。 + 遇到此配置时，组件集从平台默认值开始，禁用的组件被移除，并添加额外的组件。none 重置状态，使平台默认值被忽略。 + 空字符串将 fsync 配置重置为平台默认值。大多数平台上的默认值等同于 core.fsync=committed,-loose-object，具有良好的性能，但在系统非正常关闭时有丢失最近工作的风险。 +

• none 清除 fsync 组件集。
• loose-object 加固以松散对象形式添加到仓库的对象。
• pack 加固以包文件形式添加到仓库的对象。
• pack-metadata 加固包文件位图和索引。
• commit-graph 加固提交图文件。
• index 在索引被修改时加固索引。
• objects 是等同于 loose-object,pack 的聚合选项。
• reference 加固在仓库中修改的引用。
• derived-metadata 是等同于 pack-metadata,commit-graph 的聚合选项。
• committed 是当前等同于 objects 的聚合选项。此模式牺牲一些性能以确保通过 git commit 或类似命令提交到仓库的工作被加固。
• added 是当前等同于 committed,index 的聚合选项。此模式牺牲额外性能以确保 git add 和类似操作的结果被加固。
• all 是同步上述所有单独组件的聚合选项。

core.fsyncMethod:: 指示 Git 将用于使用 fsync 和相关原语加固仓库数据的策略的值。 +

• fsync 使用 fsync() 系统调用或平台等效调用。
• writeout-only 发出页面缓存回写请求，但根据文件系统和存储硬件，添加到仓库的数据在系统崩溃时可能不持久。这是 macOS 上的默认模式。
• batch 启用一种模式，使用仅写出刷新在磁盘回写缓存中暂存多个更新，然后对虚拟文件执行单次完整 fsync 以在操作结束时触发磁盘缓存刷新。

目前 batch 模式仅适用于松散对象文件。其他仓库数据的持久化方式与 fsync 相同。此模式预计在 macOS 上对于存储在 HFS+ 或 APFS 文件系统上的仓库与 fsync 一样安全，在 Windows 上对于存储在 NTFS 或 ReFS 文件系统上的仓库也是如此。

core.fsyncObjectFiles:: 此布尔值将在写入对象文件时启用 'fsync()'。此设置已弃用。请改用 core.fsync。 + 此设置影响以松散对象形式添加到 Git 仓库的数据。设置为 true 时，Git 将发出 fsync 或类似系统调用以刷新缓存，使松散对象在系统非正常关闭时保持一致。

core.preloadIndex:: 为 'git diff' 等操作启用并行索引预加载。 + 这可以加速 'git diff' 和 'git status' 等操作，特别是在 NFS 等具有弱缓存语义和因此相对高 IO 延迟的文件系统上。启用后，Git 将并行执行与文件系统数据的索引比较，允许重叠 IO。默认为 true。

core.unsetenvvars:: 仅 Windows：以逗号分隔的环境变量名称列表，在生成任何其他进程之前需要取消设置。默认为 PERL5LIB，以考虑 Git for Windows 坚持使用自己的 Perl 解释器的事实。

core.createObject:: 您可以将其设置为 'link'，在这种情况下，使用硬链接后跟删除源来确保对象创建不会覆盖现有对象。 + 在某些文件系统/操作系统组合上，这不可靠。在那里将此配置设置为 'rename'；但是，这将移除确保现有对象文件不会被覆盖的检查。

core.notesRef:: 显示提交消息时，还显示存储在给定引用中的笔记。引用必须是完全限定的。如果给定的引用不存在，这不是错误，但意味着不应打印任何笔记。 + 此设置默认为 "refs/notes/commits"，可以通过 GIT_NOTES_REF 环境变量覆盖。参见 git-notes(1)。

core.commitGraph:: 如果为 true，则 git 将读取提交图文件（如果存在）以解析提交的图结构。默认为 true。参见 git-commit-graph(1) 获取更多信息。

core.useReplaceRefs:: 如果设置为 false，则表现为在命令行给出了 --no-replace-objects 选项。参见 git(1) 和 git-replace(1) 获取更多信息。

core.multiPackIndex:: 使用 multi-pack-index 文件通过单个索引跟踪多个包文件。参见 git-multi-pack-index(1) 获取更多信息。默认为 true。

core.sparseCheckout:: 启用"稀疏检出"功能。参见 git-sparse-checkout(1) 获取更多信息。

core.sparseCheckoutCone:: 启用稀疏检出功能的"锥形模式"。当稀疏检出文件包含有限的模式集时，此模式提供显著的性能优势。可以通过将此变量设置为 'false' 来请求"非锥形模式"以允许指定更灵活的模式。参见 git-sparse-checkout(1) 获取更多信息。

core.abbrev:: 设置对象名称缩写的长度。如果未指定或设置为 "auto"，将根据仓库中打包对象的大致数量计算适当的值，希望这足以使缩写对象名称在一段时间内保持唯一。如果设置为 "no"，则不进行缩写，对象名称以其完整长度显示。最小长度为 4。

core.maxTreeDepth:: Git 遍历树时愿意递归的最大深度（例如 "a/b/cde/f" 的深度为 4）。这是一个安全措施，允许 Git 干净地中止，通常不需要调整。当 Git 使用 MSVC 编译时，默认为 512。否则，默认为 2048。

credential.helper:: 指定需要用户名或密码凭据时调用的外部帮助程序；帮助程序可以咨询外部存储以避免提示用户输入凭据。这通常是凭据帮助程序的名称（可能带有参数），但也可能是带参数的绝对路径，或者如果前面有 !，则为 shell 命令。 + 请注意，可以定义多个帮助程序。详见 gitcredentials(7)。

credential.interactive:: 默认情况下，Git 和任何配置的凭据帮助程序在需要新凭据时会要求用户输入。如果存储的凭据仍然有效，其中许多帮助程序将基于存储的凭据成功。要避免 Git 的用户交互可能性，请设置 credential.interactive=false。某些凭据帮助程序也会尊重此选项。

credential.useHttpPath:: 获取凭据时，将 http 或 https URL 的"路径"组件视为重要。默认为 false。参见 gitcredentials(7) 获取更多信息。

credential.sanitizePrompt:: 默认情况下，作为密码提示一部分显示的用户名和主机名不允许包含控制字符（默认会进行 URL 编码）。将此设置配置为 false 可覆盖该行为。

credential.protectProtocol:: 默认情况下，Git 与凭据帮助程序通信时使用的协议中不允许使用回车符。此设置允许用户覆盖此默认值。

credential.username:: 如果未为网络认证设置用户名，则默认使用此用户名。参见下面的 credential.<context>.* 和 gitcredentials(7)。

credential.<url>.:: 上面的任何 credential. 选项都可以选择性地应用于某些凭据。例如，"credential.https://example.com.username" 将仅为到 example.com 的 https 连接设置默认用户名。有关 URL 如何匹配的详细信息，请参见 gitcredentials(7)。

credentialCache.ignoreSIGHUP:: 告诉 git-credential-cache--daemon 忽略 SIGHUP，而不是退出。

credentialStore.lockTimeoutMS:: git-credential-store 在尝试锁定凭据文件时重试的时间长度（以毫秒为单位）。值 0 表示根本不重试；-1 表示无限期尝试。默认为 1000（即重试 1 秒）。

diff.autoRefreshIndex:: 使用 git diff 与工作树文件比较时，不要将仅 stat 的更改视为已更改。而是静默运行 git update-index --refresh 以更新其内容在工作树中与索引中匹配的路径的缓存 stat 信息。此选项默认为 true。请注意，这只影响 git diff Porcelain，而不影响较低级别的 diff 命令，如 git diff-files。

diff.dirstat:: ifdef::git-diff[] 以逗号分隔的 --dirstat 参数列表，指定 git diff 及其相关命令的 --dirstat 选项的默认行为。 endif::git-diff[] ifndef::git-diff[] 以逗号分隔的 --dirstat 参数列表，指定 git-diff(1) 及其相关命令的 --dirstat 选项的默认行为。 endif::git-diff[] 默认值可以在命令行上覆盖（使用 --dirstat=<param>,...）。回退默认值（当未被 diff.dirstat 更改时）为 changes,noncumulative,3。以下参数可用：

不在输出中显示。

示例：以下将计算更改的文件数，同时忽略更改文件总数少于 10% 的目录，并在父目录中累积子目录计数：files,10,cumulative。

diff.statNameWidth:: 限制 --stat 输出中文件名部分的宽度。如果设置，适用于所有生成 --stat 输出的命令，除了 format-patch。

diff.statGraphWidth:: 限制 --stat 输出中图形部分的宽度。如果设置，适用于所有生成 --stat 输出的命令，除了 format-patch。

diff.context:: 生成具有 <n> 行上下文的差异，而不是默认的 3 行。此值被 -U 选项覆盖。

diff.interHunkContext:: 显示差异块之间的上下文，最多到指定的行数，从而融合彼此接近的块。此值作为 --inter-hunk-context 命令行选项的默认值。

diff.external:: 如果设置了此配置变量，则不使用内部差异机制生成差异，而是使用给定的命令。可以用 GIT_EXTERNAL_DIFF 环境变量覆盖。命令以 git(1) 中"git Diffs"下描述的参数调用。注意：如果您只想对部分文件使用外部差异程序，您可能需要改用 gitattributes(5)。

diff.trustExitCode:: 如果此布尔值设置为 true，则 diff.external 命令期望在认为输入文件相等时返回退出码 0，在认为它们不同时返回 1，就像 diff(1) 一样。如果设置为 false（默认值），则命令期望无论是否相等都返回退出码 0。任何其他退出码都会导致 Git 报告致命错误。

diff.ignoreSubmodules:: 设置 --ignore-submodules 的默认值。请注意，这只影响 git diff Porcelain，而不影响较低级别的 diff 命令，如 git diff-files。git checkout 和 git switch 在报告未提交的更改时也会尊重此设置。将其设置为 all 会禁用 git commit 和 git status 在设置 status.submoduleSummary 时通常显示的子模块摘要，除非使用 --ignore-submodules 命令行选项覆盖。git submodule 命令不受此设置影响。默认设置为 untracked，以便忽略任何未跟踪的子模块。

diff.mnemonicPrefix:: 如果设置，git diff 使用根据正在比较的内容而不同于标准 a/ 和 b/ 的前缀对。当此配置生效时，反向差异输出也会交换前缀的顺序： git diff;; 比较 (i)ndex 和 (w)ork tree； git diff HEAD;; 比较 (c)ommit 和 (w)ork tree； git diff --cached;; 比较 (c)ommit 和 (i)ndex； git diff HEAD:<file1> <file2>;; 比较 (o)bject 和 (w)ork tree 实体； git diff --no-index <a> <b>;; 比较两个非 git 事物 <a> 和 <b>。

diff.noPrefix:: 如果设置，git diff 不显示任何源或目标前缀。

diff.srcPrefix:: 如果设置，git diff 使用此源前缀。默认为 a/。

diff.dstPrefix:: 如果设置，git diff 使用此目标前缀。默认为 b/。

diff.relative:: 如果设置为 true，git diff 不显示目录外的更改并显示相对于当前目录的路径名。

diff.orderFile:: 指示如何在差异中排序文件的文件。 ifdef::git-diff[] 详见 -O 选项。 endif::git-diff[] ifndef::git-diff[] 详见 git-diff(1) 的 -O 选项。 endif::git-diff[] 如果 diff.orderFile 是相对路径名，则将其视为相对于工作树顶部。

diff.renameLimit:: 在复制/检测的详尽部分中要考虑的文件数量；等同于 git diff 选项 -l。如果未设置，默认值目前为 1000。如果关闭了重命名检测，此设置无效。

diff.renames:: Git 是否以及如何检测重命名。如果设置为 false，则禁用重命名检测。如果设置为 true，则启用基本重命名检测。如果设置为 copies 或 copy，Git 也将检测复制。默认为 true。请注意，这只影响 git-diff(1) 和 git-log(1) 等 git diff Porcelain，而不影响 git-diff-files(1) 等较低级别命令。

diff.suppressBlankEmpty:: 布尔值，抑制在每个空输出行前打印空格的标准行为。默认为 false。

diff.submodule:: 指定显示子模块差异的格式。short 格式仅显示范围开始和结束的提交名称。log 格式像 git-submodule(1) summary 一样列出范围中的提交。diff 格式显示更改内容的内联差异。默认为 short。

diff.wordRegex:: 在执行逐字差异计算时用于确定什么是"单词"的 POSIX 扩展正则表达式。匹配正则表达式的字符序列是"单词"，所有其他字符是可忽略的空白。

diff.<driver>.command:: 自定义差异驱动程序命令。详见 gitattributes(5)。

diff.<driver>.trustExitCode:: 如果此布尔值设置为 true，则 diff.<driver>.command 命令期望在认为输入文件相等时返回退出码 0，在认为它们不同时返回 1，就像 diff(1) 一样。如果设置为 false（默认值），则命令期望无论是否相等都返回退出码 0。任何其他退出码都会导致 Git 报告致命错误。

diff.<driver>.xfuncname:: 差异驱动程序应用于识别块头的正则表达式。也可以使用内置模式。详见 gitattributes(5)。

diff.<driver>.binary:: 将此选项设置为 true 以使差异驱动程序将文件视为二进制。详见 gitattributes(5)。

diff.<driver>.textconv:: 差异驱动程序应调用以生成文件的文本转换版本的命令。转换的结果用于生成人类可读的差异。详见 gitattributes(5)。

diff.<driver>.wordRegex:: 差异驱动程序应用于在一行中拆分单词的正则表达式。详见 gitattributes(5)。

diff.<driver>.cachetextconv:: 将此选项设置为 true 以使差异驱动程序缓存文本转换输出。详见 gitattributes(5)。

diff.indentHeuristic:: 将此选项设置为 false 以禁用默认启发式，该启发式会移动差异块边界以使补丁更易读。

diff.algorithm:: 选择差异算法。变体如下：

低出现率公共元素"。

diff.wsErrorHighlight:: 在差异的 context、old 或 new 行中高亮空白错误。多个值用逗号分隔，none 重置先前的值，default 将列表重置为 new，all 是 old,new,context 的简写。空白错误使用 color.diff.whitespace 着色。命令行选项 --ws-error-highlight=<kind> 覆盖此设置。

diff.colorMoved:: 如果设置为有效的 <mode> 或 true 值，差异中移动的行将以不同颜色着色。 ifdef::git-diff[] 有关有效模式的详情，请参见 --color-moved。 endif::git-diff[] ifndef::git-diff[] 有关有效模式的详情，请参见 git-diff(1) 中的 --color-moved。 endif::git-diff[] 如果简单设置为 true，将使用默认颜色模式。设置为 false 时，移动的行不会着色。

diff.colorMovedWS:: 当使用例如 diff.colorMoved 设置为移动的行着色时，此选项控制处理空格的模式。有关有效模式的详情，请参见 git-diff(1) 中的 --color-moved-ws。

diff.tool:: 控制 git-difftool(1) 使用哪个差异工具。此变量覆盖在 merge.tool 中配置的值。下面的列表显示了有效的内置值。任何其他值被视为自定义差异工具，需要定义相应的 difftool.<tool>.cmd 变量。

diff.guitool:: 控制 git-difftool(1) 在给出 -g/--gui 标志时使用哪个差异工具。此变量覆盖在 merge.guitool 中配置的值。下面的列表显示了有效的内置值。任何其他值被视为自定义差异工具，需要定义相应的 difftool.<guitool>.cmd 变量。

<!-- 包含文件不存在: {build_dir}/mergetools-diff.adoc --> difftool.<tool>.cmd:: 指定调用指定差异工具的命令。指定的命令在 shell 中求值，以下变量可用：LOCAL 设置为包含差异前像内容的临时文件名称，REMOTE 设置为包含差异后像内容的临时文件名称。 + 详见 git-difftool(1) 中的 --tool=<tool> 选项。

difftool.<tool>.path:: 覆盖给定工具的路径。当您的工具不在 PATH 中时很有用。

difftool.trustExitCode:: 如果调用的差异工具返回非零退出状态，则退出 difftool。 + 详见 git-difftool(1) 中的 --trust-exit-code 选项。

difftool.prompt:: 每次调用差异工具前提示。

difftool.guiDefault:: 设置 true 以默认使用 diff.guitool（等同于指定 --gui 参数），或 auto 根据 DISPLAY 环境变量值的存在选择 diff.guitool 或 diff.tool。默认为 false，必须显式提供 --gui 参数才能使用 diff.guitool。

extensions.*:: 除非另有说明，如果 core.repositoryFormatVersion 不是 1，则指定扩展是错误的。参见 gitrepository-layout(5)。 + compatObjectFormat::: 指定要使用的兼容哈希算法。可接受的值为 sha1 和 sha256。指定的值必须与 extensions.objectFormat 的值不同。这允许对象格式与此兼容对象格式匹配的 Git 仓库之间的客户端级互操作性。特别是当完全实现时，可以从对象格式与兼容对象格式匹配的仓库进行推送和拉取。以及能够在本地指定对象时使用以兼容对象格式编码的对象 ID，而不仅仅是使用对象格式编码的对象 ID。 + 请注意，此扩展启用的功能不完整且可能会更改。目前仅用于允许底层功能的开发和测试，不打算由最终用户启用。

noop::: 此扩展完全不改变 git 的行为。它仅用于测试格式 1 兼容性。 + 由于历史原因，无论 core.repositoryFormatVersion 设置如何，都会遵守此扩展。

noop-v1::: 此扩展完全不改变 git 的行为。它仅用于测试格式 1 兼容性。

objectFormat::: 指定要使用的哈希算法。可接受的值为 sha1 和 sha256。如果未指定，则假定为 sha1。 + 请注意，此设置应仅由 git-init(1) 或 git-clone(1) 设置。尝试在初始化后更改它将不起作用，并会产生难以诊断的问题。

partialClone::: 启用时，表示仓库是通过部分克隆创建的（或后来执行了部分获取），并且远程可能已省略发送某些不需要的对象。这样的远程称为"承诺者远程"，它承诺所有此类省略的对象将来都可以从它那里获取。 + 此键的值是承诺者远程的名称。 + 由于历史原因，无论 core.repositoryFormatVersion 设置如何，都会遵守此扩展。

preciousObjects::: 如果启用，表示仓库中的对象不得被删除（例如通过 git-prune 或 git repack -d）。 + 由于历史原因，无论 core.repositoryFormatVersion 设置如何，都会遵守此扩展。

refStorage::: 指定引用存储格式和相应的有效负载。值可以是格式名称或 URI：

其他有效负载方案，例如 postgres://127.0.0.1:5432?database=myrepo。

请注意，此设置应仅由 git-init(1) 或 git-clone(1) 设置。尝试在初始化后更改它将不起作用，并会产生难以诊断的问题。

relativeWorktrees::: 如果启用，表示至少一个工作树已使用相对路径链接。如果使用 --relative-paths 选项或将 worktree.useRelativePaths 配置设置为 true 创建或修复了工作树，则会自动设置。

submodulePathConfig::: 此扩展适用于少数用户：

使用 .git/modules/<plain-name> 位置，导致进一步冲突。

启用 extensions.submodulePathConfig 时，submodule.<name>.gitdir 配置成为所有子模块 gitdir 路径的唯一真实来源，并在克隆和初始化操作期间自动为所有新子模块设置。 + 如果模块没有相应的 submodule.<name>.gitdir 设置，Git 将报错。 + 现有（扩展前）子模块需要通过添加缺失的配置条目来迁移。可以手动完成，例如为每个子模块：git config submodule.<name>.gitdir .git/modules/<name>，或通过 git submodule--helper migrate-gitdir-configs 命令迭代所有子模块并尝试迁移它们。 + 可以通过将 init.defaultSubmodulePathConfig 设置为 true 来自动为新仓库启用此扩展，例如通过运行 git config --global init.defaultSubmodulePathConfig true。

worktreeConfig::: 如果启用，工作树将从 $GIT_DIR/config.worktree 文件和 $GIT_COMMON_DIR/config 文件加载配置设置。请注意，对于主工作树，$GIT_COMMON_DIR 和 $GIT_DIR 是相同的，而其他工作树的 $GIT_DIR 等于 $GIT_COMMON_DIR/worktrees/<id>/。config.worktree 文件中的设置将覆盖任何其他配置文件的设置。 + 启用此扩展时，必须小心将某些值从公共配置文件移动到主工作树的 config.worktree 文件（如果存在）：

到 $GIT_COMMON_DIR/config.worktree。

根据您对每个工作树可自定义稀疏检出设置的期望，调整 core.sparseCheckout 和 core.sparseCheckoutCone 的位置也可能有益。默认情况下，git sparse-checkout 内置命令启用此扩展，在每个工作树基础上分配这些配置值，并使用 $GIT_DIR/info/sparse-checkout 文件为每个工作树独立指定稀疏度。详见 git-sparse-checkout(1)。 + 由于历史原因，无论 core.repositoryFormatVersion 设置如何，都会遵守此扩展。

fastimport.unpackLimit:: 如果 git-fast-import(1) 导入的对象数量低于此限制，则对象将被解包为松散对象文件。然而，如果导入的对象数量等于或超过此限制，则包将作为包存储。存储来自快速导入的包可以使导入操作完成更快，特别是在慢速文件系统上。如果未设置，则使用 transfer.unpackLimit 的值。

feature.*:: 以 feature. 开头的配置设置会修改一组其他配置设置的默认值。这些组由 Git 开发者社区创建为推荐默认值，可能会更改。特别是，可能会添加具有不同默认值的新配置选项。

feature.experimental:: 启用 Git 新增的配置选项，这些选项正在考虑作为未来的默认值。此处包含的配置设置可能在每个版本（包括次要版本更新）中添加或移除。这些设置可能具有意外的交互，因为它们是全新的。如果您有兴趣提供有关实验功能的反馈，请启用此设置。新的默认值为： +

• fetch.negotiationAlgorithm=skipping 可能通过一次跳过更多提交来改善获取协商时间，减少往返次数。

• pack.useBitmapBoundaryTraversal=true 可能通过遍历更少的对象来改善位图遍历时间。

• pack.allowPackReuse=multi 可能通过重用多个包（而不仅仅是一个）中的对象来改善创建包所需的时间。

• pack.usePathWalk 可能加速包文件创建，并在存在某些文件名与 Git 默认名称哈希冲突的情况下使包文件显著更小。

• init.defaultRefFormat=reftable 导致新初始化的仓库使用 reftable 格式存储引用。此新格式解决了不区分大小写的文件系统的问题，压缩更好，并在许多用例中表现显著更好。有关此新存储格式的更多信息，请参阅 Documentation/technical/reftable.adoc。

feature.manyFiles:: 启用优化具有工作目录中许多文件的仓库的配置选项。文件较多时，git status 和 git checkout 等命令可能较慢，这些新默认值可提高性能： +

• 查看差异。skipHash=true 通过不计算尾随校验和来加速索引写入。请注意，这将导致 Git 2.13.0 之前的版本拒绝解析索引，Git 2.40.0 之前的版本将在 git fsck 期间报告损坏的索引。

• 查看差异。version=4 在索引中启用路径前缀压缩。

• core.untrackedCache=true 启用未跟踪缓存。此设置假定您的机器上 mtime 正常工作。

fetch.recurseSubmodules:: 此选项控制 git fetch（以及 git pull 中的底层获取）是否递归获取到已填充的子模块中。此选项可以设置为布尔值或 on-demand。设置为布尔值会无条件地更改获取和拉取的行为，为 true 时递归到子模块，为 false 时完全不递归。设置为 on-demand 时，获取和拉取仅在子模块的超级项目检索到更新子模块引用的提交时才递归到已填充的子模块中。默认为 on-demand，或如果设置了 submodule.recurse 则为其值。

fetch.fsckObjects:: 如果设置为 true，git-fetch-pack 将检查所有获取的对象。详见 transfer.fsckObjects 了解检查内容。默认为 false。如果未设置，则使用 transfer.fsckObjects 的值。

fetch.fsck.<msg-id>:: 类似于 fsck.<msg-id>，但由 git-fetch-pack(1) 而不是 git-fsck(1) 使用。详见 fsck.<msg-id> 文档。

fetch.fsck.skipList:: 类似于 fsck.skipList，但由 git-fetch-pack(1) 而不是 git-fsck(1) 使用。详见 fsck.skipList 文档。

fetch.unpackLimit:: 如果通过 Git 原生传输获取的对象数量低于此限制，则对象将被解包为松散对象文件。然而，如果接收的对象数量等于或超过此限制，则接收的包将作为包存储，添加任何缺失的增量基。存储来自推送的包可以使推送操作完成更快，特别是在慢速文件系统上。如果未设置，则使用 transfer.unpackLimit 的值。

fetch.prune:: 如果为 true，获取将自动表现为在命令行给出了 --prune 选项。另见 remote.<name>.prune 和 git-fetch(1) 的修剪部分。

fetch.pruneTags:: 如果为 true，获取在修剪时将自动表现为提供了 refs/tags/*:refs/tags/* refspec（如果尚未设置）。这允许同时设置此选项和 fetch.prune 以维护与上游引用的 1:1 映射。另见 remote.<name>.pruneTags 和 git-fetch(1) 的修剪部分。

fetch.all:: 如果为 true，获取将尝试更新所有可用的远程。可以通过传递 --no-all 或显式指定一个或多个远程来覆盖此行为。默认为 false。

fetch.output:: 控制如何打印引用更新状态。有效值为 full 和 compact。默认值为 full。详见 git-fetch(1) 的输出部分。

fetch.negotiationAlgorithm:: 控制在协商服务器发送的包文件内容时，如何发送有关本地仓库中提交的信息。设置为 consecutive 以使用遍历连续提交并检查每个提交的算法。设置为 skipping 以使用跳过提交以努力更快收敛的算法，但可能导致大于必要的包文件；或设置为 noop 完全不发送任何信息，这几乎肯定会导致大于必要的包文件，但会跳过协商步骤。设置为 default 以覆盖先前的设置并使用默认行为。默认通常为 consecutive，但如果 feature.experimental 为 true，则默认为 skipping。未知值将导致 git fetch 报错。 + 另见 git-fetch(1) 的 --negotiate-only 和 --negotiation-restrict 选项。

fetch.showForcedUpdates:: 设置为 false 以在 git-fetch(1) 和 git-pull(1) 命令中启用 --no-show-forced-updates。默认为 true。

fetch.parallel:: 指定一次并行运行的最大获取操作数（子模块，或当 git-fetch(1) 的 --multiple 选项生效时的远程）。 + 值为 0 将给出一些合理的默认值。如果未设置，默认为 1。 + 对于子模块，此设置可以使用 submodule.fetchJobs 配置设置覆盖。

fetch.writeCommitGraph:: 设置为 true 以在每次 git fetch 命令从远程下载包文件后写入提交图。使用 --split 选项，大多数执行将在现有提交图文件之上创建一个非常小的提交图文件。偶尔这些文件会合并，写入可能需要更长时间。拥有更新的提交图文件有助于许多 Git 命令的性能，包括 git merge-base、git push -f 和 git log --graph。默认为 false。

fetch.bundleURI:: 此值存储用于在从原始 Git 服务器执行增量获取之前从包 URI 下载 Git 对象数据的 URI。这类似于 git-clone(1) 中 --bundle-uri 选项的行为。如果提供的包 URI 包含为增量获取组织的包列表，git clone --bundle-uri 将设置 fetch.bundleURI 值。 + 如果您修改此值并且您的仓库有 fetch.bundleCreationToken 值，请在从新包 URI 获取之前移除该 fetch.bundleCreationToken 值。

fetch.bundleCreationToken:: 当使用 fetch.bundleURI 从使用 "creationToken" 启发式的包列表增量获取时，此配置值存储已下载包的最大 creationToken 值。此值用于防止将来下载包，如果公布的 creationToken 不严格大于此值。 + 创建令牌值由服务特定包 URI 的提供者选择。如果您在 fetch.bundleURI 处修改了 URI，请确保在获取之前移除 fetch.bundleCreationToken 的值。

filter.<driver>.clean:: 用于在签入时将工作树文件内容转换为 blob 的命令。详见 gitattributes(5)。

filter.<driver>.smudge:: 用于在签出时将 blob 对象内容转换为工作树文件的命令。详见 gitattributes(5)。

format.attach:: 启用 multipart/mixed 附件作为 'format-patch' 的默认值。该值也可以是双引号字符串，这将启用附件作为默认值并将该值设置为边界。参见 git-format-patch(1) 中的 --attach 选项。要取消先前的值，请将其设置为空字符串。

format.from:: 为 format-patch 的 --from 选项提供默认值。接受布尔值或名称和电子邮件地址。如果为 false，format-patch 默认为 --no-from，在补丁邮件的 "From:" 字段中直接使用提交作者。如果为 true，format-patch 默认为 --from，在补丁邮件的 "From:" 字段中使用您的提交者身份，如果不同则在补丁邮件正文中包含 "From:" 字段。如果设置为非布尔值，format-patch 使用该值代替您的提交者身份。默认为 false。

format.forceInBodyFrom:: 为 format-patch 的 --[no-]force-in-body-from 选项提供默认值。默认为 false。

format.numbered:: 布尔值，可以启用或禁用补丁主题中的序列号。默认为 "auto"，仅在有多个补丁时启用。可以通过设置为 "true" 或 "false" 为所有消息启用或禁用。参见 git-format-patch(1) 中的 --numbered 选项。

format.headers:: 包含在要通过邮件提交的补丁中的额外邮件头。参见 git-format-patch(1)。

format.to:: format.cc:: 包含在要通过邮件提交的补丁中的额外收件人。参见 git-format-patch(1) 中的 --to 和 --cc 选项。

format.subjectPrefix:: format-patch 的默认值是输出带有 '[PATCH]' 主题前缀的文件。使用此变量更改该前缀。

format.coverFromDescription:: format-patch 使用分支描述填充求职信的哪些部分的默认模式。参见 git-format-patch(1) 中的 --cover-from-description 选项。

format.signature:: format-patch 的默认值是输出包含 Git 版本号的签名。使用此变量更改该默认值。将此变量设置为空字符串 ("") 以抑制签名生成。

format.signatureFile:: 与 format.signature 类似，只是此变量指定的文件内容将用作签名。

format.suffix:: format-patch 的默认值是输出带有 .patch 后缀的文件。使用此变量更改该后缀（如果需要，请确保包含点）。

format.encodeEmailHeaders:: 使用 RFC 2047 中描述的 "Q-encoding" 对包含非 ASCII 字符的邮件头进行编码以进行邮件传输。默认为 true。

format.pretty:: ifndef::with-breaking-changes[] log/show/whatchanged 命令的默认 pretty 格式。参见 git-log(1)、git-show(1)、git-whatchanged(1)。 endif::with-breaking-changes[] ifdef::with-breaking-changes[] log/show 命令的默认 pretty 格式。参见 git-log(1)、git-show(1)。 endif::with-breaking-changes[]

format.thread:: 'git format-patch' 的默认线程样式。可以是布尔值，或 shallow 或 deep。shallow 线程使每封邮件都回复到系列的开头，开头从求职信、--in-reply-to 和第一封补丁邮件中按此顺序选择。deep 线程使每封邮件都回复到前一封。布尔 true 值与 shallow 相同，false 值禁用线程。

format.signOff:: 布尔值，允许您默认启用 format-patch 的 -s/--signoff 选项。注意： 将 Signed-off-by 尾部添加到补丁应该是一个有意识的行为，意味着您证明您有权在相同的开源许可下提交此工作。详见 'SubmittingPatches' 文档。

format.coverLetter:: 布尔值，控制调用 format-patch 时是否生成求职信，但还可以设置为 "auto" 以仅在有多个补丁时生成求职信。默认为 false。

format.commitListFormat:: 当未给出 --commit-list-format 选项时，format-patch 使用此变量的值来决定如何格式化每个提交的条目。默认为 shortlog。

format.outputDirectory:: 设置自定义目录来存储结果文件，而不是当前工作目录。将创建所有目录组件。

format.filenameMaxLength:: format-patch 命令生成的输出文件名的最大长度；默认为 64。可以通过 --filename-max-length=<n> 命令行选项覆盖。

format.useAutoBase:: 布尔值，允许您默认启用 format-patch 的 --base=auto 选项。也可以设置为 "whenAble" 以允许在有合适基础可用时启用 --base=auto，但否则跳过添加基础信息而不会导致格式失败。

format.notes:: 为 format-patch 的 --notes 选项提供默认值。接受布尔值或指定从何处获取笔记的引用。如果为 false，format-patch 默认为 --no-notes。如果为 true，format-patch 默认为 --notes。如果设置为非布尔值，format-patch 默认为 --notes=<ref>，其中 ref 是非布尔值。默认为 false。 + 如果希望使用引用 refs/notes/true，请使用该字面量代替。 + 可以多次指定此配置以允许多个笔记引用被包含。在这种情况下，它的行为类似于传入的多个 --[no-]notes[=] 选项。即 true 的值将显示默认笔记，<ref> 的值也将显示来自该笔记引用的笔记，false 的值将否定先前的配置且不显示笔记。 + 例如，

notes = bar

将仅显示来自 refs/notes/bar 的笔记。

format.mboxrd:: 布尔值，当使用 --stdout 时启用健壮的 "mboxrd" 格式以转义 "^>+From " 行。

format.noprefix:: 如果设置，不在补丁中显示任何源或目标前缀。这等同于 git diff 使用的 diff.noprefix 选项（但 format-patch 不遵守）。请注意，通过设置此选项，您生成的任何补丁的接收者将需要使用 -p0 选项应用它们。

fsck.<msg-id>:: 在 fsck 期间，Git 可能会发现旧数据的问题，这些问题不会由当前版本的 Git 生成，并且如果设置了 transfer.fsckObjects 也不会通过网络发送。此功能旨在支持处理包含此类数据的旧仓库。 + 设置 fsck.<msg-id> 将被 git-fsck(1) 使用，但要接受此类数据的推送，请改为设置 receive.fsck.<msg-id>，或要克隆或获取它，请设置 fetch.fsck.<msg-id>。 + 为简洁起见，本文档的其余部分讨论 fsck.*，但同样的内容适用于相应的 receive.fsck.* 和 fetch.fsck.* 变量。 + 与 color.ui 和 core.editor 等变量不同，receive.fsck.<msg-id> 和 fetch.fsck.<msg-id> 变量在未设置时不会回退到 fsck.<msg-id> 配置。要在不同情况下统一配置相同的 fsck 设置，必须将所有三个变量设置为相同的值。 + 当设置了 fsck.<msg-id> 时，可以通过配置 fsck.<msg-id> 设置将错误切换为警告，反之亦然，其中 <msg-id> 是 fsck 消息 ID，值为 error、warn 或 ignore 之一。为方便起见，fsck 在错误/警告前加上消息 ID，例如 "missingEmail: invalid author/committer line - missing email" 意味着设置 fsck.missingEmail = ignore 将隐藏该问题。 + 通常，最好使用 fsck.skipList 枚举有问题的现有对象，而不是列出这些有问题的对象共享的要忽略的损坏类型，因为这样做会使相同损坏的新实例不被发现。 + 设置未知的 fsck.<msg-id> 值将导致 fsck 终止，但对 receive.fsck.<msg-id> 和 fetch.fsck.<msg-id> 执行相同操作只会导致 git 发出警告。 + 有关 <msg-id> 的支持值，请参见 git-fsck(1) 的 Fsck Messages 部分。

fsck.skipList:: 对象名称列表的路径（即每行一个未缩写的 SHA-1），这些对象已知以非致命方式损坏且应被忽略。在 Git 2.20 及更高版本上，注释（'#'）、空行以及任何前导和尾随空格都会被忽略。在旧版本上，每行除 SHA-1 之外的任何内容都会导致错误。 + 当一个成熟的项目应被接受，尽管早期提交包含可以安全忽略的错误（例如无效的提交者电子邮件地址）时，此功能很有用。注意：损坏的对象无法通过此设置跳过。 + 与 fsck.<msg-id> 一样，此变量有相应的 receive.fsck.skipList 和 fetch.fsck.skipList 变体。 + 与 color.ui 和 core.editor 等变量不同，receive.fsck.skipList 和 fetch.fsck.skipList 变量在未设置时不会回退到 fsck.skipList 配置。要在不同情况下统一配置相同的 fsck 设置，必须将所有三个变量设置为相同的值。 + 旧版本的 Git（2.20 之前）记录对象名称列表应排序。这从来不是要求；对象名称可以以任何顺序出现，但在读取列表时，我们跟踪列表是否已排序以用于内部二分搜索实现，这可以对已排序的列表节省一些工作。除非您有一个巨大的列表，否则没有必要特意预排序列表。在 Git 2.20 版本之后，使用了哈希实现代替，因此现在没有理由预排序列表。

fsmonitor.allowRemote:: 默认情况下，fsmonitor 守护进程拒绝处理网络挂载的仓库。将 fsmonitor.allowRemote 设置为 true 会覆盖此行为。仅在 core.fsmonitor 设置为 true 时才被尊重。

fsmonitor.socketDir:: 此 Mac OS 特定选项，如果设置，指定用于在 fsmonitor 守护进程和各种 Git 命令之间通信的 Unix 域套接字的创建目录。该目录必须位于原生 Mac OS 文件系统上。仅在 core.fsmonitor 设置为 true 时才被尊重。

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 将打包它们。一些 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，则 gc 将在运行 git-gc(1) 时重写提交图文件。使用 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:: 将不可达对象存储在 cruft 包中（参见 git-repack(1)）而不是作为松散对象。默认为 true。

gc.maxCruftSize:: 重新打包时限制新 cruft 包的大小。当与 --max-cruft-size 同时指定时，命令行选项优先。参见 git-repack(1) 的 --max-cruft-size 选项。

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

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> 的引用。

gc.reflogExpireUnreachable:: gc.<pattern>.reflogExpireUnreachable:: 'git reflog expire' 移除此时间之前且从当前提示不可达的 reflog 条目；默认为 30 天。值 "now" 立即过期所有条目，"never" 完全抑制过期。中间带有 "<pattern>"（例如 "refs/stash"）时，该设置仅适用于匹配 <pattern> 的引用。 + 这些类型的条目通常是使用 git commit --amend 或 git rebase 的结果，是修改或变基发生之前的提交。由于这些更改不是当前项目的一部分，大多数用户会希望更快地过期它们，这就是为什么 默认值比 gc.reflogExpire 更激进。

gc.recentObjectsHook:: 在考虑是否移除对象时（无论是生成 cruft 包还是将不可达对象存储为松散对象），使用 shell 执行指定的命令。将其输出解释为对象 ID，Git 将其视为"最近的"，无论其年龄如何。通过将其 mtime 视为"现在"，输出中提到的任何对象（及其后代）将被保留，无论其真实年龄如何。 + 输出必须每行恰好包含一个十六进制对象 ID，没有其他内容。在仓库中找不到的对象将被忽略。支持多个钩子，但所有钩子都必须成功退出，否则操作（生成 cruft 包或解包不可达对象）将被停止。

gc.repackFilter:: 重新打包时，使用指定的过滤器将某些对象移动到单独的包文件中。参见 git-repack(1) 的 --filter=<filter-spec> 选项。

gc.repackFilterTo:: 重新打包并使用过滤器时（参见 gc.repackFilter），指定的位置将用于创建包含被过滤掉的对象的包文件。警告： 指定的位置应该是可访问的，例如使用 Git alternates 机制，否则仓库可能被 Git 视为损坏，因为它可能无法访问该包文件中的对象。参见 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)。

gitcvs.commitMsgAnnotation:: 将此字符串附加到每个提交消息。设置为空字符串以禁用此功能。默认为 "via git-CVS emulator"。

gitcvs.enabled:: 是否为此仓库启用 CVS 服务器接口。参见 git-cvsserver(1)。

gitcvs.logFile:: CVS 服务器接口记录各种内容的日志文件路径。参见 git-cvsserver(1)。

gitcvs.usecrlfattr:: 如果为 true，服务器将查找文件的行结束转换属性以确定要使用的 -k 模式。如果属性强制 Git 将文件视为文本，则 -k 模式将留空，以便 CVS 客户端将其视为文本。如果它们抑制文本转换，文件将设置为 '-kb' 模式，这会抑制客户端可能执行的任何换行处理。如果属性不允许确定文件类型，则使用 gitcvs.allBinary。参见 gitattributes(5)。

gitcvs.allBinary:: 当 gitcvs.usecrlfattr 无法解析正确的 '-kb' 模式时使用此选项。如果为 true，所有未解析的文件都以 '-kb' 模式发送给客户端。这会使客户端将它们视为二进制文件，从而抑制可能执行的任何换行处理。或者，如果设置为 "guess"，则检查文件内容以确定它是否是二进制文件，类似于 core.autocrlf。

gitcvs.dbName:: git-cvsserver 用于缓存从 Git 仓库派生的修订信息的数据库。确切含义取决于使用的数据库驱动程序，对于 SQLite（默认驱动程序），这是一个文件名。支持变量替换（详见 git-cvsserver(1)）。不能包含分号（;）。默认值：'%Ggitcvs.%m.sqlite'

gitcvs.dbDriver:: 使用的 Perl DBI 驱动程序。您可以在此处指定任何可用的驱动程序，但它可能不起作用。git-cvsserver 已使用 'DBD::SQLite' 测试，据报告可与 'DBD::Pg' 配合使用，据报告不能与 'DBD::mysql' 配合使用。实验性功能。不能包含双冒号（:）。默认值：'SQLite'。参见 git-cvsserver(1)。

gitcvs.dbUser:: gitcvs.dbPass:: 数据库用户名和密码。仅在设置 gitcvs.dbDriver 时有用，因为 SQLite 没有数据库用户和/或密码的概念。'gitcvs.dbUser' 支持变量替换（详见 git-cvsserver(1)）。

gitcvs.dbTableNamePrefix:: 数据库表名前缀。添加到使用的任何数据库表名前面，允许单个数据库用于多个仓库。支持变量替换（详见 git-cvsserver(1)）。任何非字母字符将被替换为下划线。

除 gitcvs.usecrlfattr 和 gitcvs.allBinary 外，所有 gitcvs 变量也可以指定为 'gitcvs.<access_method>.<varname>'（其中 'access_method' 是 "ext" 和 "pserver" 之一），以使它们仅适用于给定的访问方法。

gitweb.category:: gitweb.description:: gitweb.owner:: gitweb.url:: 详见 gitweb(1)。

gitweb.avatar:: gitweb.blame:: gitweb.grep:: gitweb.highlight:: gitweb.patches:: gitweb.pickaxe:: gitweb.remote_heads:: gitweb.showSizes:: gitweb.snapshot:: 详见 gitweb.conf(5)。

gpg.program:: 在创建或验证 PGP 签名时用来代替 "gpg" 的程序的路径名。该程序必须支持与 GPG 相同的命令行接口，即要验证分离签名，运行 "gpg --verify $signature - <$file"，该程序应通过以代码 0 退出来表示签名正确。要生成 ASCII 装甲分离签名，将要签名的内容提供给 "gpg -bsau $key" 的标准输入，该程序应将结果发送到其标准输出。

gpg.format:: 指定使用 --gpg-sign 签名时使用哪种密钥格式。默认为 "openpgp"。其他可能的值为 "x509"、"ssh"。 + 有关签名格式的详情，请参见 gitformat-signature(5)，该格式根据所选的 gpg.format 而有所不同。

gpg.<format>.program:: 使用此选项自定义您选择的签名格式所使用的程序（参见 gpg.program 和 gpg.format）。gpg.program 仍可作为 gpg.openpgp.program 的旧版同义词使用。gpg.x509.program 的默认值为 "gpgsm"，gpg.ssh.program 的默认值为 "ssh-keygen"。

gpg.minTrustLevel:: 指定签名验证的最低信任级别。如果未设置此选项，则合并操作的签名验证需要至少 marginal 信任的密钥。执行签名验证的其他操作需要至少 undefined 信任的密钥。设置此选项会覆盖所有操作所需的信任级别。支持的值，按重要性递增顺序： +

• undefined
• never
• marginal
• fully
• ultimate

gpg.ssh.defaultKeyCommand:: 当未设置 user.signingkey 且请求 ssh 签名时将运行此命令。成功退出时，期望其输出的第一行包含以 key:: 为前缀的有效 ssh 公钥。这允许脚本在静态配置 user.signingKey 不切实际时动态查找正确的公钥。例如当密钥或 SSH 证书经常轮换或选择正确的密钥依赖于 Git 未知的外部因素时。

gpg.ssh.allowedSignersFile:: 包含您愿意信任的 ssh 公钥的文件。该文件由一行或多行主体后跟一个 ssh 公钥组成。 例如：user1@example.com,user2@example.com ssh-rsa AAAAX1... 详见 ssh-keygen(1) "ALLOWED SIGNERS"。主体仅用于标识密钥，在验证签名时可用。 + SSH 没有像 gpg 那样的信任级别概念。为了区分有效签名和受信任签名，当公钥存在于 allowedSignersFile 中时，签名验证的信任级别设置为 fully。否则信任级别为 undefined，git verify-commit/tag 将失败。 + 此文件可以设置为仓库外部的位置，每个开发者维护自己的信任存储。中央仓库服务器可以从具有推送访问权限的 ssh 密钥自动生成此文件以验证代码。在企业环境中，此文件可能由处理开发者 ssh 密钥的自动化工具在全局位置生成。 + 只允许签名提交的仓库可以使用相对于工作树顶级目录的路径将文件存储在仓库本身中。这样，只有已拥有有效密钥的提交者才能在密钥环中添加或更改密钥。 + 自 OpenSSH 8.8 起，此文件允许使用 valid-after 和 valid-before 选项指定密钥有效期。如果签名密钥在签名创建时有效，Git 会将签名标记为有效。这允许用户更改签名密钥而不会使所有先前创建的签名无效。 + 使用带有 cert-authority 选项的 SSH CA 密钥（参见 ssh-keygen(1) "CERTIFICATES"）也是有效的。

gpg.ssh.revocationFile:: SSH KRL 或已吊销公钥列表（不带主体前缀）。详见 ssh-keygen(1)。如果在此文件中找到公钥，则始终将其视为信任级别为 "never"，签名将显示为无效。

grep.lineNumber:: 如果设置为 true，默认启用 -n 选项。

grep.column:: 如果设置为 true，默认启用 --column 选项。

grep.patternType:: 设置默认匹配行为。使用 'basic'、'extended'、'fixed' 或 'perl' 值将相应启用 --basic-regexp、--extended-regexp、--fixed-strings 或 --perl-regexp 选项，而值 'default' 将使用 grep.extendedRegexp 选项在 'basic' 和 'extended' 之间选择。

grep.extendedRegexp:: 如果设置为 true，默认启用 --extended-regexp 选项。当 grep.patternType 选项设置为 'default' 以外的值时，此选项被忽略。

grep.threads:: 使用的 grep 工作线程数。如果未设置（或设置为 0），Git 将使用与可用逻辑核心数一样多的线程。

grep.fullName:: 如果设置为 true，默认启用 --full-name 选项。

grep.fallbackToNoIndex:: 如果设置为 true，当 git grep 在 git 仓库外执行时回退到 git grep --no-index。默认为 false。

gui.commitMsgWidth:: 定义 git-gui(1) 中提交消息窗口的宽度。默认为 "75"。

gui.diffContext:: 指定 git-gui(1) 调用 diff 时使用的上下文行数。默认为 "5"。

gui.displayUntracked:: 确定 git-gui(1) 是否在文件列表中显示未跟踪的文件。默认为 "true"。

gui.encoding:: 指定在 git-gui(1) 和 gitk(1) 中显示文件内容时使用的默认字符编码。 可以通过为相关文件设置 'encoding' 属性来覆盖（参见 gitattributes(5)）。如果未设置此选项，工具默认使用区域编码。

gui.matchTrackingBranch:: 确定使用 git-gui(1) 创建的新分支是否默认跟踪同名的远程分支。默认值："false"。

gui.newBranchTemplate:: 使用 git-gui(1) 创建新分支时用作建议名称。

gui.pruneDuringFetch:: 如果为 "true"，git-gui(1) 在执行获取时将修剪远程跟踪分支。默认值为 "false"。

gui.trustmtime:: 确定 git-gui(1) 是否应信任文件修改时间戳。默认情况下不信任时间戳。

gui.spellingDictionary:: 指定在 git-gui(1) 中用于拼写检查提交消息的词典。设置为 "none" 时关闭拼写检查。

gui.fastCopyBlame:: 如果为 true，'git gui blame' 使用 -C 而不是 -C -C 进行原始位置检测。这使得在大型仓库上 blame 显著更快，但代价是复制检测不够彻底。

gui.copyBlameThreshold:: 指定 'git gui blame' 原始位置检测中使用的阈值，以字母数字字符为单位。有关复制检测的更多信息，请参见 git-blame(1) 手册。

gui.blamehistoryctx:: 指定从 'git gui blame' 调用 Show History Context 菜单项时，在 gitk(1) 中为选定提交显示的历史上下文的天数半径。如果此变量设置为零，则显示整个历史。

gui.GCWarning:: 确定当 Git 检测到仓库中有大量松散对象时，git-gui(1) 是否应提示进行垃圾回收。默认值为 "true"。

guitool.<name>.cmd:: 指定调用 git-gui(1) Tools 菜单中相应项时执行的 shell 命令行。此选项对每个工具都是必需的。命令从工作目录的根目录执行，并在环境中接收工具名称作为 GIT_GUITOOL、当前选定文件的名称作为 'FILENAME'，以及当前分支的名称作为 'CUR_BRANCH'（如果头指针分离，则 'CUR_BRANCH' 为空）。

guitool.<name>.needsFile:: 仅在 GUI 中选择了差异时运行工具。它保证 'FILENAME' 不为空。

guitool.<name>.noConsole:: 静默运行命令，不创建窗口显示其输出。

guitool.<name>.noRescan:: 工具执行完成后不重新扫描工作目录的更改。

guitool.<name>.confirm:: 在实际运行工具之前显示确认对话框。

guitool.<name>.argPrompt:: 向用户请求字符串参数，并通过 ARGS 环境变量将其传递给工具。由于请求参数意味着确认，如果启用此选项，'confirm' 选项将无效。如果选项设置为 'true'、'yes' 或 '1'，对话框使用内置的通用提示；否则使用变量的确切值。

guitool.<name>.revPrompt:: 向用户请求单个有效修订，并设置 REVISION 环境变量。在其他方面，此选项类似于 'argPrompt'，可以与其一起使用。

guitool.<name>.revUnmerged:: 在 'revPrompt' 子对话框中仅显示未合并的分支。这对于类似于合并或变基的工具很有用，但不适用于签出或重置等操作。

guitool.<name>.title:: 指定提示对话框使用的标题。默认为工具名称。

guitool.<name>.prompt:: 指定显示在对话框顶部、'argPrompt' 和 'revPrompt' 子部分之前的一般提示字符串。默认值包含实际命令。

help.browser:: 指定用于以 'web' 格式显示帮助的浏览器。参见 git-help(1)。

help.format:: 覆盖 git-help(1) 使用的默认帮助格式。支持 'man'、'info'、'web' 和 'html' 值。'man' 是默认值。'web' 和 'html' 相同。

help.autoCorrect:: 如果 Git 检测到拼写错误并能准确识别一个与错误相似的有效命令，Git 将尝试建议正确的命令甚至自动运行建议。可能的配置值为： - 0、"false"、"off"、"no"、"show"：显示建议的命令（默认）。 - 1、"true"、"on"、"yes"、"immediate"：立即运行建议的命令。 - 大于 1 的正数：在指定的十分之一秒（0.1 秒）后运行建议的命令。 - "never"：不运行或显示任何建议的命令。 - "prompt"：显示建议并提示确认是否运行该命令。

help.htmlPath:: 指定 HTML 文档所在的路径。支持文件系统路径和 URL。当帮助以 'web' 格式显示时，HTML 页面将此前缀作为路径。默认为 Git 安装的文档路径。

http.proxy:: 覆盖 HTTP 代理，通常使用 'http_proxy'、'https_proxy' 和 'all_proxy' 环境变量配置（参见 curl(1)）。除了 curl 理解的语法外，还可以指定带有用户名但没有密码的代理字符串，在这种情况下 Git 将尝试以与其他凭据相同的方式获取密码。有关更多信息，请参见 gitcredentials(7)。语法为 '[protocol://][user[:password]@]proxyhost[:port][/path]'。这可以按远程覆盖；参见 remote.<name>.proxy + 任何代理，无论如何配置，都必须完全透明，不得以任何方式修改、转换或缓冲请求或响应。不完全透明的代理已知会导致 Git 出现各种形式的损坏。

http.proxyAuthMethod:: 设置对 HTTP 代理进行身份验证的方法。仅在配置的代理字符串包含用户名部分（即格式为 'user@host' 或 'user@host:port'）时生效。这可以按远程覆盖；参见 remote.<name>.proxyAuthMethod。两者都可以被 GIT_HTTP_PROXY_AUTHMETHOD 环境变量覆盖。可能的值为：

* ntlm - NTLM 身份验证（比较 curl(1) 的 --ntlm 选项）

http.proxySSLCert:: 存储用于对 HTTPS 代理进行身份验证的客户端证书的文件路径名。可以被 GIT_PROXY_SSL_CERT 环境变量覆盖。

http.proxySSLKey:: 存储用于对 HTTPS 代理进行身份验证的私钥的文件路径名。可以被 GIT_PROXY_SSL_KEY 环境变量覆盖。

http.proxySSLCertPasswordProtected:: 为代理 SSL 证书启用 Git 的密码提示。否则，如果证书或私钥被加密，OpenSSL 将提示用户，可能多次。可以被 GIT_PROXY_SSL_CERT_PASSWORD_PROTECTED 环境变量覆盖。

http.proxySSLCAInfo:: 包含在使用 HTTPS 代理时用于验证代理的证书包的文件路径名。可以被 GIT_PROXY_SSL_CAINFO 环境变量覆盖。

http.emptyAuth:: 尝试在不请求用户名或密码的情况下进行身份验证。这可用于尝试 GSS-Negotiate 身份验证而无需在 URL 中指定用户名，因为 libcurl 通常需要用户名进行身份验证。可能的值为：

有效。

http.proactiveAuth:: 尝试在不先进行未身份验证尝试并接收 401 响应的情况下进行身份验证。这可用于确保所有请求都经过身份验证。如果 http.emptyAuth 设置为 true，则此值无效。 + 如果使用的凭据帮助程序指定了身份验证方案（即通过 authtype 字段），则使用该值；如果提供了用户名和密码但没有方案，则使用基本身份验证。选项的值决定从帮助程序请求的方案。可能的值为：

* none - 禁用主动身份验证。

请注意，应始终将 TLS 与此配置一起使用，因为如果选择了基本身份验证，否则很容易意外暴露明文凭据。

http.delegation:: 控制 GSSAPI 凭据委托。委托默认在 libcurl 7.21.7 版本以来默认禁用。设置参数以告诉服务器在用户凭据方面允许委托什么。与 GSS/kerberos 一起使用。可能的值为：

* always - 无条件允许服务器委托。

http.extraHeader:: 与服务器通信时传递额外的 HTTP 头。如果存在多个此类条目，则所有条目都作为额外头添加。要允许覆盖从系统配置继承的设置，空值将把额外头重置为空列表。

http.cookieFile:: 包含先前存储的 cookie 行的文件路径名，如果它们与服务器匹配，应在 Git http 会话中使用。读取 cookie 的文件格式应为纯 HTTP 头或 Netscape/Mozilla cookie 文件格式（参见 curl(1)）。将其设置为空字符串，以仅接受来自服务器的新 cookie 并在同一连接内的后续请求中将其发回。请注意，http.cookieFile 指定的文件仅用作输入，除非设置了 http.saveCookies。

http.saveCookies:: 如果设置，将请求期间收到的 cookie 存储到 http.cookieFile 指定的文件中。如果 http.cookieFile 未设置或设置为空字符串，则无效。

http.version:: 与服务器通信时使用指定的 HTTP 协议版本。如果要强制使用默认值。可用版本和默认版本取决于 libcurl。当前此选项的可能值为：

- HTTP/2
- HTTP/1.1

http.curloptResolve:: 发送 HTTP 请求时 libcurl 将首先使用的主机名解析信息。此信息应采用以下格式之一：

- [+]HOST:PORT:ADDRESS[,ADDRESS]
- -HOST:PORT

第一种格式将所有请求重定向到给定的 HOST:PORT 到提供的 ADDRESS。第二种格式清除该 HOST:PORT 组合的所有先前配置值。要允许轻松覆盖从系统配置继承的所有设置，空值将把所有解析信息重置为空列表。

http.sslVersion:: 协商 SSL 连接时使用的 SSL 版本，如果要强制使用默认值。可用版本和默认版本取决于 libcurl 是针对 NSS 还是 OpenSSL 构建的，以及使用的加密库的特定配置。在内部，这设置 'CURLOPT_SSL_VERSION' 选项；有关此选项格式和支持的 SSL 版本的更多详情，请参见 libcurl 文档。当前此选项的可能值为：

- sslv2
- sslv3
- tlsv1
- tlsv1.0
- tlsv1.1
- tlsv1.2
- tlsv1.3

可以被 GIT_SSL_VERSION 环境变量覆盖。要强制 Git 使用 libcurl 的默认 SSL 版本并忽略任何显式的 http.sslversion 选项，请将 GIT_SSL_VERSION 设置为空字符串。

http.sslCipherList:: 协商 SSL 连接时使用的 SSL 密码列表。可用密码取决于 libcurl 是针对 NSS 还是 OpenSSL 构建的，以及使用的加密库的特定配置。在内部，这设置 'CURLOPT_SSL_CIPHER_LIST' 选项；有关此列表格式的更多详情，请参见 libcurl 文档。 + 可以被 GIT_SSL_CIPHER_LIST 环境变量覆盖。要强制 Git 使用 libcurl 的默认密码列表并忽略任何显式的 http.sslCipherList 选项，请将 GIT_SSL_CIPHER_LIST 设置为空字符串。

http.sslVerify:: 通过 HTTPS 获取或推送时是否验证 SSL 证书。默认为 true。可以被 GIT_SSL_NO_VERIFY 环境变量覆盖。

http.sslCert:: 通过 HTTPS 获取或推送时包含 SSL 证书的文件。可以被 GIT_SSL_CERT 环境变量覆盖。

http.sslKey:: 通过 HTTPS 获取或推送时包含 SSL 私钥的文件。可以被 GIT_SSL_KEY 环境变量覆盖。

http.sslCertPasswordProtected:: 为 SSL 证书启用 Git 的密码提示。否则，如果证书或私钥被加密，OpenSSL 将提示用户，可能多次。可以被 GIT_SSL_CERT_PASSWORD_PROTECTED 环境变量覆盖。

http.sslCAInfo:: 通过 HTTPS 获取或推送时用于验证对等方的证书文件。可以被 GIT_SSL_CAINFO 环境变量覆盖。

http.sslCAPath:: 包含 CA 证书文件的路径，用于通过 HTTPS 获取或推送时验证对等方。可以被 GIT_SSL_CAPATH 环境变量覆盖。

http.sslBackend:: 要使用的 SSL 后端名称（例如 "openssl" 或 "schannel"）。如果 cURL 缺少在运行时选择 SSL 后端的支持，则忽略此选项。

http.sslCertType:: 通过 HTTPS 获取或推送时使用的客户端证书类型。使用 openssl 或 gnutls 后端时支持 "PEM"、"DER"。"P12" 在 "openssl"、"schannel"、"securetransport" 和 gnutls 8.11+ 上受支持。另请参见 libcurl CURLOPT_SSLCERTTYPE。可以被 GIT_SSL_CERT_TYPE 环境变量覆盖。

http.sslKeyType:: 通过 HTTPS 获取或推送时使用的客户端私钥类型（例如 "PEM"、"DER" 或 "ENG"）。仅在使用 "openssl" 后端时适用。openssl 不支持 "DER"。设置为 "ENG" 时特别有用，用于使用 PKCS#11 令牌进行身份验证，在 sslCert 选项中使用 PKCS#11 URL。另请参见 libcurl CURLOPT_SSLKEYTYPE。可以被 GIT_SSL_KEY_TYPE 环境变量覆盖。

http.schannelCheckRevoke:: 用于在 http.sslBackend 设置为 "schannel" 时强制或禁用 cURL 中的证书吊销检查。如果未设置，默认为 true。仅在 Git 持续出错且消息关于检查证书吊销状态时才需要禁用此选项。如果 cURL 缺少在运行时设置相关 SSL 选项的支持，则忽略此选项。

http.schannelUseSSLCAInfo:: 从 cURL v7.60.0 开始，Secure Channel 后端可以使用通过 http.sslCAInfo 提供的证书包，但这会覆盖 Windows 证书存储。由于默认情况下这不是期望的，当通过 http.sslBackend 配置了 schannel 后端时，Git 将告诉 cURL 默认不使用该包，除非 http.schannelUseSSLCAInfo 覆盖此行为。

http.pinnedPubkey:: https 服务的公钥。它可以是 PEM 或 DER 编码的公钥文件的文件名，也可以是以 'sha256//' 开头后跟公钥的 base64 编码 sha256 哈希的字符串。另请参见 libcurl 'CURLOPT_PINNEDPUBLICKEY'。如果设置了此选项但 cURL 不支持，Git 将以错误退出。

http.sslTry:: 通过常规 FTP 协议连接时尝试使用 AUTH SSL/TLS 和加密数据传输。如果 FTP 服务器出于安全原因需要此功能，或者您希望在远程 FTP 服务器支持时安全连接，则可能需要此功能。默认为 false，因为它可能在配置错误的服务器上触发证书验证错误。

http.maxRequests:: 并行启动多少个 HTTP 请求。可以被 GIT_HTTP_MAX_REQUESTS 环境变量覆盖。默认为 5。

http.minSessions:: 跨请求保留的 curl 会话数（跨槽计数）。在调用 http_cleanup() 之前，它们不会以 curl_easy_cleanup() 结束。如果未定义 USE_CURL_MULTI，此值将被限制为 1。默认为 1。

http.postBuffer:: 智能 HTTP 传输在向远程系统 POST 数据时使用的缓冲区的最大字节数。对于大于此缓冲区大小的请求，使用 HTTP/1.1 和 Transfer-Encoding: chunked 以避免在本地创建巨大的包文件。默认为 1 MiB，足以满足大多数请求。 + 请注意，提高此限制仅对禁用分块传输编码有效，因此应仅在远程服务器或代理仅支持 HTTP/1.0 或不符合 HTTP 标准时使用。一般来说，提高此限制不是解决大多数推送问题的有效方法，但会显著增加内存消耗，因为即使对于小型推送也会分配整个缓冲区。

http.lowSpeedLimit:: http.lowSpeedTime:: 如果 HTTP 传输速度（以字节/秒为单位）低于 'http.lowSpeedLimit' 的时间超过 'http.lowSpeedTime' 秒，则传输将被中止。可以被 GIT_HTTP_LOW_SPEED_LIMIT 和 GIT_HTTP_LOW_SPEED_TIME 环境变量覆盖。

http.keepAliveIdle:: 指定在发送 TCP 保活探测之前在空闲连接上等待的秒数（如果操作系统支持）。如果未设置，使用 curl 的默认值。可以被 GIT_HTTP_KEEPALIVE_IDLE 环境变量覆盖。

http.keepAliveInterval:: 指定 TCP 保活探测之间的等待秒数（如果操作系统支持）。如果未设置，使用 curl 的默认值。可以被 GIT_HTTP_KEEPALIVE_INTERVAL 环境变量覆盖。

http.keepAliveCount:: 指定在放弃并终止连接之前发送的 TCP 保活探测次数（如果操作系统支持）。如果未设置，使用 curl 的默认值。可以被 GIT_HTTP_KEEPALIVE_COUNT 环境变量覆盖。

http.retryAfter:: 当服务器返回 HTTP 429（请求过多）且没有 Retry-After 头时，重试前的默认等待时间（以秒为单位）。默认为 0（立即重试）。当存在 Retry-After 头时，其值优先于此设置；但是，自动使用服务器提供的 Retry-After 头需要 libcurl 7.66.0 或更高版本。在较旧版本上，请手动配置此设置以控制重试延迟。可以被 GIT_HTTP_RETRY_AFTER 环境变量覆盖。另见 http.maxRetries 和 http.maxRetryTime。

http.maxRetries:: 收到 HTTP 429（请求过多）响应后的最大重试次数。设置为 0（默认值）以禁用重试。可以被 GIT_HTTP_MAX_RETRIES 环境变量覆盖。另见 http.retryAfter 和 http.maxRetryTime。

http.maxRetryTime:: 处理 HTTP 429（请求过多）响应时等待单次重试尝试的最大时间（以秒为单位）。如果服务器请求延迟（通过 Retry-After 头）或 http.retryAfter 配置的值超过此最大值，Git 将立即失败而不是等待。默认为 300 秒（5 分钟）。可以被 GIT_HTTP_MAX_RETRY_TIME 环境变量覆盖。另见 http.retryAfter 和 http.maxRetries。

http.noEPSV:: 布尔值，禁用 curl 使用 EPSV ftp 命令。这对于某些不支持 EPSV 模式的"差"ftp 服务器很有帮助。可以被 GIT_CURL_FTP_NO_EPSV 环境变量覆盖。默认为 false（curl 将使用 EPSV）。

http.userAgent:: 呈现给 HTTP 服务器的 HTTP USER_AGENT 字符串。默认值表示 Git 客户端的版本，如 git/1.7.1。此选项允许您将此值覆盖为更常见的值，如 Mozilla/4.0。例如，如果通过限制 HTTP 连接为一组常见 USER_AGENT 字符串（但不包括像 git/1.7.1 这样的）的防火墙连接，这可能是必要的。可以被 GIT_HTTP_USER_AGENT 环境变量覆盖。

http.followRedirects:: Git 是否应跟随 HTTP 重定向。如果设置为 true，Git 将透明地跟随它遇到的服务器发出的任何重定向。如果设置为 false，Git 将所有重定向视为错误。如果设置为 initial，Git 仅对远程的初始请求跟随重定向，但不对后续的 HTTP 请求跟随。由于 Git 使用重定向后的 URL 作为后续请求的基础，这通常足够了。默认为 initial。

http.<url>.:: 上面的任何 http. 选项都可以选择性地应用于某些 URL。要使配置键匹配 URL，配置键的每个元素与 URL 的相应元素按以下顺序进行比较：

but at a lower precedence than a config key with a user name.

上面的列表按优先级递减排序；匹配配置键路径的 URL 优先于匹配其用户名的 URL。例如，如果 URL 是 https://user@example.com/foo/bar，配置键匹配 https://example.com/foo 将优先于配置键匹配 https://user@example.com。 + 所有 URL 在尝试匹配之前都会被规范化（如果嵌入在 URL 中，密码部分在匹配时始终被忽略），以便拼写不同的等效 URL 能够正确匹配。环境变量设置始终覆盖任何匹配。匹配的 URL 是直接传递给 Git 命令的那些。这意味着由于重定向而访问的任何 URL 不参与匹配。

i18n.commitEncoding:: 提交消息存储的字符编码；Git 本身并不关心，但此信息在例如从电子邮件导入提交或在 gitk 图形历史浏览器中（以及将来可能在其他地方或其他 porcelain 命令中）是必需的。参见 git-mailinfo(1)。默认为 'utf-8'。

i18n.logOutputEncoding:: 运行 'git log' 及其相关命令时提交消息转换的字符编码。

imap.folder:: 将邮件放入的文件夹，通常是草稿文件夹。例如：INBOX.Drafts、INBOX/Drafts 或 [Gmail]/Drafts。必须指定要交互的 IMAP 文件夹；当未给出 --folder 选项时，此配置变量的值用作回退默认值。

imap.tunnel:: 用于建立到 IMAP 服务器的隧道的命令，通过该隧道传输命令而不是使用到服务器的直接网络连接。当未设置 imap.host 时需要。

imap.host:: 标识服务器的 URL。非安全连接使用 imap:// 前缀，安全连接使用 imaps:// 前缀。当设置 imap.tunnel 时被忽略，否则需要。

imap.user:: 登录服务器时使用的用户名。

imap.pass:: 登录服务器时使用的密码。

imap.port:: 连接到服务器的整数端口号。imap:// 主机默认为 143，imaps:// 主机默认为 993。当设置 imap.tunnel 时被忽略。

imap.sslverify:: 布尔值，启用/禁用 SSL/TLS 连接使用的服务器证书验证。默认为 true。当设置 imap.tunnel 时被忽略。

imap.preformattedHTML:: 布尔值，启用/禁用发送补丁时使用 html 编码。html 编码的补丁将用 <pre> 括起来，并具有 text/html 的内容类型。具有讽刺意味的是，启用此选项会导致 Thunderbird 将补丁作为 plain/text、format=fixed 电子邮件发送。默认为 false。

imap.authMethod:: 指定与 IMAP 服务器进行身份验证的方法。如果 Git 使用 NO_CURL 选项构建，或者您的 curl 版本早于 7.34.0，或者您使用 --no-curl 选项运行 git-imap-send，则唯一支持的方法是 PLAIN、CRAM-MD5、OAUTHBEARER 和 XOAUTH2。如果未设置，则 git imap-send 使用基本的 IMAP 明文 LOGIN 命令。

include.path:: includeIf.<condition>.path:: 用于包含其他配置文件的特殊变量。参见 git-config(1) 主文档中的"配置文件"部分，特别是"包含"和"条件包含"子部分。

查看差异。recordEndOfIndexEntries:: 指定索引文件是否应包含"索引条目结束"部分。这减少了多处理器机器上的索引加载时间，但在使用 Git 2.20 之前的版本读取索引时会产生"ignoring EOIE extension"消息。如果 index.threads 已显式启用则默认为 'true'，否则为 'false'。

查看差异。recordOffsetTable:: 指定索引文件是否应包含"索引条目偏移表"部分。这减少了多处理器机器上的索引加载时间，但在使用 Git 2.20 之前的版本读取索引时会产生"ignoring IEOT extension"消息。如果 index.threads 已显式启用则默认为 'true'，否则为 'false'。

查看差异。sparse:: 启用时，使用稀疏目录条目写入索引。除非同时启用 core.sparseCheckout 和 core.sparseCheckoutCone，否则无效。默认为 'false'。

查看差异。threads:: 指定加载索引时生成的线程数。这旨在减少多处理器机器上的索引加载时间。指定 0 或 'true' 将导致 Git 自动检测 CPU 数量并相应设置线程数。指定 1 或 'false' 将禁用多线程。默认为 'true'。

查看差异。version:: 指定新索引文件应使用的版本初始化。这不会影响现有仓库。如果启用了 feature.manyFiles，则默认为 4。

查看差异。skipHash:: 启用时，不计算索引文件的尾随哈希。这加速了操作索引的 Git 命令，如 git add、git commit 或 git status。不存储校验和，而是写入值为零的尾随字节集，表示计算被跳过。 + 如果您启用 index.skipHash，则 Git 2.13.0 之前的版本将拒绝解析索引，Git 2.40.0 之前的版本将在 git fsck 期间报告错误。

:see-git-init: ifndef::git-init[] :see-git-init: (See the "TEMPLATE DIRECTORY" section of git-init(1).) endif::[]

init.templateDir:: 指定从中复制模板的目录。{see-git-init} init.defaultBranch:: 允许覆盖默认分支名称，例如在初始化新仓库时。 init.defaultObjectFormat:: 允许覆盖新仓库的默认对象格式。参见 git-init(1) 中的 --object-format=。命令行选项和 GIT_DEFAULT_HASH 环境变量都优先于此配置。 init.defaultRefFormat:: 允许覆盖新仓库的默认引用存储格式。参见 git-init(1) 中的 --ref-format=。命令行选项和 GIT_DEFAULT_REF_FORMAT 环境变量都优先于此配置。

init.defaultSubmodulePathConfig:: 一个布尔值，指定 git init 和 git clone 是否应自动将 extensions.submodulePathConfig 设置为 true。这允许所有新仓库自动使用子模块路径扩展。未设置时默认为 false。

instaweb.browser:: 指定用于在 gitweb 中浏览您的工作仓库的程序。参见 git-instaweb(1)。

instaweb.httpd:: 用于在您的工作仓库上启动 gitweb 的 HTTP 守护进程命令行。参见 git-instaweb(1)。

instaweb.local:: 如果为 true，由 git-instaweb(1) 启动的 Web 服务器将绑定到本地 IP (127.0.0.1)。

instaweb.modulePath:: git-instaweb(1) 使用的默认模块路径，替代 /usr/lib/apache2/modules。仅在 httpd 为 Apache 时使用。

instaweb.port:: 绑定 gitweb httpd 的端口号。参见 git-instaweb(1)。

interactive.singleKey:: 当设置为 true 时，允许用户在交互式命令中使用单个键提供单字母输入（即无需按 Enter 键）。这目前被 git-add(1)、git-checkout(1)、git-restore(1)、git-commit(1)、git-reset(1) 和 git-stash(1) 的 --patch 模式使用。

interactive.diffFilter:: 当交互式命令（如 git add --patch）显示彩色差异时，git 将通过此配置变量定义的 shell 命令传输差异。该命令可以进一步标记差异以供人类使用，前提是它与原始差异中的行保持一对一的对应关系。默认为禁用（无过滤）。

log.abbrevCommit:: 如果为 true，使 ifndef::with-breaking-changes[] git-log(1)、git-show(1) 和 git-whatchanged(1) endif::with-breaking-changes[] ifdef::with-breaking-changes[] git-log(1) 和 git-show(1) endif::with-breaking-changes[] 假定 --abbrev-commit。您可以用 --no-abbrev-commit 覆盖此选项。

log.date:: 设置 log 命令的默认日期时间模式。设置 log.date 的值类似于使用 git log 的 --date 选项。详见 git-log(1)。 + 如果格式设置为 "auto:foo" 且分页器正在使用，则格式 "foo" 将用于日期格式。否则，将使用 "default"。

log.decorate:: 打印由 log 命令显示的任何提交的引用名称。可能的值为：

names are shown.

这与 git log 的 --decorate 选项相同。

log.initialDecorationSet:: 默认情况下，git log 仅显示某些已知引用命名空间的装饰。如果指定了 'all'，则显示所有引用作为装饰。

log.excludeDecoration:: 从日志装饰中排除指定的模式。这类似于 --decorate-refs-exclude 命令行选项，但配置选项可以被 --decorate-refs 选项覆盖。

log.diffMerges:: 设置指定 --diff-merges=on 时使用的差异格式，详见 git-log(1) 中的 --diff-merges。默认为 separate。

log.follow:: 如果为 true，当给定单个 <path> 时，git log 将表现得如同使用了 --follow 选项。这与 --follow 有相同的限制，即不能用于跟踪多个文件，且在非线性历史上效果不佳。

log.graphColors:: 以逗号分隔的颜色列表，可用于在 git log --graph 中绘制历史线。

log.showRoot:: 如果为 true，初始提交将显示为一个大的创建事件。这等同于与空树的差异。像 git-log(1) 或 git-whatchanged(1) 这样通常隐藏根提交的工具现在将显示它。默认为 true。

log.showSignature:: 如果为 true，使 git-log(1)、git-show(1) 和 git-whatchanged(1) 假定 --show-signature。

log.mailmap:: 如果为 true，使 git-log(1)、git-show(1) 和 git-whatchanged(1) 假定 --use-mailmap，否则假定 --no-use-mailmap。默认为 true。

lsrefs.unborn:: 可以是 "advertise"（默认）、"allow" 或 "ignore"。如果为 "advertise"，服务器将响应客户端发送的 "unborn"（如 gitprotocol-v2(5) 中所述），并将在协议 v2 能力通告期间通告对此功能的支持。"allow" 与 "advertise" 相同，只是服务器不会通告对此功能的支持；这对于无法原子更新的负载均衡服务器很有用，管理员可以配置 "allow"，然后在延迟后配置 "advertise"。

mailinfo.scissors:: 如果为 true，使 git-mailinfo(1)（因此也包括 git-am(1)）默认表现为在命令行上提供了 --scissors 选项。激活时，此功能会删除剪刀线之前消息正文中的所有内容（即主要由 ">8"、"8<" 和 "-" 组成）。

mailmap.file:: 增强 mailmap 文件的位置。默认的 mailmap 位于仓库根目录，首先加载，然后加载此变量指向的 mailmap 文件。mailmap 文件的位置可能在仓库子目录中，或在仓库本身之外的某个地方。参见 git-shortlog(1) 和 git-blame(1)。

mailmap.blob:: 类似于 mailmap.file，但将值视为仓库中 blob 的引用。如果同时给出了 mailmap.file 和 mailmap.blob，则两者都会被解析，mailmap.file 中的条目优先。在裸仓库中，默认为 HEAD:.mailmap。在非裸仓库中，默认为空。

maintenance.auto:: 此布尔配置选项控制某些命令在完成正常工作后是否运行 git maintenance run --auto。默认为 true。

maintenance.autoDetach:: 许多 Git 命令在将数据写入仓库后会触发自动维护。此布尔配置选项控制此自动维护是在前台发生还是维护进程应分离并在后台继续运行。 + 如果未设置，gc.autoDetach 的值用作回退。如果两者都未设置则默认为 true，这意味着维护进程将分离。

maintenance.strategy:: 此字符串配置选项提供了一种指定仓库维护的推荐策略之一的方式。这影响在 git maintenance run 期间运行哪些任务，前提是未提供 --task=<task> 参数。此设置影响手动维护、自动维护以及计划维护。运行的任务可能因维护类型而异。 + 维护策略可以通过设置 maintenance.<task>.enabled 和 maintenance.<task>.schedule 进一步调整。如果设置了，这些值将替代 maintenance.strategy 提供的默认值。 + 可能的策略为： +

• none：此策略意味着完全不运行任何任务。这是计划维护的默认策略。
• gc：此策略运行 gc 任务。
• geometric：此策略对包文件执行几何重新打包，并保持辅助数据结构最新。此策略过期 reflog 中的数据并移除无法再定位的工作树。当几何重新打包策略决定执行全合一重新打包时，该策略为所有不可达对象生成 cruft 包。已经是 cruft 包一部分的对象将被过期。

此重新打包策略是 gc 策略的完全替代，推荐用于大型仓库。这是手动维护的默认策略。

• incremental：此设置优化为执行不删除任何数据的小型维护活动。此设置不计划 gc 任务，但每小时运行 prefetch 和 commit-graph 任务，每天运行 loose-objects 和 incremental-repack 任务，每周运行 pack-refs 任务。手动仓库维护使用 gc 任务。

maintenance.<task>.enabled:: 此布尔配置选项控制当未向 git maintenance run 指定 --task 选项时，名称为 <task> 的维护任务是否运行。如果存在 --task 选项，则忽略这些配置值。默认情况下，只有 maintenance.gc.enabled 为 true。

maintenance.<task>.schedule:: 此配置选项控制在 git maintenance run --schedule=<frequency> 命令期间是否运行给定的 <task>。值必须是 "hourly"、"daily" 或 "weekly" 之一。

maintenance.commit-graph.auto:: 此整数配置选项控制 commit-graph 任务作为 git maintenance run --auto 的一部分应多久运行一次。如果为零，则 commit-graph 任务不会与 --auto 选项一起运行。负值将强制任务每次运行。否则，正值意味着当不在提交图文件中的可达提交数量至少为 maintenance.commit-graph.auto 的值时，命令应运行。默认值为 100。

maintenance.loose-objects.auto:: 此整数配置选项控制 loose-objects 任务作为 git maintenance run --auto 的一部分应多久运行一次。如果为零，则 loose-objects 任务不会与 --auto 选项一起运行。负值将强制任务每次运行。否则，正值意味着当松散对象数量至少为 maintenance.loose-objects.auto 的值时，命令应运行。默认值为 100。

maintenance.loose-objects.batchSize:: 此整数配置选项控制在 loose-objects 任务期间写入包文件的松散对象的最大数量。默认为五万。使用值 0 表示无限制。

maintenance.incremental-repack.auto:: 此整数配置选项控制 incremental-repack 任务作为 git maintenance run --auto 的一部分应多久运行一次。如果为零，则 incremental-repack 任务不会与 --auto 选项一起运行。负值将强制任务每次运行。否则，正值意味着当不在多包索引中的包文件数量至少为 maintenance.incremental-repack.auto 的值时，命令应运行。默认值为 10。

maintenance.geometric-repack.auto:: 此整数配置选项控制 geometric-repack 任务作为 git maintenance run --auto 的一部分应多久运行一次。如果为零，则 geometric-repack 任务不会与 --auto 选项一起运行。负值将强制任务每次运行。否则，正值意味着当有需要合并在一起以保持几何级数的包文件，或者当有至少这么多松散对象将被写入新包文件时，命令应运行。默认值为 100。

maintenance.geometric-repack.splitFactor:: 此整数配置选项控制几何序列使用的因子。详见 git-repack(1) 中的 --geometric= 选项。默认为 2。

maintenance.reflog-expire.auto:: 此整数配置选项控制 reflog-expire 任务作为 git maintenance run --auto 的一部分应多久运行一次。如果为零，则 reflog-expire 任务不会与 --auto 选项一起运行。负值将强制任务每次运行。否则，正值意味着当 "HEAD" reflog 中过期的 reflog 条目数量至少为 maintenance.loose-objects.auto 的值时，命令应运行。默认值为 100。

maintenance.rerere-gc.auto:: 此整数配置选项控制 rerere-gc 任务作为 git maintenance run --auto 的一部分应多久运行一次。如果为零，则 rerere-gc 任务不会与 --auto 选项一起运行。负值将强制任务每次运行。否则，任何正值意味着当 "rr-cache" 目录存在且至少有一个条目时，命令将运行，无论其是否过期。此启发式方法将来可能会改进。默认值为 1。

maintenance.worktree-prune.auto:: 此整数配置选项控制 worktree-prune 任务作为 git maintenance run --auto 的一部分应多久运行一次。如果为零，则 worktree-prune 任务不会与 --auto 选项一起运行。负值将强制任务每次运行。否则，正值意味着当可修剪的工作树数量超过该值时，命令应运行。默认值为 1。

man.viewer:: 指定可用于以 'man' 格式显示帮助的程序。参见 git-help(1)。

man.<tool>.cmd:: 指定调用指定 man 查看器的命令。指定的命令在 shell 中求值，man 页面作为参数传递。（参见 git-help(1)。）

man.<tool>.path:: 覆盖给定工具的路径，该工具可用于以 'man' 格式显示帮助。参见 git-help(1)。

merge.conflictStyle:: 指定合并时将冲突块写入工作树文件的样式。默认为 "merge"，显示 +<<<<<<<+ 冲突标记、一侧所做的更改、======= 标记、另一侧所做的更改，然后是 +>>>>>>>+ 标记。另一种样式 "diff3" 在 ======= 标记之前添加 +|||||||+ 标记和原始文本。"merge" 样式往往比 diff3 产生更小的冲突区域，既因为排除了原始文本，也因为当两侧的行子集匹配时，它们会被直接从冲突区域中拉出。另一种样式 "zdiff3" 类似于 diff3，但当匹配行出现在冲突区域的开头或结尾附近时，会从冲突区域中移除两侧的匹配行。

merge.defaultToUpstream:: 如果调用合并时没有提交参数，则使用存储在其远程跟踪分支中的最后观察值合并为当前分支配置的上游分支。branch.<current branch>.merge 的值用于命名由 branch.<current-branch>.remote 命名的远程上的分支，然后通过 remote.<remote>.fetch 映射到相应的远程跟踪分支，并合并这些跟踪分支的提示。默认为 true。

merge.ff:: 默认情况下，当合并当前分支后代的提交时，Git 不会创建额外的合并提交。相反，当前分支的提示会被快进。当设置为 false 时，此变量告诉 Git 在这种情况下创建额外的合并提交（等同于从命令行给出 --no-ff 选项）。当设置为 only 时，只允许此类快进合并（等同于从命令行给出 --ff-only 选项）。

merge.verifySignatures:: 如果为 true，这等同于 --verify-signatures 命令行选项。详见 git-merge(1)。

merge.branchdesc:: 除了分支名称外，还使用与之关联的分支描述文本填充日志消息。默认为 false。

merge.log:: 除了分支名称外，还使用正在合并的实际提交的最多指定数量的单行描述填充日志消息。默认为 false，true 是 20 的同义词。

merge.suppressDest:: 通过将匹配集成分支名称的 glob 添加到此多值配置变量，为合并到这些集成分支计算的默认合并消息将从其标题中省略 "into <branch-name>"。 + 空值的元素可用于清除从先前配置条目积累的 glob 列表。当未定义 merge.suppressDest 变量时，使用 master 的默认值以保持向后兼容性。

merge.renameLimit:: 合并期间详尽重命名检测中要考虑的文件数量。如果未指定，默认为 diff.renameLimit 的值。如果 merge.renameLimit 和 diff.renameLimit 都未指定，目前默认为 7000。如果关闭了重命名检测，此设置无效。

merge.renames:: Git 是否检测重命名。如果设置为 false，则禁用重命名检测。如果设置为 true，则启用基本重命名检测。默认为 diff.renames 的值。

merge.directoryRenames:: Git 是否检测目录重命名，影响合并时当历史一侧添加到目录的新文件在历史另一侧被重命名时会发生什么。可能的值为：

conflict;; A conflict will be reported for such paths.

如果 merge.renames 为 false，则 merge.directoryRenames 被忽略并视为 false。默认为 conflict。

merge.renormalize:: 告诉 Git 仓库中文件的规范表示已随时间变化（例如早期提交以 CRLF 行结束符记录文本文件，但最近的使用 LF 行结束符）。在此类仓库中，对于需要三方内容合并的每个文件，Git 可以在执行合并之前将提交中记录的数据转换为规范形式，以减少不必要的冲突。有关更多信息，请参见 gitattributes(5) 中的"合并具有不同签入/签出属性的分支"部分。

merge.stat:: 在合并结束时，在 ORIG_HEAD 和合并结果之间打印什么（如果有的话）。可能的值为：

compact;; Show git diff --compact-summary ORIG_HEAD.

但任何无法识别的值（例如由未来版本的 Git 添加的值）被视为 true 而不是触发错误。默认为 true。

merge.autoStash:: 当设置为 true 时，在操作开始前自动创建临时 stash 条目，并在操作结束后应用它。这意味着您可以在脏工作树上运行合并。但请谨慎使用：成功合并后的最终 stash 应用可能会导致非平凡的冲突。此选项可以被 git-merge(1) 的 --no-autostash 和 --autostash 选项覆盖。默认为 false。

merge.tool:: 控制 git-mergetool(1) 使用哪个合并工具。下面的列表显示了有效的内置值。任何其他值被视为自定义合并工具，需要定义相应的 mergetool.<tool>.cmd 变量。

merge.guitool:: 控制 git-mergetool(1) 在给出 -g/--gui 标志时使用哪个合并工具。下面的列表显示了有效的内置值。任何其他值被视为自定义合并工具，需要定义相应的 mergetool.<guitool>.cmd 变量。

<!-- 包含文件不存在: {build_dir}/mergetools-merge.adoc --> merge.verbosity:: 控制递归合并策略显示的输出量。级别 0 不输出任何内容，除非检测到冲突时输出最终错误消息。级别 1 仅输出冲突，2 输出冲突和文件更改。级别 5 及以上输出调试信息。默认为级别 2。可以被 GIT_MERGE_VERBOSITY 环境变量覆盖。

merge.<driver>.name:: 为自定义低级合并驱动程序定义人类可读的名称。详见 gitattributes(5)。

merge.<driver>.driver:: 定义实现自定义低级合并驱动程序的命令。详见 gitattributes(5)。

merge.<driver>.recursive:: 命名在执行公共祖先之间的内部合并时使用的低级合并驱动程序。详见 gitattributes(5)。

mergetool.<tool>.path:: 覆盖给定工具的路径。当您的工具不在 $PATH 中时很有用。

mergetool.<tool>.cmd:: 指定调用指定合并工具的命令。指定的命令在 shell 中求值，以下变量可用：BASE 是包含要合并文件的公共基础的临时文件名称（如果可用）；LOCAL 是包含当前分支上文件内容的临时文件名称；REMOTE 是包含正在合并的分支上文件内容的临时文件名称；MERGED 包含合并工具应将成功合并的结果写入的文件名称。

mergetool.<tool>.hideResolved:: 允许用户为特定工具覆盖全局 mergetool.hideResolved 值。完整描述请参见 mergetool.hideResolved。

mergetool.<tool>.trustExitCode:: 对于自定义合并命令，指定合并命令的退出码是否可用于确定合并是否成功。如果未设置为 true，则检查合并目标文件时间戳，如果文件已更新则假定合并成功；否则，提示用户指示合并的成功。

mergetool.meld.hasOutput:: 旧版本的 meld 不支持 --output 选项。Git 会通过检查 meld --help 的输出来尝试检测 meld 是否支持 --output。配置 mergetool.meld.hasOutput 将使 Git 跳过这些检查并使用配置的值。将 mergetool.meld.hasOutput 设置为 true 告诉 Git 无条件使用 --output 选项，设置为 false 则避免使用 --output。

mergetool.meld.useAutoMerge:: 当给出 --auto-merge 时，meld 将自动合并非冲突部分，高亮冲突部分，并等待用户决定。将 mergetool.meld.useAutoMerge 设置为 true 告诉 Git 无条件使用 meld 的 --auto-merge 选项。将此值设置为 auto 使 git 检测是否支持 --auto-merge，仅在可用时使用。值为 false 则完全避免使用 --auto-merge，这是默认值。

mergetool.<variant>.layout:: 配置 vimdiff 的 <variant> 的分屏窗口布局，可以是 vimdiff、nvimdiff、gvimdiff 中的任何一个。当使用 --tool=<variant> 启动 git mergetool 时（或者如果 merge.tool 配置为 <variant> 则不使用 --tool），Git 将查阅 mergetool.<variant>.layout 以确定工具的布局。如果变体特定的配置不可用，则使用 vimdiff 的配置作为回退。如果那也不可用，将使用具有 4 个窗口的默认布局。 ifdef::git-mergetool[] 要配置布局，请参见"后端特定提示"部分。 endif::[] ifndef::git-mergetool[] 要配置布局，请参见 git-mergetool(1) 中的"后端特定提示"部分。 endif::[]

mergetool.hideResolved:: 在合并期间，Git 将自动解决尽可能多的冲突，并写入包含其无法解决的冲突周围的冲突标记的 $MERGED 文件；$LOCAL 和 $REMOTE 通常是 Git 冲突解决之前的文件版本。此标志导致 $LOCAL 和 $REMOTE 被覆盖，以便仅将未解决的冲突呈现给合并工具。可以通过 mergetool.<tool>.hideResolved 配置变量按工具配置。默认为 false。

mergetool.keepBackup:: 执行合并后，带有冲突标记的原始文件可以保存为带有 .orig 扩展名的文件。如果此变量设置为 false，则不保留此文件。默认为 true（即保留备份文件）。

mergetool.keepTemporaries:: 调用自定义合并工具时，Git 使用一组临时文件传递给工具。如果工具返回错误且此变量设置为 true，则这些临时文件将被保留；否则，它们将在工具退出后被移除。默认为 false。

mergetool.writeToTemp:: 默认情况下，Git 在工作树中写入冲突文件的临时 BASE、LOCAL 和 REMOTE 版本。当设置为 true 时，Git 将尝试使用临时目录存储这些文件。默认为 false。

mergetool.prompt:: 每次调用合并解决程序前提示。

mergetool.guiDefault:: 设置 true 以默认使用 merge.guitool（等同于指定 --gui 参数），或 auto 根据 DISPLAY 环境变量值的存在选择 merge.guitool 或 merge.tool。默认为 false，必须显式提供 --gui 参数才能使用 merge.guitool。

notes.mergeStrategy:: 解决笔记冲突时默认选择哪种合并策略。必须是 manual、ours、theirs、union 或 cat_sort_uniq 之一。默认为 manual。有关每种策略的更多信息，请参见 git-notes(1) 的"笔记合并策略"部分。 + 此设置可以通过向 git-notes(1) 传递 --strategy 选项来覆盖。

notes.<name>.mergeStrategy:: 当执行笔记合并到 refs/notes/<name> 时选择哪种合并策略。这覆盖更通用的 notes.mergeStrategy。有关可用策略的更多信息，请参见 git-notes(1) 中的"笔记合并策略"部分。

notes.displayRef:: 除了 core.notesRef 或 GIT_NOTES_REF 设置的默认值外，使用 git log 系列命令显示提交消息时从哪个引用（或引用，如果是 glob 或指定多次）读取笔记。 + 此设置可以被 GIT_NOTES_DISPLAY_REF 环境变量覆盖，该变量必须是以冒号分隔的引用或 glob 列表。 + 对于不存在的引用会发出警告，但不匹配任何引用的 glob 会被静默忽略。 + 此设置可以被 git-log(1) 系列命令的 --no-notes 选项或这些命令接受的 --notes=<ref> 选项禁用。 + core.notesRef 的有效值（可能被 GIT_NOTES_REF 覆盖）也会隐式添加到要显示的引用列表中。

notes.rewrite.<command>:: 当使用 <command>（目前为 amend 或 rebase）重写提交时，如果此变量为 false，git 不会将笔记从原始提交复制到重写的提交。默认为 true。另见下面的 notes.rewriteRef。 + 此设置可以被 GIT_NOTES_REWRITE_REF 环境变量覆盖，该变量必须是以冒号分隔的引用或 glob 列表。

notes.rewriteMode:: 在重写期间复制笔记时（参见 notes.rewrite.<command> 选项），确定如果目标提交已有笔记时该怎么做。必须是 overwrite、concatenate、cat_sort_uniq 或 ignore 之一。默认为 concatenate。 + 此设置可以被 GIT_NOTES_REWRITE_MODE 环境变量覆盖。

notes.rewriteRef:: 在重写期间复制笔记时，指定应复制其笔记的（完全限定的）引用。可以是 glob，在这种情况下将复制所有匹配引用中的笔记。您也可以多次指定此配置。 + 没有默认值；您必须配置此变量以启用笔记重写。将其设置为 refs/notes/commits 以启用默认提交笔记的重写。 + 可以被 GIT_NOTES_REWRITE_REF 环境变量覆盖。有关其格式的进一步描述，请参见上面的 notes.rewrite.<command>。

pack.window:: The size of the window used by git-pack-objects(1) when no window size is given on the command line. Defaults to 10.

pack.depth:: The maximum delta depth used by git-pack-objects(1) when no maximum depth is given on the command line. Defaults to 50. Maximum value is 4095.

pack.windowMemory:: The maximum size of memory that is consumed by each thread in git-pack-objects(1) for pack window memory when no limit is given on the command line. The value can be suffixed with "k", "m", or "g". When left unconfigured (or set explicitly to 0), there will be no limit.

pack.compression:: An integer -1..9, indicating the compression level for objects in a pack file. -1 is the zlib default. 0 means no compression, and 1..9 are various speed/size tradeoffs, 9 being slowest. If not set, defaults to core.compression. If that is not set, defaults to -1, the zlib default, which is "a default compromise between speed and compression (currently equivalent to level 6)." + Note that changing the compression level will not automatically recompress all existing objects. You can force recompression by passing the -F option to git-repack(1).

pack.allowPackReuse:: When true or "single", and when reachability bitmaps are enabled, pack-objects will try to send parts of the bitmapped packfile verbatim. When "multi", and when a multi-pack reachability bitmap is available, pack-objects will try to send parts of all packs in the MIDX. + If only a single pack bitmap is available, and pack.allowPackReuse is set to "multi", reuse parts of just the bitmapped packfile. This can reduce memory and CPU usage to serve fetches, but might result in sending a slightly larger pack. Defaults to true.

pack.island:: An extended regular expression configuring a set of delta islands. See "DELTA ISLANDS" in git-pack-objects(1) for details.

pack.islandCore:: Specify an island name which gets to have its objects be packed first. This creates a kind of pseudo-pack at the front of one pack, so that the objects from the specified island are hopefully faster to copy into any pack that should be served to a user requesting these objects. In practice this means that the island specified should likely correspond to what is the most commonly cloned in the repo. See also "DELTA ISLANDS" in git-pack-objects(1).

pack.deltaCacheSize:: The maximum memory in bytes used for caching deltas in git-pack-objects(1) before writing them out to a pack. This cache is used to speed up the writing object phase by not having to recompute the final delta result once the best match for all objects is found. Repacking large repositories on machines which are tight with memory might be badly impacted by this though, especially if this cache pushes the system into swapping. A value of 0 means no limit. The smallest size of 1 byte may be used to virtually disable this cache. Defaults to 256 MiB.

pack.deltaCacheLimit:: The maximum size of a delta, that is cached in git-pack-objects(1). This cache is used to speed up the writing object phase by not having to recompute the final delta result once the best match for all objects is found. Defaults to 1000. Maximum value is 65535.

pack.threads:: Specifies the number of threads to spawn when searching for best delta matches. This requires that git-pack-objects(1) be compiled with pthreads otherwise this option is ignored with a warning. This is meant to reduce packing time on multiprocessor machines. The required amount of memory for the delta search window is however multiplied by the number of threads. Specifying 0 will cause Git to auto-detect the number of CPUs and set the number of threads accordingly.

pack.indexVersion:: Specify the default pack index version. Valid values are 1 for legacy pack index used by Git versions prior to 1.5.2, and 2 for the new pack index with capabilities for packs larger than 4 GB as well as proper protection against the repacking of corrupted packs. Version 2 is the default. Note that version 2 is enforced and this config option is ignored whenever the corresponding pack is larger than 2 GB. + If you have an old Git that does not understand the version 2 *.idx file, cloning or fetching over a non-native protocol (e.g. "http") that will copy both *.pack file and corresponding *.idx file from the other side may give you a repository that cannot be accessed with your older version of Git. If the *.pack file is smaller than 2 GB, however, you can use git-index-pack(1) on the *.pack file to regenerate the *.idx file.

pack.packSizeLimit:: The maximum size of a pack. This setting only affects packing to a file when repacking, i.e. the git:// protocol is unaffected. It can be overridden by the --max-pack-size option of git-repack(1). Reaching this limit results in the creation of multiple packfiles. + Note that this option is rarely useful, and may result in a larger total on-disk size (because Git will not store deltas between packs) and worse runtime performance (object lookup within multiple packs is slower than a single pack, and optimizations like reachability bitmaps cannot cope with multiple packs). + If you need to actively run Git using smaller packfiles (e.g., because your filesystem does not support large files), this option may help. But if your goal is to transmit a packfile over a medium that supports limited sizes (e.g., removable media that cannot store the whole repository), you are likely better off creating a single large packfile and splitting it using a generic multi-volume archive tool (e.g., Unix split). + The minimum size allowed is limited to 1 MiB. The default is unlimited. Common unit suffixes of 'k', 'm', or 'g' are supported.

pack.useBitmaps:: When true, git will use pack bitmaps (if available) when packing to stdout (e.g., during the server side of a fetch). Defaults to true. You should not generally need to turn this off unless you are debugging pack bitmaps.

pack.useBitmapBoundaryTraversal:: When true, Git will use an experimental algorithm for computing reachability queries with bitmaps. Instead of building up complete bitmaps for all of the negated tips and then OR-ing them together, consider negated tips with existing bitmaps as additive (i.e. OR-ing them into the result if they exist, ignoring them otherwise), and build up a bitmap at the boundary instead. + When using this algorithm, Git may include too many objects as a result of not opening up trees belonging to certain UNINTERESTING commits. This inexactness matches the non-bitmap traversal algorithm. + In many cases, this can provide a speed-up over the exact algorithm, particularly when there is poor bitmap coverage of the negated side of the query.

pack.useSparse:: When true, git will default to using the '--sparse' option in 'git pack-objects' when the '--revs' option is present. This algorithm only walks trees that appear in paths that introduce new objects. This can have significant performance benefits when computing a pack to send a small change. However, it is possible that extra objects are added to the pack-file if the included commits contain certain types of direct renames. Default is true.

pack.usePathWalk:: Enable the --path-walk option by default for git pack-objects processes. See git-pack-objects(1) for full details.

pack.preferBitmapTips:: Specifies a ref hierarchy (e.g., "refs/heads/"); can be given multiple times to specify more than one hierarchy. When selecting which commits will receive bitmaps, prefer a commit at the tip of a reference that is contained in any of the configured hierarchies. + Note that setting this configuration to refs/foo/ does not mean that the commits at the tips of refs/foo/bar and refs/foo/baz will necessarily be selected. This is because commits are selected for bitmaps from within a series of windows of variable length. + If a commit at the tip of any reference which is a suffix of any value of this configuration is seen in a window, it is immediately given preference over any other commit in that window.

pack.writeBitmaps (deprecated):: This is a deprecated synonym for repack.writeBitmaps.

pack.writeBitmapHashCache:: When true, git will include a "hash cache" section in the bitmap index (if one is written). This cache can be used to feed git's delta heuristics, potentially leading to better deltas between bitmapped and non-bitmapped objects (e.g., when serving a fetch between an older, bitmapped pack and objects that have been pushed since the last gc). The downside is that it consumes 4 bytes per object of disk space. Defaults to true. + When writing a multi-pack reachability bitmap, no new namehashes are computed; instead, any namehashes stored in an existing bitmap are permuted into their appropriate location when writing a new bitmap.

pack.writeBitmapLookupTable:: When true, Git will include a "lookup table" section in the bitmap index (if one is written). This table is used to defer loading individual bitmaps as late as possible. This can be beneficial in repositories that have relatively large bitmap indexes. Defaults to false.

pack.readReverseIndex:: When true, git will read any .rev file(s) that may be available (see: gitformat-pack(5)). When false, the reverse index will be generated from scratch and stored in memory. Defaults to true.

pack.writeReverseIndex:: When true, git will write a corresponding .rev file (see: gitformat-pack(5)) for each new packfile that it writes in all places except for git-fast-import(1) and in the bulk checkin mechanism. Defaults to true.

pager.<cmd>:: If the value is boolean, turns on or off pagination of the output of a particular Git subcommand when writing to a tty. Otherwise, turns on pagination for the subcommand using the pager specified by the value of pager.<cmd>. If --paginate or --no-pager is specified on the command line, it takes precedence over this option. To disable pagination for all commands, set core.pager or GIT_PAGER to cat.

pretty.<name>:: pretty.<name>:: --pretty= 格式字符串的别名，如 git-log(1) 中指定。此处定义的任何别名都可以像内置 pretty 格式一样使用。例如，运行 git config pretty.changelog "format:* %H %s" 将导致调用 git log "--pretty=format:* %H %s"。请注意，与内置格式同名的别名将被静默忽略。

promisor.quiet:: 如果设置为 "true"，在为部分克隆获取额外对象时假定 --quiet。

promisor.advertise:: 如果设置为 "true"，服务器将使用 "promisor-remote" 能力（参见 gitprotocol-v2(5)）通告它使用的承诺者远程（如果有的话）。默认为 "false"，这意味着不通告 "promisor-remote" 能力。

promisor.sendFields:: 以逗号或空格分隔的额外远程相关字段名列表。当服务器使用 "promisor-remote" 能力通告其承诺者远程时，它会从其配置中发送这些字段名和关联的字段值，参见 gitprotocol-v2(5)。目前，仅支持 "partialCloneFilter" 和 "token" 字段名。 + partialCloneFilter:: 包含用于远程的部分克隆过滤器。 + token:: 包含远程的身份验证令牌。 + 当字段名是此列表的一部分且服务器上设置了相应的 "remote.foo.<field-name>" 配置变量为非空值时，则在通告承诺者远程 "foo" 时会发送字段名和值。 + 除非 "promisor.advertise" 配置变量设置为 "true"，否则此列表无效，并且无论此设置如何，"name" 和 "url" 字段始终被通告。

promisor.acceptFromServer:: 如果设置为 "all"，客户端将接受服务器可能使用 "promisor-remote" 能力通告的所有承诺者远程。如果设置为 "knownName"，客户端将接受已在客户端配置且与客户端通告的名称相同的承诺者远程。这不是很安全，但可用于服务器和客户端被信任不会切换名称和 URL 的企业环境。如果设置为 "knownUrl"，客户端将接受在客户端上配置的名称和 URL 都与服务器通告的名称和 URL 相同的承诺者远程。这比 "all" 或 "knownName" 更安全，因此如果可能应使用此选项替代那些选项。默认为 "none"，这意味着不会接受服务器通告的任何承诺者远程。通过接受承诺者远程，客户端同意服务器可以从其对客户端的 "fetch" 和 "clone" 请求的响应中省略可从此承诺者远程延迟获取的对象。名称和 URL 比较区分大小写。参见 gitprotocol-v2(5)。

promisor.checkFields:: 以逗号或空格分隔的额外远程相关字段名列表。客户端在接受承诺者远程之前，会检查服务器传输的这些字段的值是否与其自身配置中的值匹配。目前，"partialCloneFilter" 和 "token" 是唯一支持的字段名。 + 如果正在检查其中一个字段名（例如 "token"）的已通告承诺者远程（例如 "foo"），则必须满足三个条件才能通过此特定字段的检查： +

1. 必须设置相应的本地配置（例如 remote.foo.token）。
2. 服务器必须为远程 "foo" 通告 "token" 字段。
3. 本地配置的 remote.foo.token 的值必须与服务器为 "token" 字段通告的值完全匹配。

如果 promisor.checkFields 中列出的任何字段名不满足任何条件，则已通告的远程 "foo" 将被拒绝。 + 对于 "partialCloneFilter" 字段，这允许客户端确保服务器的过滤器与其本地期望的匹配，防止过滤行为的不一致。对于 "token" 字段，这可用于验证身份验证凭据是否与期望的值匹配。 + 字段值的比较区分大小写。 + "name" 和 "url" 字段始终根据 promisor.acceptFromServer 策略进行检查，与此设置无关。 + 字段名和值应由服务器通过 "promisor-remote" 能力使用 promisor.sendFields 配置变量传递。仅当 promisor.acceptFromServer 配置变量未设置为 "None" 时才检查字段。如果设置为 "None"，则此配置变量无效。参见 gitprotocol-v2(5)。

promisor.storeFields:: 以逗号或空格分隔的额外远程相关字段名列表。如果客户端接受已通告的远程，客户端将把从远程通告中获取的与这些字段名关联的值存储到其配置中，然后重新加载其远程配置。目前，"partialCloneFilter" 和 "token" 是唯一支持的字段名。 + 例如，如果服务器为远程 "foo" 通告 "partialCloneFilter=blob:limit=20k"，且该远程被接受，则 "blob:limit=20k" 将被存储到 "remote.foo.partialCloneFilter" 配置变量中。 + 如果来自已通告远程的新字段值与客户端上该远程的现有字段值相同，则不会对客户端配置进行任何更改。 + 当存储新值时，会向标准错误打印消息以通知用户。 + 请注意，出于安全原因，如果远程尚未在客户端配置，则不会为该远程存储任何内容。在任何情况下，都不会创建新的远程，也不会存储 URL。 + 在存储部分克隆过滤器之前，会解析它以检查其有效性。如果无效，会发出警告且不会存储。 + 在存储令牌之前，会执行检查以确保它不包含控制字符。如果检查失败，会发出警告且不会存储。

protocol.allow:: 如果设置，为所有没有显式策略（protocol.<name>.allow）的协议提供用户定义的默认策略。默认情况下，如果未设置，已知安全的协议（http、https、git、ssh）的默认策略为 always，已知危险的协议（ext）的默认策略为 never，所有其他协议（包括 file）的默认策略为 user。支持的策略：

hg to allow the git-remote-hg helper)

protocol.version:: 如果设置，客户端将尝试使用指定的协议版本与服务器通信。如果服务器不支持，通信将回退到版本 0。如果未设置，默认为 2。支持的版本：

...

Defaults to false.

rebase.rescheduleFailedExec:: 自动重新安排失败的 exec 命令。这仅在交互模式下（或提供了 --exec 选项时）有意义。这与指定 --reschedule-failed-exec 选项相同。

rebase.forkPoint:: 如果设置为 false，默认设置 --no-fork-point 选项。

rebase.rebaseMerges:: 是否以及如何默认设置 --rebase-merges 选项。可以是 rebase-cousins、no-rebase-cousins 或布尔值。设置为 true 或 no-rebase-cousins 等同于 --rebase-merges=no-rebase-cousins，设置为 rebase-cousins 等同于 --rebase-merges=rebase-cousins，设置为 false 等同于 --no-rebase-merges。在命令行上传递 --rebase-merges（无论是否带参数）会覆盖任何 rebase.rebaseMerges 配置。

rebase.maxLabelLength:: 从提交主题生成标签名称时，将名称截断到此长度。默认情况下，名称被截断到略小于 NAME_MAX（以允许例如为相应的松散引用写入 .lock 文件）。

receive.advertiseAtomic:: 默认情况下，git-receive-pack 将向其客户端通告原子推送能力。如果您不想通告此能力，请将此变量设置为 false。

receive.advertisePushOptions:: 当设置为 true 时，git-receive-pack 将向其客户端通告推送选项能力。默认为 false。

receive.autogc:: 默认情况下，git-receive-pack 在从 git-push 接收数据并更新引用后将运行 "git maintenance run --auto"。您可以通过将此变量设置为 false 来停止它。

receive.certNonceSeed:: 通过将此变量设置为字符串，git receive-pack 将接受 git push --signed 并通过使用以此字符串作为密钥的 HMAC 保护的 "nonce" 来验证它。

receive.certNonceSlop:: 当 git push --signed 发送的推送证书中的 "nonce" 是由服务同一仓库的 receive-pack 在此秒数内发出的，将证书中找到的 "nonce" 导出到 GIT_PUSH_CERT_NONCE 给钩子（而不是 receive-pack 要求发送方包含的内容）。这可能使在 pre-receive 和 post-receive 中编写检查稍微容易一些。他们只需检查 GIT_PUSH_CERT_NONCE_STATUS 是否为 OK，而不是检查记录 nonce 过期多少秒的 GIT_PUSH_CERT_NONCE_SLOP 环境变量来决定是否接受证书。

receive.fsckObjects:: 如果设置为 true，git-receive-pack 将检查所有接收到的对象。详见 transfer.fsckObjects 了解检查内容。默认为 false。如果未设置，则使用 transfer.fsckObjects 的值。

receive.fsck.<msg-id>:: 类似于 fsck.<msg-id>，但由 git-receive-pack(1) 而不是 git-fsck(1) 使用。详见 fsck.<msg-id> 文档。

receive.fsck.skipList:: 类似于 fsck.skipList，但由 git-receive-pack(1) 而不是 git-fsck(1) 使用。详见 fsck.skipList 文档。

receive.keepAlive:: 从客户端接收包后，receive-pack 在处理包时可能不会产生输出（如果指定了 --quiet），导致某些网络断开 TCP 连接。设置此选项后，如果 receive-pack 在此阶段 receive.keepAlive 秒内未传输任何数据，它将发送一个简短的保活包。默认为 5 秒；设置为 0 以完全禁用保活。

receive.unpackLimit:: 如果推送中接收的对象数量低于此限制，则对象将被解包为松散对象文件。然而，如果接收的对象数量等于或超过此限制，则接收的包将作为包存储，添加任何缺失的增量基。存储来自推送的包可以使推送操作完成更快，特别是在慢速文件系统上。如果未设置，则使用 transfer.unpackLimit 的值。

receive.maxInputSize:: 如果传入包流的大小超过此限制，则 git-receive-pack 将出错，而不是接受包文件。如果未设置或设置为 0，则大小不受限制。

receive.denyDeletes:: 如果设置为 true，git-receive-pack 将拒绝删除引用的引用更新。使用此选项防止通过推送删除引用。

receive.denyDeleteCurrent:: 如果设置为 true，git-receive-pack 将拒绝删除非裸仓库当前签出分支的引用更新。

receive.denyCurrentBranch:: 如果设置为 true 或 "refuse"，git-receive-pack 将拒绝更新非裸仓库当前签出分支的引用。此类推送可能很危险，因为它会使 HEAD 与索引和工作树不同步。如果设置为 "warn"，则将此类推送到 stderr 的警告，但允许推送继续。如果设置为 false 或 "ignore"，则允许此类推送且不显示消息。默认为 "refuse"。 + 另一个选项是 "updateInstead"，如果推送到当前分支，它将更新工作树。此选项旨在当一方不易通过交互式 ssh 访问时（例如实时网站，因此要求工作目录是干净的）同步工作目录。此模式在 VM 内部开发以在不同操作系统上测试和修复代码时也很方便。 + 默认情况下，"updateInstead" 如果工作树或索引与 HEAD 有任何差异，将拒绝推送，但 push-to-checkout 钩子可用于自定义此行为。参见 githooks(5)。

receive.denyNonFastForwards:: 如果设置为 true，git-receive-pack 将拒绝非快进的引用更新。使用此选项防止通过推送进行此类更新，即使推送是强制的。此配置变量在初始化共享仓库时设置。

receive.hideRefs:: 此变量与 transfer.hideRefs 相同，但仅适用于 receive-pack（因此影响推送，但不影响获取）。通过 git push 更新或删除隐藏引用的尝试将被拒绝。

receive.procReceiveRefs:: 这是一个多值变量，定义了与 receive-pack 中命令匹配的引用前缀。匹配前缀的命令将由外部钩子 "proc-receive" 执行，而不是内部的 execute_commands 函数。如果未定义此变量，则永远不会使用 "proc-receive" 钩子，所有命令将由内部的 execute_commands 函数执行。 + 例如，如果此变量设置为 "refs/for"，推送到 "refs/for/master" 等引用不会创建或更新名为 "refs/for/master" 的引用，但可能通过运行钩子 "proc-receive" 直接创建或更新拉取请求。 + 可以在值的开头提供可选修饰符以过滤特定操作的命令：创建 (a)、修改 (m)、删除 (d)。修饰符中可以包含 ! 以否定引用前缀条目。例如： + git config --system --add receive.procReceiveRefs ad:refs/heads git config --system --add receive.procReceiveRefs !:refs/heads

receive.updateServerInfo:: 如果设置为 true，git-receive-pack 在从 git-push 接收数据并更新引用后将运行 git-update-server-info。

receive.shallowUpdate:: 如果设置为 true，当新引用需要新的浅层根时，可以更新 .git/shallow。否则这些引用将被拒绝。

reftable.blockSize:: reftable 后端写入块时使用的字节大小。块大小由写入器确定，不必是 2 的幂。块大小必须大于仓库中使用的最长引用名称或日志条目，因为引用不能跨越块。 + 建议使用对虚拟内存系统或文件系统友好的 2 的幂（如 4kB 或 8kB）。较大的大小（64kB）可以产生更好的压缩，但读者在访问时可能会增加成本。 + 最大块大小为 16777215 字节（15.99 MiB）。默认值为 4096 字节（4kB）。值为 0 将使用默认值。

reftable.restartInterval:: 创建重启点的间隔。reftable 后端在文件创建时确定重启点。每 16 个可能更适合较小的块大小（4k 或 8k），每 64 个适合较大的块大小（64k）。 + 更频繁的重启点会减少前缀压缩并增加重启表占用的空间，两者都会增加文件大小。 + 较少的重启点使前缀压缩更有效，减少整体文件大小，但会增加读者在二分搜索步骤后遍历更多记录的惩罚。 + 每个块最多支持 65535 个重启点。 + 默认值是每 16 条记录创建重启点。值为 0 将使用默认值。

reftable.indexObjects:: reftable 后端是否应写入对象块。对象块是对象 ID 到指向它们的引用的反向映射。 + 默认值为 true。

reftable.geometricFactor:: 每当 reftable 后端向堆栈追加新表时，它会执行自动压缩以确保只有少量表。后端通过确保表在各自大小方面形成几何序列来实现这一点。 + 默认情况下，几何序列使用因子 2，这意味着对于任何表，下一个最大的表必须至少是其两倍大小。最大支持因子为 256。

reftable.lockTimeout:: 每当 reftable 后端向堆栈追加新表时，它必须在更新之前锁定中央 "tables.list" 文件。此配置控制在另一个进程已获取锁的情况下进程等待获取锁的时间。值 0 表示根本不重试；-1 表示无限期尝试。默认为 100（即重试 100ms）。

remote.pushDefault:: 默认推送到的远程。覆盖所有分支的 branch.<name>.remote，并被特定分支的 branch.<name>.pushRemote 覆盖。

remote.<name>.url:: 远程仓库的 URL。参见 git-fetch(1) 或 git-push(1)。配置的远程可以有多个 URL；在这种情况下，第一个用于获取，所有都用于推送（假设未定义 remote.<name>.pushurl）。将此键设置为空字符串会清除 URL 列表，允许您覆盖先前的配置。

remote.<name>.pushurl:: 远程仓库的推送 URL。参见 git-push(1)。如果配置的远程中存在 pushurl 选项，则用于推送而不是 remote.<name>.url。配置的远程可以有多个推送 URL；在这种情况下，推送到所有这些 URL。将此键设置为空字符串会清除 URL 列表，允许您覆盖先前的配置。

remote.<name>.proxy:: 对于需要 curl 的远程（http、https 和 ftp），用于该远程的代理 URL。设置为空字符串以禁用该远程的代理。

remote.<name>.proxyAuthMethod:: 对于需要 curl 的远程（http、https 和 ftp），用于对正在使用的代理进行身份验证的方法（可能在 remote.<name>.proxy 中设置）。参见 http.proxyAuthMethod。

remote.<name>.fetch:: git-fetch(1) 的默认 "refspec" 集。参见 git-fetch(1)。

remote.<name>.push:: git-push(1) 的默认 "refspec" 集。参见 git-push(1)。

remote.<name>.mirror:: 如果为 true，推送到此远程将自动表现为在命令行给出了 --mirror 选项。

remote.<name>.skipDefaultUpdate:: remote.<name>.skipFetchAll 的已弃用同义词（如果两者在配置文件中设置了不同的值，将使用最后出现的值）。

remote.<name>.skipFetchAll:: 如果为 true，当使用 git-fetch(1)、git-remote(1) 的 update 子命令更新时，将跳过此远程，并被 git maintenance 的预取任务忽略。

remote.<name>.receivepack:: 推送时在远程端执行的默认程序。参见 git-push(1) 的 --receive-pack 选项。

remote.<name>.uploadpack:: 获取时在远程端执行的默认程序。参见 git-fetch-pack(1) 的 --upload-pack 选项。

remote.<name>.tagOpt:: 将此值设置为 --no-tags 会在从远程 <name> 获取时禁用自动标签跟踪。设置为 --tags 将从远程 <name> 获取每个标签，即使它们从远程分支头不可达。将这些标志直接传递给 git-fetch(1) 可以覆盖此设置。参见 git-fetch(1) 的 --tags 和 --no-tags 选项。

remote.<name>.vcs:: 将此设置为值 <vcs> 将导致 Git 使用 git-remote-<vcs> 辅助程序与远程交互。

remote.<name>.prune:: 当设置为 true 时，默认从此远程获取也会移除远程上不再存在的任何远程跟踪引用（如同在命令行给出了 --prune 选项）。覆盖 fetch.prune 设置（如果有）。

remote.<name>.pruneTags:: 当设置为 true 时，如果通过 remote.<name>.prune、fetch.prune 或 --prune 通常激活了修剪，则从此远程获取时也会移除远程上不再存在的任何本地标签。覆盖 fetch.pruneTags 设置（如果有）。 + 另见 remote.<name>.prune 和 git-fetch(1) 的修剪部分。

remote.<name>.promisor:: 当设置为 true 时，此远程将用于获取承诺者对象。

remote.<name>.partialclonefilter:: 从此承诺者远程获取时将应用的过滤器。更改或清除此值仅影响新提交的获取。要获取已存在于本地对象数据库中的提交的关联对象，请使用 git-fetch(1) 的 --refetch 选项。

remote.<name>.serverOption:: 从此远程获取时使用的默认服务器选项集。这些服务器选项可以被 --server-option= 命令行参数覆盖。 + 这是一个多值变量，可以在更高优先级的配置文件（例如仓库中的 .git/config）中使用空值来清除从较低优先级配置文件（例如 $HOME/.gitconfig）继承的值。

remote.<name>.negotiationRestrict:: 在 git fetch 期间与此远程协商时，将作为 "have" 行通告的提交限制为仅从匹配给定模式的引用可达的那些。此多值配置选项的行为类似于命令行上的 --negotiation-restrict。 + 每个值是精确的引用名称（例如 refs/heads/release）或 glob 模式（例如 refs/heads/release/*）。模式语法与 --negotiation-restrict 相同。 + 这些配置值用作 --negotiation-restrict 命令行选项的默认值。如果在命令行上指定了 --negotiation-restrict（或其同义词 --negotiation-tip），则不使用配置值。 + 如果启用了 push.negotiate，这些值也会影响 git push 期间的协商。 + 空值表示忽略所有先前的值，允许从更广泛的配置场景重置列表。

remote.<name>.negotiationInclude:: 在 git fetch 期间与此远程协商时，客户端通告本地存在的提交列表。在具有许多引用的仓库中，此 "haves" 列表可能会被截断。根据数据形状，丢弃某些引用可能代价高昂。此多值配置选项指定引用、提交哈希或引用模式 glob，其提示应始终作为 "have" 提交在与此远程的获取协商期间发送。 + 每个值是精确的引用名称（例如 refs/heads/release）、提交哈希或 glob 模式（例如 refs/heads/release/*）。模式语法与 --negotiation-include 相同。 + 这些配置值用作 --negotiation-include 命令行选项的默认值。如果在命令行上指定了 --negotiation-include，则不使用配置值。 + 此选项与正常协商过程是累加的：协商算法仍然运行并通告其自己选择的提交，但匹配 remote.<name>.negotiationInclude 的引用在这些启发式选择的提交之上无条件发送。 + 如果启用了 push.negotiate，这些值也会影响 git push 期间的协商。 + 空值表示忽略所有先前的值，允许从更广泛的配置场景重置列表。

remote.<name>.followRemoteHEAD:: 当使用远程的配置的 refspec 获取时，git-fetch(1) 应如何处理 remotes/<name>/HEAD 的更新。默认值为 "create"，如果 remotes/<name>/HEAD 存在于远程但不存在于本地，则创建它；这不会触及已存在的本地引用。设置为 "warn" 时，如果远程的值与本地不同，将打印消息；如果没有本地引用，其行为类似于 "create"。"warn" 的变体是 "warn-if-not-$branch"，其行为类似于 "warn"，但如果远程的 HEAD 是 $branch，则保持静默。设置为 "always" 将静默地将 remotes/<name>/HEAD 更新为远程的值。最后，设置为 "never" 将永远不会更改或创建本地引用。

remotes.<group>:: 由 "git remote update <group>" 获取的远程列表。参见 git-remote(1)。

repack.useDeltaBaseOffset:: 默认情况下，git-repack(1) 创建使用增量基偏移的包。如果您需要与 Git 1.4.4 之前的版本共享仓库，无论是直接还是通过 http 等哑协议，则需要将此选项设置为 "false" 并重新打包。通过本机协议从旧 Git 版本访问不受此选项影响。

repack.packKeptObjects:: 如果设置为 true，使 git repack 表现为传递了 --pack-kept-objects。详见 git-repack(1)。通常默认为 false，但如果正在写入位图索引（通过 --write-bitmap-index 或 repack.writeBitmaps）则为 true。

repack.useDeltaIslands:: 如果设置为 true，使 git repack 表现为传递了 --delta-islands。默认为 false。

repack.writeBitmaps:: 当为 true 时，git 在将所有对象打包到磁盘时（例如运行 git repack -a 时）将写入位图索引。此索引可以加速后续为克隆和获取创建的包的"计数对象"阶段，代价是一些磁盘空间和初始重新打包的额外时间。如果创建多个包文件，此选项无效。裸仓库默认为 true，否则为 false。

repack.updateServerInfo:: 如果设置为 false，git-repack(1) 将不会运行 git-update-server-info(1)。默认为 true。当为 true 时可以被 git-repack(1) 的 -n 选项覆盖。

repack.cruftWindow:: repack.cruftWindowMemory:: repack.cruftDepth:: repack.cruftThreads:: 当未通过命令行给出相应参数时，git-pack-objects(1) 在生成 cruft 包时使用的参数。默认值和含义请参见类似命名的 pack.* 配置变量。

repack.midxMustContainCruft:: 当设置为 true 时，当使用 --write-midx 调用时，git-repack(1) 将无条件地在多包索引中包含 cruft 包（如果有的话）。当为 false 时，仅在必要时才在 MIDX 中包含 cruft 包（例如，因为它们可能需要与 MIDX 位图形成可达性闭包）。默认为 true。

repack.midxSplitFactor:: 当使用 --write-midx=incremental 选项调用 git repack 时，在压缩增量 MIDX 层期间几何合并条件中使用的因子。 + 当较新层的累积对象计数超过下一个更深层的对象计数的 1/<N> 时，相邻层将被合并。必须至少为 2。默认为 2。

repack.midxNewLayerThreshold:: 在 git repack --write-midx=incremental 期间，顶层 MIDX 层中被视为几何重新打包候选的包的最小数量。 + 当顶层的包数量少于此阈值时，这些包完全被排除在几何重新打包之外，因此保持不变。必须至少为 1。默认为 8。

rerere.autoUpdate:: 当设置为 true 时，git-rerere 在使用先前记录的解决方案干净地解决冲突后，用结果内容更新索引。默认为 false。

rerere.enabled:: 激活已解决冲突的记录，以便在再次遇到相同的冲突块时可以自动解决。默认情况下，如果 $GIT_DIR 下存在 rr-cache 目录（例如仓库中先前使用过 "rerere"），则启用 git-rerere(1)。

revert.reference:: 将此变量设置为 true 使 git revert 表现为给出了 --reference 选项。

safe.bareRepository:: 指定 Git 将与哪些裸仓库一起工作。当前支持的值为： +

• all：Git 与所有裸仓库一起工作。这是 Git 2.x 中的默认值。
• explicit：Git 仅与通过顶层 --git-dir 命令行选项或 GIT_DIR 环境变量指定的裸仓库一起工作（参见 git(1)）。这将是 Git 3.0 中的默认值。

如果您在工作流中不使用裸仓库，那么在全局配置中将 safe.bareRepository 设置为 explicit 可能有益。这将保护您免受涉及克隆包含裸仓库的仓库并在该目录中运行 Git 命令的攻击。 + 如果您定期使用裸仓库并希望在升级到 Git 3.0 后保留当前行为，请在全局或系统配置中将 safe.bareRepository 设置为 all。 + 此配置设置仅在受保护的配置中被尊重（参见 <<SCOPES>>）。这防止不受信任的仓库篡改此值。

safe.directory:: 这些配置条目指定 Git 跟踪的目录，即使它们由当前用户以外的人拥有也被视为安全。默认情况下，Git 甚至拒绝解析由其他人拥有的仓库的 Git 配置，更不用说运行其钩子了，此配置设置允许用户指定例外，例如用于有意共享的仓库（参见 git-init(1) 中的 --shared 选项）。 + 这是一个多值设置，即您可以通过 git config --add 添加多个目录。要重置安全目录列表（例如覆盖系统配置中指定的任何此类目录），请添加一个空值的 safe.directory 条目。 + 此配置设置仅在受保护的配置中被尊重（参见 <<SCOPES>>）。这防止不受信任的仓库篡改此值。 + 此设置的值会被插值，即 ~/<path> 扩展为相对于主目录的路径，%(prefix)/<path> 扩展为相对于 Git（运行时）前缀的路径。 + 要完全退出此安全检查，请将 safe.directory 设置为字符串 *。这将允许所有仓库被视为其目录已列在 safe.directory 列表中。如果在系统配置中设置了 safe.directory=* 并且您想重新启用此保护，请在列出您认为安全的仓库之前用空值初始化您的列表。给出以 /* 结尾的目录将允许访问命名目录下的所有仓库。 + 如前所述，默认情况下 Git 仅允许您访问自己（即运行 Git 的用户）拥有的仓库。然而，当 Git 在提供 sudo 的非 Windows 平台上以 'root' 运行时，git 会检查 sudo 创建的 SUDO_UID 环境变量，并允许访问记录为其值的 uid 以及 'root' 的 id。 这是为了在安装期间轻松执行常见序列 "make && sudo make install"。在 'sudo' 下运行的 git 进程以 'root' 运行，但 'sudo' 命令导出环境变量以记录原始用户的 id。 如果这不是您想要的，并且希望 git 仅信任 root 拥有的仓库，那么您可以在调用 git 之前从 root 的环境中移除 SUDO_UID 变量。

sendemail.identity:: 配置标识。给定时，导致 sendemail.<identity> 子部分中的值优先于 sendemail 部分中的值。默认标识是 sendemail.identity 的值。

sendemail.smtpEncryption:: 描述参见 git-send-email(1)。请注意，此设置不受 identity 机制的影响。

sendemail.smtpSSLCertPath:: CA 证书的路径（目录或单个文件）。设置为空字符串以禁用证书验证。

sendemail.smtpSSLClientCert:: 如果服务器请求，要呈现的客户端证书文件路径。当服务器设置为验证客户端证书时，这是必需的。如果相应的私钥未包含在文件中，则必须使用 sendemail.smtpSSLClientKey 或 --smtp-ssl-client-key 选项提供。

sendemail.smtpSSLClientKey:: 与客户端证书对应的客户端私钥文件路径。为避免配置错误，此配置必须与 sendemail.smtpSSLClientCert 或 --smtp-ssl-client-cert 选项结合使用。如果客户端密钥包含在客户端证书中，私钥的选择取决于证书的格式。详见 https://metacpan.org/pod/IO::Socket::SSL。

sendemail.<identity>.*:: 下面找到的 sendemail.* 参数的标识特定版本，当通过命令行或 sendemail.identity 选择此标识时，优先于这些参数。

sendemail.multiEdit:: 如果为 true（默认），将生成单个编辑器实例来编辑您需要编辑的文件（使用 --annotate 时的补丁，以及使用 --compose 时的摘要）。如果为 false，文件将逐个编辑，每次生成新的编辑器。

sendemail.confirm:: 设置发送前是否确认的默认值。必须是 always、never、cc、compose 或 auto 之一。有关这些值的含义，请参见 git-send-email(1) 文档中的 --confirm。

sendemail.mailmap:: 如果为 true，使 git-send-email(1) 假定 --mailmap，否则假定 --no-mailmap。默认为 False。

sendemail.mailmap.file:: git-send-email(1) 特定的增强 mailmap 文件的位置。默认 mailmap 和 mailmap.file 首先加载。因此，此文件中的条目优先于默认 mailmap 位置中的条目。参见 gitmailmap(5)。

sendemail.mailmap.blob:: 类似于 sendemail.mailmap.file，但将值视为仓库中 blob 的引用。sendemail.mailmap.file 中的条目优先于此处的条目。参见 gitmailmap(5)。

sendemail.aliasesFile:: 为避免输入长电子邮件地址，请将其指向一个或多个电子邮件别名文件。您还必须提供 sendemail.aliasFileType。

sendemail.aliasFileType:: sendemail.aliasesFile 中指定的文件格式。必须是 mutt、mailrc、pine、elm、gnus 或 sendmail 之一。 + 每种格式的别名文件是什么样的可以在同名电子邮件程序的文档中找到。与标准格式的差异和限制描述如下：

recognized by the parser.

sendemail.annotate:: sendemail.bcc:: sendemail.cc:: sendemail.ccCmd:: sendemail.chainReplyTo:: sendemail.envelopeSender:: sendemail.from:: sendemail.headerCmd:: sendemail.signedOffByCc:: sendemail.smtpPass:: sendemail.suppressCc:: sendemail.suppressFrom:: sendemail.to:: sendemail.toCmd:: sendemail.smtpDomain:: sendemail.smtpServer:: sendemail.smtpServerPort:: sendemail.smtpServerOption:: sendemail.smtpUser:: sendemail.imapSentFolder:: sendemail.useImapOnly:: sendemail.thread:: sendemail.transferEncoding:: sendemail.validate:: sendemail.xmailer:: 这些配置变量都为 git-send-email(1) 命令行选项提供默认值。详见其文档。

sendemail.outlookidfix:: 如果为 true，使 git-send-email(1) 假定 --outlook-id-fix，如果为 false 则假定 --no-outlook-id-fix。如果未指定，其行为与未指定 --outlook-id-fix 相同。

sendemail.signedOffCc (deprecated):: sendemail.signedOffByCc 的已弃用别名。

sendemail.smtpBatchSize:: 每次连接发送的消息数，之后将重新登录。如果值为 0 或未定义，在一个连接中发送所有消息。另见 git-send-email(1) 的 --batch-size 选项。

sendemail.smtpReloginDelay:: 重新连接到 SMTP 服务器之前等待的秒数。另见 git-send-email(1) 的 --relogin-delay 选项。

sendemail.forbidSendmailVariables:: 为避免常见的配置错误，如果存在 sendmail 的任何配置选项，git-send-email(1) 将中止并发出警告。设置此变量以绕过检查。

sequence.editor:: git rebase -i 用于编辑变基指令文件的文本编辑器。使用时该值由 shell 解释。可以被 GIT_SEQUENCE_EDITOR 环境变量覆盖。未配置时，使用默认的提交消息编辑器。

showBranch.default:: git-show-branch(1) 的默认分支集。参见 git-show-branch(1)。

sideband.allowControlCharacters:: 默认情况下，通过边带传递的控制字符会被屏蔽，ANSI 颜色序列除外。这防止可能不需要的 ANSI 转义序列被发送到终端。使用此配置设置覆盖此行为（值可以是以下关键字的逗号分隔列表）：

Allow all control characters to be sent to the terminal.

sideband.<url>.*:: 将 sideband.* 选项选择性地应用于特定 URL。与 http.<url>.* 设置使用相同的 URL 匹配逻辑。

sparse.expectFilesOutsideOfPatterns:: 通常对于稀疏检出，不匹配任何稀疏模式的文件在索引中标记为 SKIP_WORKTREE 位，并在工作树中缺失。因此，Git 通常会检查具有 SKIP_WORKTREE 位的文件是否确实存在于工作树中，与预期相反。如果 Git 找到任何此类文件，它会通过清除相关的 SKIP_WORKTREE 位将这些路径标记为存在。此选项可用于告诉 Git 此类尽管被跳过但仍存在的文件是预期的，并停止检查它们。 + 默认为 false，允许 Git 从索引和工作树中的文件列表不同步中自动恢复。 + 如果您在某种外部因素免除 Git 维护工作树文件存在与稀疏模式之间一致性的责任的设置中，请将此设置为 true。例如，如果您有一个 Git 感知的虚拟文件系统，该系统具有基于访问模式保持工作树和稀疏模式最新的健壮机制。 + 无论此设置如何，除非启用稀疏检出，否则 Git 不会检查尽管被跳过但仍存在的文件，因此除非 core.sparseCheckout 为 true，否则此配置选项无效。

splitIndex.maxPercentChange:: 当使用拆分索引功能时，这指定在写入新的共享索引之前，拆分索引可以包含的条目百分比（与拆分索引和共享索引中的总条目数相比）。值应在 0 到 100 之间。如果值为 0，则始终写入新的共享索引；如果为 100，则永不写入新的共享索引。默认情况下，值为 20，因此如果拆分索引中的条目数将大于总条目数的 20%，则写入新的共享索引。参见 git-update-index(1)。

splitIndex.sharedIndexExpire:: 当使用拆分索引功能时，自从此变量指定的时间以来未修改的共享索引文件将在创建新的共享索引文件时被移除。值 "now" 立即过期所有条目，"never" 完全抑制过期。默认值为 "2.weeks.ago"。请注意，每次基于共享索引文件创建新的拆分索引文件或从中读取时，共享索引文件都被视为已修改（出于过期目的）。参见 git-update-index(1)。

ssh.variant:: 默认情况下，Git 根据配置的 SSH 命令的基本名称确定要使用的命令行参数（使用环境变量 GIT_SSH 或 GIT_SSH_COMMAND 或配置设置 core.sshCommand 配置）。如果基本名称无法识别，Git 将尝试通过首先使用 -G（打印配置）选项调用配置的 SSH 命令来检测 OpenSSH 选项的支持，随后将使用 OpenSSH 选项（如果成功）或除主机和远程命令外不使用选项（如果失败）。 + 配置变量 ssh.variant 可以设置为覆盖此检测。有效值为 ssh（使用 OpenSSH 选项）、plink、putty、tortoiseplink、simple（除主机和远程命令外无选项）。可以使用值 auto 显式请求默认自动检测。任何其他值被视为 ssh。此设置也可以通过环境变量 GIT_SSH_VARIANT 覆盖。 + The current command-line parameters used for each variant are as follows:

compareBranches = @{upstream} @

This would show comparisons against both the configured upstream and push tracking branches for the current branch.

status.displayCommentPrefix:: 如果设置为 true，git-status(1) 将在每行输出前插入注释前缀（以 core.commentChar 开头，即默认为 #）。这是 Git 1.8.4 及之前版本中 git-status(1) 的行为。默认为 false。

status.renameLimit:: 在 git-status(1) 和 git-commit(1) 中执行重命名检测时要考虑的文件数量。默认为 diff.renameLimit 的值。

status.renames:: Git 是否以及如何在 git-status(1) 和 git-commit(1) 中检测重命名。如果设置为 "false"，则禁用重命名检测。如果设置为 "true"，则启用基本重命名检测。如果设置为 "copies" 或 "copy"，Git 也将检测复制。默认为 diff.renames 的值。

status.showStash:: 如果设置为 true，git-status(1) 将显示当前存储的条目数。默认为 false。

status.showUntrackedFiles:: 默认情况下，git-status(1) 和 git-commit(1) 显示 Git 当前未跟踪的文件。仅包含未跟踪文件的目录仅显示目录名。 显示未跟踪文件意味着 Git 需要对整个仓库中的所有文件执行 lstat()， 这在某些系统上可能很慢。因此，此变量控制命令如何显示未跟踪文件。 可能的值为：

* all - Show also individual files in untracked directories.

If this variable is not specified, it defaults to 'normal'. All usual spellings for Boolean value true are taken as normal and false as no. This variable can be overridden with the -u|--untracked-files option of git-status(1) and git-commit(1).

status.submoduleSummary:: 默认为 false。如果设置为非零数字或 true（等同于 -1 或无限制数字），将启用子模块摘要并显示修改的子模块的提交摘要（参见 git-submodule(1) 的 --summary-limit 选项）。请注意，当 diff.ignoreSubmodules 设置为 'all' 或仅对 submodule.<name>.ignore=all 的子模块，摘要输出命令将被抑制。该规则的唯一例外是 status 和 commit 将显示已暂存的子模块更改。要同时查看被忽略子模块的摘要，您可以使用 --ignore-submodules=dirty 命令行选项或 'git submodule summary' 命令，该命令显示类似的输出但不遵守这些设置。

submodule.<name>.url:: 子模块的 URL。此变量通过 'git submodule init' 从 .gitmodules 文件复制到 git 配置。用户可以在通过 'git submodule update' 获取子模块之前更改配置的 URL。如果既未设置 submodule.<name>.active 也未设置 submodule.active，则此变量的存在用作指示子模块是否为 git 命令所关注的回退。详见 git-submodule(1) 和 gitmodules(5)。

submodule.<name>.update:: 子模块通过 'git submodule update' 更新的方法，这是唯一受影响的命令，其他如 'git checkout --recurse-submodules' 不受影响。它的存在是由于历史原因，当时 'git submodule' 是唯一与子模块交互的命令；像 submodule.active 和 pull.rebase 这样的设置更具体。它由 git submodule init 从 gitmodules(5) 文件填充。参见 git-submodule(1) 中 'update' 命令的描述。

submodule.<name>.branch:: 子模块的远程分支名称，由 git submodule update --remote 使用。设置此选项以覆盖 .gitmodules 文件中找到的值。详见 git-submodule(1) 和 gitmodules(5)。

submodule.<name>.fetchRecurseSubmodules:: 此选项可用于控制此子模块的递归获取。它可以被 "git fetch" 和 "git pull" 的 --[no-]recurse-submodules 命令行选项覆盖。此设置将覆盖 gitmodules(5) 文件中的设置。

submodule.<name>.ignore:: 定义在什么情况下 "git status" 和 diff 系列将子模块显示为已修改。当设置为 "all" 时，永远不会将子模块视为已修改。尽管如此，可以使用 --force 选项暂存它，然后它将显示在状态输出中。当设置为 "dirty" 时，将忽略子模块工作树的所有更改，仅考虑子模块的 HEAD 与超级项目中记录的提交之间的差异。"untracked" 还将让具有已修改跟踪文件的子模块显示出来。当设置为 "none"（默认）时，如果子模块的工作树中有未跟踪的文件，也会将子模块显示为已更改。此设置覆盖 .gitmodules 中为此子模块做出的任何设置，两种设置都可以在命令行上使用 "--ignore-submodules" 选项覆盖。'git submodule' 命令不受此设置影响。

submodule.<name>.active:: 布尔值，指示子模块是否为 git 命令所关注。此配置选项优先于 submodule.active 配置选项。详见 gitsubmodules(7)。

submodule.<name>.gitdir:: 这设置子模块 <name> 的 gitdir 路径。当启用 extensions.submodulePathConfig 时，此配置被尊重，否则无效。启用时，此配置成为子模块 gitdir 路径的唯一真实来源，如果缺失 Git 将报错。详见 git-config(1)。

submodule.active:: 一个重复字段，包含用于与子模块路径匹配以确定子模块是否为 git 命令所关注的路径规范。详见 gitsubmodules(7)。

submodule.recurse:: 布尔值，指示命令是否应默认启用 --recurse-submodules 选项。默认为 false。 + When set to true, it can be deactivated via the --no-recurse-submodules option. Note that some Git commands lacking this option may call some of the above commands affected by submodule.recurse; for instance git remote update will call git fetch but does not have a --no-recurse-submodules option. For these commands a workaround is to temporarily change the configuration value by using git -c submodule.recurse=0. + The following list shows the commands that accept --recurse-submodules and whether they are supported by this setting.

• checkout, fetch, grep, pull, push, read-tree, reset, restore and switch are always supported.
• clone and ls-files are not supported.
• branch is supported only if submodule.propagateBranches is enabled

submodule.propagateBranches:: [实验性] 布尔值，在使用 --recurse-submodules 或 submodule.recurse=true 时启用分支支持。启用此选项将允许某些命令接受 --recurse-submodules，并且某些已接受 --recurse-submodules 的命令现在将考虑分支。默认为 false。

submodule.fetchJobs:: 指定同时获取/克隆的子模块数量。正整数允许最多该数量的子模块并行获取。值为 0 将给出一些合理的默认值。如果未设置，默认为 1。

submodule.alternateLocation:: 指定克隆子模块时子模块如何获取备用位置。可能的值为 no、superproject。默认假定为 no，不添加引用。当值设置为 superproject 时，要克隆的子模块计算其相对于超级项目备用位置的备用位置。

submodule.alternateErrorStrategy:: 指定如何处理通过 submodule.alternateLocation 计算的子模块备用位置的错误。可能的值为 ignore、info、die。默认为 die。请注意，如果设置为 ignore 或 info，并且计算的备用位置有错误，则克隆将如同没有备用位置一样继续。

tag.forceSignAnnotated:: 布尔值，指定创建的注释标签是否应进行 GPG 签名。如果在命令行上指定了 --annotate，则它优先于此选项。

tag.sort:: ifdef::git-tag[] This variable controls the sort ordering of tags when displayed by git-tag. endif::git-tag[] ifndef::git-tag[] This variable controls the sort ordering of tags when displayed by git-tag(1). endif::git-tag[] Without the --sort=<value> option provided, the value of this variable will be used as the default.

tag.gpgSign:: 布尔值，指定是否所有标签都应进行 GPG 签名。在自动脚本中运行时使用此选项可能导致大量标签被签名。因此，使用代理来避免多次输入 GPG 密码很方便。请注意，此选项不影响由 -u <keyid> 或 --local-user=<keyid> 选项启用的标签签名行为。

tar.umask:: 此变量可用于限制 tar 归档条目的权限位。默认为 0002，关闭全局写入位。特殊值 "user" 表示将使用归档用户的 umask。参见 umask(2) 和 git-archive(1)。

Trace2 配置设置仅从系统和全局配置文件读取；仓库本地和工作树配置文件以及 -c 命令行参数不受尊重。

trace2.normalTarget:: 此变量控制普通目标目的地。可以被 GIT_TRACE2 环境变量覆盖。下表显示了可能的值。

trace2.perfTarget:: 此变量控制性能目标目的地。可以被 GIT_TRACE2_PERF 环境变量覆盖。下表显示了可能的值。

trace2.eventTarget:: 此变量控制事件目标目的地。可以被 GIT_TRACE2_EVENT 环境变量覆盖。下表显示了可能的值。

try both.

trace2.normalBrief:: 布尔值。当为 true 时，time、filename 和 line 字段从普通输出中省略。可以被 GIT_TRACE2_BRIEF 环境变量覆盖。默认为 false。

trace2.perfBrief:: 布尔值。当为 true 时，time、filename 和 line 字段从 PERF 输出中省略。可以被 GIT_TRACE2_PERF_BRIEF 环境变量覆盖。默认为 false。

trace2.eventBrief:: 布尔值。当为 true 时，time、filename 和 line 字段从事件输出中省略。可以被 GIT_TRACE2_EVENT_BRIEF 环境变量覆盖。默认为 false。

trace2.eventNesting:: 整数。指定事件输出中嵌套区域的期望深度。深于此值的区域将被省略。可以被 GIT_TRACE2_EVENT_NESTING 环境变量覆盖。默认为 2。

trace2.configParams:: 以逗号分隔的"重要"配置设置模式列表，应记录在 trace2 输出中。例如，core.*,remote.*.url 将导致 trace2 输出包含列出每个配置的远程的事件。可以被 GIT_TRACE2_CONFIG_PARAMS 环境变量覆盖。默认未设置。

trace2.envVars:: 以逗号分隔的"重要"环境变量列表，应记录在 trace2 输出中。例如，GIT_HTTP_USER_AGENT,GIT_CONFIG 将导致 trace2 输出包含列出 HTTP 用户代理覆盖和 Git 配置文件位置的事件（假设已设置任何）。可以被 GIT_TRACE2_ENV_VARS 环境变量覆盖。默认未设置。

trace2.destinationDebug:: 布尔值。当为 true 时，当跟踪目标目的地无法打开写入时，Git 将打印错误消息。默认情况下，这些错误被抑制，跟踪被静默禁用。可以被 GIT_TRACE2_DST_DEBUG 环境变量覆盖。

trace2.maxFiles:: 整数。当将跟踪文件写入目标目录时，如果这样做会超过此文件数量，则不写入额外的跟踪。而是写入一个哨兵文件，将阻止对此目录的进一步跟踪。默认为 0，禁用此检查。

trailer.separators:: 此选项指定哪些字符被识别为尾部分隔符。默认情况下，只有 : 被识别为尾部分隔符，除了 = 在命令行上始终被接受以与其他 git 命令兼容。 + 此选项给出的第一个字符将是在此尾部的配置中未指定其他分隔符时使用的默认字符。 + 例如，如果此选项的值为 %=$，则只有使用格式 <key><sep><value> 且 <sep> 包含 %、= 或 $ 后跟空格的行才会被视为尾部。% 将是使用的默认分隔符，因此默认情况下尾部将显示为：<key>% <value>（键和值之间将出现一个百分号和一个空格）。

trailer.where:: 此选项指定新尾部将添加的位置。 + 可以是 end（默认）、start、after 或 before。 + 如果是 end，则每个新尾部将出现在现有尾部的末尾。 + 如果是 start，则每个新尾部将出现在现有尾部的开头而不是末尾。 + 如果是 after，则每个新尾部将出现在具有相同 <key> 的最后一个尾部之后。 + 如果是 before，则每个新尾部将出现在具有相同 <key> 的第一个尾部之前。

trailer.ifexists:: 此选项使得可以选择当输入中已存在至少一个具有相同 <key> 的尾部时执行什么操作。 + 此选项的有效值为：addIfDifferentNeighbor（默认）、addIfDifferent、add、replace 或 doNothing。 + 使用 addIfDifferentNeighbor，仅当没有具有相同 (<key>, <value>) 对的尾部在新尾部将被添加的行的上方或下方时，才会添加新尾部。 + 使用 addIfDifferent，仅当输入中没有具有相同 (<key>, <value>) 对的尾部时，才会添加新尾部。 + 使用 add，即使输入中已存在一些具有相同 (<key>, <value>) 对的尾部，也会添加新尾部。 + 使用 replace，具有相同 <key> 的现有尾部将被删除，并添加新尾部。被删除的尾部将是距离新尾部添加位置最近的一个（具有相同 <key>）。 + 使用 doNothing，不执行任何操作；即如果输入中已存在具有相同 <key> 的尾部，则不添加新尾部。

trailer.ifmissing:: 此选项使得可以选择当输入中尚不存在具有相同 <key> 的尾部时执行什么操作。 + 此选项的有效值为：add（默认）和 doNothing。 + 使用 add，将添加新尾部。 + 使用 doNothing，不执行任何操作。

trailer.<key-alias>.key:: 为 <key> 定义 <key-alias>。<key-alias> 必须是 <key> 的前缀（不区分大小写）。例如，在 git config trailer.ack.key "Acked-by" 中，Acked-by 是 <key>，ack 是 <key-alias>。此配置允许在命令行上使用 "ack" <key-alias> 进行更短的 --trailer "ack:..." 调用，而不是更长的 --trailer "Acked-by:..."。 + 在 <key> 的末尾，可以出现分隔符后跟一些空格字符。默认情况下唯一有效的分隔符是 :，但可以使用 trailer.separators 配置变量更改。 + 如果键中有分隔符，则在添加尾部时覆盖默认分隔符。

trailer.<key-alias>.where:: 此选项接受与 trailer.where 配置变量相同的值，并覆盖该选项为具有指定 <key-alias> 的尾部指定的内容。

trailer.<key-alias>.ifexists:: 此选项接受与 trailer.ifexists 配置变量相同的值，并覆盖该选项为具有指定 <key-alias> 的尾部指定的内容。

trailer.<key-alias>.ifmissing:: 此选项接受与 trailer.ifmissing 配置变量相同的值，并覆盖该选项为具有指定 <key-alias> 的尾部指定的内容。

trailer.<key-alias>.command:: 已弃用，推荐使用 trailer.<key-alias>.cmd。此选项的行为与 trailer.<key-alias>.cmd 相同，只是它不向指定命令传递任何参数。而是子字符串 $ARG 的第一次出现被将作为参数传递的 <value> 替换。 + 请注意，用户命令中的 $ARG 仅被替换一次，并且替换 $ARG 的原始方式不安全。 + 当为同一个 <key-alias> 同时给出 trailer.<key-alias>.cmd 和 trailer.<key-alias>.command 时，使用 trailer.<key-alias>.cmd，忽略 trailer.<key-alias>.command。

trailer.<key-alias>.cmd:: 此选项可用于指定一个 shell 命令，该命令将被调用一次以自动添加具有指定 <key-alias> 的尾部，然后每次指定 --trailer <key-alias>=<value> 参数时调用以修改此选项将产生的尾部的 <value>。 + 当指定的命令首次被调用以添加具有指定 <key-alias> 的尾部时，其行为如同在 git-interpret-trailers(1) 的开头添加了一个特殊的 --trailer <key-alias>=<value> 参数，其中 <value> 被视为命令的标准输出，修剪掉任何前导和尾随空白。 + 如果命令行上还传递了一些 --trailer <key-alias>=<value> 参数，则命令将为每个具有相同 <key-alias> 的参数再次调用一次。这些参数的 <value> 部分（如果有的话）将作为其第一个参数传递给命令。这样命令可以从 --trailer <key-alias>=<value> 参数中传递的 <value> 计算出 <value>。

transfer.credentialsInUrl:: 配置的 URL 可以包含明文凭据，格式为 <protocol>://<user>:<password>@<domain>/<path>。您可能希望警告或禁止使用此类配置（转而使用 git-credential(1)）。这将用于 git-clone(1)、git-fetch(1)、git-push(1) 以及配置的 URL 的任何其他直接使用。 + 请注意，目前仅限于检测 remote.<name>.url 配置中的凭据；不会检测 remote.<name>.pushurl 配置中的凭据。 + 您可能希望启用此功能以防止意外暴露凭据，例如因为： +

• 您运行 git 的操作系统或系统可能不提供方式或不允许您配置存储用户名和/或密码的配置文件的权限。
• 即使提供了，将此类数据"静态"存储可能会以其他方式暴露您，例如备份过程可能将数据复制到另一个系统。
• git 程序将在命令行上将完整 URL 作为参数相互传递，这意味着凭据将暴露给允许查看其他用户完整进程列表的系统上的其他非特权用户。在 linux 上，procfs(5) 中记录的 "hidepid" 设置允许配置此行为。

如果此类担忧不适用于您，那么您可能不需要担心由于在 git 的配置文件中存储敏感数据而导致的凭据暴露。如果您确实想使用此功能，请将 transfer.credentialsInUrl 设置为以下值之一： +

• allow（默认）：Git 将继续其活动而不发出警告。
• warn：Git 在解析包含明文凭据的 URL 时将向 stderr 写入警告消息。
• die：Git 在解析包含明文凭据的 URL 时将向 stderr 写入失败消息。

transfer.fsckObjects:: 当未设置 fetch.fsckObjects 或 receive.fsckObjects 时，使用此变量的值代替。默认为 false。 + 设置后，获取或接收将在对象格式错误或链接到不存在的对象时中止。此外，还会检查各种其他问题，包括遗留问题（参见 fsck.<msg-id>），以及潜在的安全问题，如 .GIT 目录的存在或恶意 .gitmodules 文件（详见 v2.2.1 和 v2.17.1 的发行说明）。其他健全性和安全检查可能会在未来的版本中添加。 + 在接收端，fsckObjects 失败将使这些对象不可达，参见 git-receive-pack(1) 中的"隔离环境"。在获取端，格式错误的对象将被留在仓库中未被引用。 + 由于 fetch.fsckObjects 实现的非隔离性质，不能像 receive.fsckObjects 那样依赖它来保持对象存储干净。 + 当对象被解包时，它们被写入对象存储，因此可能存在恶意对象被引入的情况，即使 "fetch" 失败，后续的 "fetch" 也可能成功，因为只检查新传入的对象，而不检查已写入对象存储的对象。不应依赖这种行为差异。将来，此类对象也可能被隔离用于 "fetch"。 + 目前，如果偏执者想要与 "push" 相同的保护，需要找到某种方式来模拟隔离环境。例如，在内部镜像的情况下，分两步执行镜像，一步获取不受信任的对象，然后执行第二次 "push"（将使用隔离）到另一个内部仓库，并让内部客户端使用这个推送到的仓库，或者禁止内部获取，只允许在运行完整的 "fsck" 后才允许它们（并且在此期间没有新的获取发生）。

transfer.hideRefs:: receive-pack 和 upload-pack 使用的字符串，用于决定从初始通告中省略哪些引用。使用多个定义来指定多个前缀字符串。在此变量下列出的层次结构下的引用被排除，并在响应 git push 或 git fetch 时被隐藏。参见 receive.hideRefs 和 uploadpack.hideRefs 了解此配置的程序特定版本。 + 您还可以在引用名称前包含 ! 以否定条目，显式暴露它，即使先前的条目将其标记为隐藏。如果您有多个 hideRefs 值，后面的条目覆盖前面的条目（更具体的配置文件中的条目覆盖不太具体的条目）。 + 如果正在使用命名空间，则在匹配 transfer.hiderefs 模式之前，会从每个引用中剥离命名空间前缀。要在剥离之前匹配引用，请在引用名称前添加 ^。如果组合 ! 和 ^，必须先指定 !。 + 例如，如果在 transfer.hideRefs 中指定了 refs/heads/master，且当前命名空间为 foo，则 refs/namespaces/foo/refs/heads/master 将从通告中省略。如果设置了 uploadpack.allowRefInWant，upload-pack 将在协议 v2 fetch 命令中将 want-ref refs/heads/master 视为 refs/namespaces/foo/refs/heads/master 不存在。另一方面，receive-pack 仍将通告引用指向的对象 ID，而不提及它的名称（即所谓的 ".have" 行）。 + 即使您隐藏了引用，客户端仍可能通过 gitnamespaces(7) 手册页"安全部分"中描述的技术窃取目标对象；最好将私有数据保存在单独的仓库中。

transfer.unpackLimit:: 当未设置 fetch.unpackLimit 或 receive.unpackLimit 时，使用此变量的值代替。默认值为 100。

transfer.advertiseSID:: 布尔值。当为 true 时，客户端和服务器进程将向其远程对等方通告其唯一会话 ID。默认为 false。

transfer.bundleURI:: 当为 true 时，本地 git clone 命令将从远程服务器请求包信息（如果已通告）并在通过 Git 协议继续克隆之前下载包。默认为 false。

transfer.advertiseObjectInfo:: 当为 true 时，服务器通告 object-info 能力。默认为 false。

uploadarchive.allowUnreachable:: 如果为 true，允许客户端使用 git archive --remote 请求任何树，无论是否从引用提示可达。详见 git-upload-archive(1) 的"安全部分"中的讨论。默认为 false。

uploadpack.hideRefs:: 此变量与 transfer.hideRefs 相同，但仅适用于 upload-pack（因此仅影响获取，不影响推送）。通过 git fetch 获取隐藏引用的尝试将失败。另见 uploadpack.allowTipSHA1InWant。

uploadpack.allowTipSHA1InWant:: 当 uploadpack.hideRefs 生效时，允许 upload-pack 接受请求隐藏引用提示处对象的获取请求（默认情况下，此类请求被拒绝）。另见 uploadpack.hideRefs。即使此选项为 false，客户端仍可能通过 gitnamespaces(7) 手册页"安全部分"中描述的技术窃取对象；最好将私有数据保存在单独的仓库中。

uploadpack.allowReachableSHA1InWant:: 允许 upload-pack 接受请求从任何引用提示可达的对象的获取请求。但请注意，计算对象可达性在计算上是昂贵的。默认为 false。即使此选项为 false，客户端仍可能通过 gitnamespaces(7) 手册页"安全部分"中描述的技术窃取对象；最好将私有数据保存在单独的仓库中。

uploadpack.allowAnySHA1InWant:: 允许 upload-pack 接受请求任何对象的获取请求。它暗示 uploadpack.allowTipSHA1InWant 和 uploadpack.allowReachableSHA1InWant。如果设置为 true，将启用两者；如果设置为 false，将禁用两者。默认未设置。

uploadpack.keepAlive:: 当 upload-pack 启动 pack-objects 后，在 pack-objects 准备包时可能会有一段安静期。通常它会输出进度信息，但如果获取时使用了 --quiet，pack-objects 在包数据开始之前将完全不输出任何内容。某些客户端和网络可能会认为服务器挂起并放弃。设置此选项指示 upload-pack 每 uploadpack.keepAlive 秒发送一个空的保活包。将此选项设置为 0 完全禁用保活包。默认为 5 秒。

uploadpack.packObjectsHook:: 如果设置了此选项，当 upload-pack 将运行 git pack-objects 为客户端创建包文件时，它将改为运行此 shell 命令。pack-objects 命令和它本应运行的参数（包括开头的 git pack-objects）被附加到 shell 命令。钩子的 stdin 和 stdout 被视为如同 pack-objects 本身被运行。即 upload-pack 将为 pack-objects 准备的输入提供给钩子，并期望在 stdout 上获得完成的包文件。 + 请注意，此配置变量仅在受保护的配置中指定时才被尊重（参见 <<SCOPES>>）。这是防止从不受信任的仓库获取的安全措施。

uploadpack.allowFilter:: 如果设置了此选项，upload-pack 将支持部分克隆和部分获取对象过滤。

uploadpackfilter.allow:: 为未指定的对象过滤器提供默认值（参见下面的配置变量）。如果设置为 true，这也将启用将来添加的所有过滤器。默认为 true。

uploadpackfilter.<filter>.allow:: 显式允许或禁止对应于 <filter> 的对象过滤器，其中 <filter> 可以是：blob:none、blob:limit、object:type、tree、sparse:oid 或 combine。如果使用组合过滤器，combine 和所有嵌套的过滤器类型都必须被允许。默认为 uploadpackfilter.allow。

uploadpackfilter.tree.maxDepth:: 仅当 <n> 不超过 uploadpackfilter.tree.maxDepth 的值时才允许 --filter=tree:<n>。如果设置，这也暗示 uploadpackfilter.tree.allow=true，除非此配置变量已被设置。如果未设置则无效。

uploadpack.allowRefInWant:: 如果设置了此选项，upload-pack 将支持协议版本 2 fetch 命令的 ref-in-want 功能。此功能旨在为由于复制延迟可能对其引用指向的 OID 没有相同视图的负载均衡服务器提供便利。

url.<base>.insteadOf:: 任何以此值开头的 URL 将被改写为以 <base> 开头。在某些站点提供大量仓库并使用多种访问方式提供服务，且某些用户需要使用不同访问方式的情况下，此功能允许人们指定任何等效 URL，并让 Git 自动将 URL 改写为特定用户的最佳替代方案，即使是站点上从未见过的仓库。当多个 insteadOf 字符串匹配给定 URL 时，使用最长匹配。 + 请注意，任何协议限制都将应用于改写后的 URL。如果改写将 URL 更改为使用自定义协议或远程辅助程序，您可能需要调整 protocol.*.allow 配置以允许请求。特别是，您期望用于子模块的协议必须设置为 always 而不是默认的 user。参见上面 protocol.allow 的描述。

url.<base>.pushInsteadOf:: 任何以此值开头的 URL 将不会被推送到；而是将其改写为以 <base> 开头，并推送到结果 URL。在某些站点提供大量仓库并使用多种访问方式提供服务，且某些方式不允许推送的情况下，此功能允许人们指定仅拉取的 URL，并让 Git 自动使用适当的 URL 进行推送，即使是站点上从未见过的仓库。当多个 pushInsteadOf 字符串匹配给定 URL 时，使用最长匹配。如果远程有显式的 pushurl，Git 将忽略该远程的此设置。

user.name:: user.email:: author.name:: author.email:: committer.name:: committer.email:: user.name 和 user.email 变量决定提交对象的 author 和 committer 字段中包含什么。如果需要 author 或 committer 不同，可以设置 author.name、author.email、committer.name 或 committer.email 变量。所有这些都可以被 GIT_AUTHOR_NAME、GIT_AUTHOR_EMAIL、GIT_COMMITTER_NAME、GIT_COMMITTER_EMAIL 和 EMAIL 环境变量覆盖。 + 请注意，这些变量的 name 形式通常指某种形式的个人姓名。有关这些设置的更多信息以及如果您正在寻找身份验证凭据，请参见 git-commit(1) 和 git(1) 的环境变量部分中的 credential.username 选项。

user.useConfigOnly:: 指示 Git 避免尝试猜测 user.email 和 user.name 的默认值，而是仅从配置中检索值。例如，如果您有多个电子邮件地址并希望为每个仓库使用不同的地址，那么在全局配置中将此配置选项设置为 true 并带有名称，Git 将在新克隆的仓库中进行新提交之前提示您设置电子邮件。默认为 false。

user.signingKey:: 如果 git-tag(1) 或 git-commit(1) 在创建签名标签或提交时没有自动选择您想要的密钥，您可以使用此变量覆盖默认选择。此选项原封不动地传递给 gpg 的 --local-user 参数，因此您可以使用 gpg 支持的任何方法指定密钥。如果 gpg.format 设置为 ssh，这可以包含您的私钥路径或使用 ssh-agent 时的公钥路径。或者它可以包含以 key:: 为前缀的公钥（例如："key::ssh-rsa XXXXXX identifier"）。私钥需要通过 ssh-agent 可用。如果未设置，Git 将调用 gpg.ssh.defaultKeyCommand（例如："ssh-add -L"）并尝试使用第一个可用的密钥。为了向后兼容，以 "ssh-" 开头的原始密钥（如 "ssh-rsa XXXXXX identifier"）被视为 "key::ssh-rsa XXXXXX identifier"，但此形式已弃用；请改用 key:: 形式。

versionsort.prereleaseSuffix (deprecated):: versionsort.suffix 的已弃用别名。如果设置了 versionsort.suffix 则被忽略。

versionsort.suffix:: 即使在 git-tag(1) 中使用版本排序，具有相同基础版本但不同后缀的标签名仍按字典序排序，导致例如预发布标签出现在主发布之后（例如 "1.0-rc1" 在 "1.0" 之后）。可以指定此变量来确定具有不同后缀的标签的排序顺序。 + 通过在此变量中指定单个后缀，任何包含该后缀的标签名将出现在相应的主发布之前。例如，如果变量设置为 "-rc"，则所有 "1.0-rcX" 标签将出现在 "1.0" 之前。如果多次指定，每个后缀一次，则配置中后缀的顺序将决定具有这些后缀的标签名的排序顺序。例如，如果配置中 "-pre" 出现在 "-rc" 之前，则所有 "1.0-preX" 标签将列在任何 "1.0-rcX" 标签之前。可以通过在其他后缀中指定空后缀来确定主发布标签相对于具有各种后缀的标签的位置。例如，如果后缀 "-rc"、""、"-ck" 和 "-bfs" 按此顺序出现在配置中，则所有 "v4.8-rcX" 标签首先列出，然后是 "v4.8"，然后是 "v4.8-ckX"，最后是 "v4.8-bfsX"。 + 如果多个后缀匹配同一个标签名，则该标签名将根据在标签名中起始位置最早的后缀进行排序。如果多个不同的匹配后缀在该最早位置开始，则该标签名将根据其中最长的后缀进行排序。如果不同后缀在多个配置文件中，则它们之间的排序顺序未定义。

web.browser:: 指定某些命令可能使用的 Web 浏览器。目前只有 git-instaweb(1) 和 git-help(1) 可能使用它。

worktree.guessRemote:: 如果未指定分支且未使用 -b、-B 或 --detach，则 git worktree add 默认从 HEAD 创建新分支。如果 worktree.guessRemote 设置为 true，worktree add 将尝试查找名称与新分支名称唯一匹配的远程跟踪分支。如果存在这样的分支，则将其签出并设置为新分支的 "upstream"。如果找不到这样的匹配，则回退到从当前 HEAD 创建新分支。

worktree.useRelativePaths:: 使用相对路径（当 "true"）或绝对路径（当 "false"）链接工作树。这对于仓库和工作树可能在不同位置或环境之间移动的设置特别有用。默认为 "false"。 + 请注意，将 worktree.useRelativePaths 设置为 "true" 意味着启用 extensions.relativeWorktrees 配置（参见 git-config(1)），从而使其与旧版本的 Git 不兼容。

缺陷

使用已弃用的 [section.subsection] 语法时，如果子节包含至少一个大写字符，更改值将导致添加一个多行键而不是更改。例如当配置如下所示时

  [section.subsection]

## key = value1

然后运行 `git config section.Subsection.key value2` 将导致

[section.subsection] key = value1

key = value2

Git

Part of the git(1) suite