Git
English ▾ 主题 ▾ 最新版本 ▾ git-config 最后更新于 2.47.0

名称

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

概要

git config list [<file-option>] [<display-option>] [--includes]
git config get [<file-option>] [<display-option>] [--includes] [--all] [--regexp] [--value=<value>] [--fixed-value] [--default=<default>] <name>
git config set [<file-option>] [--type=<type>] [--all] [--value=<value>] [--fixed-value] <name> <value>
git config unset [<file-option>] [--all] [--value=<value>] [--fixed-value] <name> <value>
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选项,否则为扩展正则表达式)。仅更新或取消设置与模式匹配的现有值。如果您想处理与模式**不**匹配的行,只需在前面添加一个感叹号(另请参阅示例),但请注意,这仅在不使用--fixed-value选项时有效。

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

读取时,默认情况下,值将从系统、全局和存储库本地配置文件中读取,并且选项--system--global--local--worktree--file <filename>可用于指示命令仅从该位置读取(请参阅文件)。

写入时,新值默认写入存储库本地配置文件,并且选项--system--global--worktree--file <filename>可用于指示命令写入该位置(您可以说--local,但这是默认值)。

此命令在出错时将以非零状态失败。一些退出代码是

  • 节或键无效 (ret=1),

  • 未提供节或名称 (ret=2),

  • 配置文件无效 (ret=3),

  • 无法写入配置文件 (ret=4),

  • 您尝试取消设置不存在的选项 (ret=5),

  • 您尝试取消设置/设置多个行匹配的选项 (ret=5),或

  • 您尝试使用无效的正则表达式 (ret=6)。

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

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

命令

list

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

get

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

set

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

unset

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

rename-section

将给定节重命名为新名称。

remove-section

从配置文件中删除给定节。

edit

打开一个编辑器来修改指定的配置文件;--system--global--local(默认)、--worktree--file <config-file>

选项

--replace-all

默认行为是最多替换一行。这将替换与键(以及可选的value-pattern)匹配的所有行。

--append

在选项中添加新行,而不更改任何现有值。这与在set中提供--value=^$相同。

--comment <message>

在新行或修改行末尾添加注释。

If _<message>_ begins with one or more whitespaces followed
by "#", it is used as-is.  If it begins with "#", a space is
prepended before it is used.  Otherwise, a string " # " (a
space followed by a hash followed by a space) is prepended
to it.  And the resulting string is placed immediately after
the value defined for the variable.  The _<message>_ must
not contain linefeed characters (no multi-line comments are
permitted).
--all

使用get,返回多值键的所有值。

--regexp

使用get,将名称解释为正则表达式。正则表达式匹配目前区分大小写,并且针对键的规范化版本进行,其中节和变量名称小写,但子节名称除外。

--url=<URL>

当给定一个两部分的<name>作为<section>.<key>时,返回<section>.<URL>.<key>的值,其<URL>部分与给定 URL 最匹配(如果不存在此类键,则使用<section>.<key>的值作为后备)。当仅给出<section>作为名称时,对该节中的所有键执行此操作并列出它们。如果未找到值,则返回错误代码 1。

--global

对于写入选项:写入全局~/.gitconfig文件而不是存储库.git/config,如果此文件存在且~/.gitconfig文件不存在,则写入$XDG_CONFIG_HOME/git/config文件。

对于读取选项:仅从全局~/.gitconfig$XDG_CONFIG_HOME/git/config读取,而不是从所有可用文件中读取。

另请参阅文件

--system

对于写入选项:写入系统范围的$(prefix)/etc/gitconfig而不是存储库.git/config

对于读取选项:仅从系统范围的$(prefix)/etc/gitconfig读取,而不是从所有可用文件中读取。

另请参阅文件

--local

对于写入选项:写入存储库.git/config文件。这是默认行为。

对于读取选项:仅从存储库.git/config读取,而不是从所有可用文件中读取。

另请参阅文件

--worktree

类似于--local,除了如果启用了extensions.worktreeConfig,则从$GIT_DIR/config.worktree读取或写入。如果没有,则与--local相同。请注意,对于主工作树,$GIT_DIR等于$GIT_COMMON_DIR,但对于其他工作树,其形式为$GIT_DIR/worktrees/<id>/。请参阅git-worktree[1]以了解如何启用extensions.worktreeConfig

-f <config-file>
--file <config-file>

对于写入选项:写入指定文件而不是存储库.git/config

对于读取选项:仅从指定文件读取,而不是从所有可用文件中读取。

另请参阅文件

--blob <blob>

类似于--file,但使用给定的 Blob 而不是文件。例如,您可以使用master:.gitmodules来读取主分支中.gitmodules文件的值。有关指定 Blob 名称的更完整列表,请参阅gitrevisions[7]中的“指定修订版本”部分。

--fixed-value

当与value-pattern参数一起使用时,将value-pattern视为一个精确的字符串,而不是正则表达式。这将限制匹配的名称/值对,仅限于值完全等于value-pattern的那些对。

--type <type>

git config将确保任何输入或输出在给定的类型约束下都是有效的,并且将以<type>的规范形式规范化输出值。

有效的<type>包括

  • bool:将值规范化为“true”或“false”。

  • int:将值规范化为简单的十进制数字。可选的后缀kmg将导致输入时值分别乘以1024、1048576或1073741824。

  • bool-or-int:根据上面描述的boolint规范化。

  • path:通过将开头的~扩展为$HOME的值,并将~user扩展为指定用户的家目录来规范化。此说明符在设置值时无效(但您可以从命令行使用git config section.variable ~/让您的 Shell 执行扩展)。

  • expiry-date:通过将固定或相对日期字符串转换为时间戳来规范化。此说明符在设置值时无效。

  • color:获取值时,通过转换为 ANSI 颜色转义序列来规范化。设置值时,将执行完整性检查以确保给定值可以规范化为 ANSI 颜色,但它将按原样写入。

--bool
--int
--bool-or-int
--path
--expiry-date

选择类型说明符的历史选项。建议改为使用--type(见上文)。

--no-type

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

-z
--null

对于所有输出值和/或键的选项,始终以空字符(而不是换行符)结束值。使用换行符作为键和值之间的分隔符。这允许安全地解析输出,而不会因包含换行符的值而感到困惑。

--name-only

仅输出listget的配置变量名称。

--show-origin

使用源类型(文件、标准输入、Blob、命令行)和实际源(配置文件路径、引用或适用的 Blob ID)增强所有查询的配置选项的输出。

--show-scope

类似于--show-origin,它使用该值的范围(工作树、本地、全局、系统、命令)增强所有查询的配置选项的输出。

--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作为后备。

--[no-]includes

在查找值时尊重配置文件中的include.*指令。当给出特定文件(例如,使用--file--global等)时,默认为off,当搜索所有配置文件时,默认为on

--default <value>

使用get时,如果未找到请求的变量,则行为就像<value>是分配给该变量的值。

已弃用的模式

以下模式已弃用,取而代之的是子命令。建议迁移到新的语法。

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 --all --show-names --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,即在使用listget可能返回多个结果时。默认情况下是使用分页器。

文件

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

$(prefix)/etc/gitconfig

系统范围的配置文件。

$XDG_CONFIG_HOME/git/config
~/.gitconfig

用户特定的配置文件。当未设置或为空时,$HOME/.config/用作$XDG_CONFIG_HOME。

这些也称为“全局”配置文件。如果两个文件都存在,则按上述顺序读取这两个文件。

$GIT_DIR/config

存储库特定的配置文件。

$GIT_DIR/config.worktree

这是可选的,仅当$GIT_DIR/config中存在extensions.worktreeConfig时才会搜索。

您还可以通过使用-c选项在运行任何 Git 命令时提供其他配置参数。有关详细信息,请参阅git[1]

选项将从所有这些可用的文件中读取。如果全局或系统范围的配置文件丢失或不可读,则将忽略它们。如果存储库配置文件丢失或不可读,git config将退出并显示非零错误代码。如果文件不可读,则会生成错误消息,但如果文件丢失则不会生成错误消息。

文件按上述顺序读取,最后找到的值优先于较早读取的值。如果采用多个值,则将使用来自所有文件的所有键值。

默认情况下,选项仅写入存储库特定的配置文件。请注意,这也影响诸如setunset之类的选项。git config每次只会更改一个文件

您可以通过使用--file选项指定文件路径,或使用--system--global--local--worktree指定配置范围来限制读取或写入哪些配置源。有关更多信息,请参见上面的选项

范围

每个配置源都属于一个配置范围。范围为

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}环境变量(见下面的环境

-c选项

除了command之外,每个范围都对应一个命令行选项:--system--global--local--worktree

读取选项时,指定范围仅会读取该范围内的文件中的选项。写入选项时,指定范围将写入该范围内的文件(而不是存储库特定的配置文件)。有关完整描述,请参见上面的选项

大多数配置选项都将被尊重,无论它是在哪个范围内定义的,但某些选项仅在特定范围内受尊重。有关完整详细信息,请参阅相应选项的文档。

受保护的配置

受保护的配置是指systemglobalcommand范围。出于安全原因,某些选项仅在受保护的配置中指定时才会被尊重,否则将被忽略。

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

环境

GIT_CONFIG_GLOBAL
GIT_CONFIG_SYSTEM

从给定文件中获取配置,而不是从全局或系统级配置中获取。有关详细信息,请参阅 git[1]

GIT_CONFIG_NOSYSTEM

是否跳过读取系统范围的 $(prefix)/etc/gitconfig 文件中的设置。有关详细信息,请参阅 git[1]

另请参阅文件

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 选项。

示例

给定一个类似这样的 .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
	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 的键/值对。

要删除重命名的条目,请执行以下操作:

% 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] 的“配置文件”部分)用于存储该存储库的配置,而 $HOME/.gitconfig 用于存储每个用户的配置作为 .git/config 文件的回退值。文件 /etc/gitconfig 可用于存储系统范围的默认配置。

Git 管道和瓷器命令都使用配置变量。变量分为多个部分,其中变量本身的完全限定变量名称是最后一个点分隔的段,部分名称是最后一个点之前的所有内容。变量名称不区分大小写,仅允许使用字母数字字符和 -,并且必须以字母字符开头。某些变量可能出现多次;然后我们说该变量是多值变量。

语法

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

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

部分可以进一步细分为子部分。要开始子部分,请在其名称放在双引号中,并在部分标题中用空格与部分名称分隔,如下例所示

	[section "subsection"]

子部分名称区分大小写,可以包含除换行符和空字节以外的任何字符。双引号 " 和反斜杠可以通过分别将其转义为 \"\\ 来包含。读取时,其他字符前面的反斜杠将被删除;例如,\t 将读取为 t,而 \0 将读取为 0。部分标题不能跨多行。变量可以直接属于某个部分或属于给定的子部分。如果您有 [section "subsection"],则可以有 [section],但您不需要。

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

所有其他行(以及部分标题后的行的其余部分)都被识别为设置变量,形式为 name = value(或仅为 name,这是一种简写,表示该变量为布尔值“true”)。变量名称不区分大小写,仅允许使用字母数字字符和 -,并且必须以字母字符开头。

围绕 name=value 的空格字符将被丢弃。value 内部的空格字符将逐字保留。以 #; 开头并扩展到行尾的注释将被丢弃。定义值的行的结尾可以使用反斜杠 (\) 继续到下一行;反斜杠和行尾字符将被丢弃。

如果 value 需要包含前导或尾随空格字符,则必须将其括在双引号 (") 中。在双引号内,必须转义双引号 (") 和反斜杠 (\) 字符:对 " 使用 \",对 \ 使用 \\

识别以下转义序列(除了 \"\\ 之外):\n 用于换行符 (NL),\t 用于水平制表符 (HT,TAB) 和 \b 用于退格符 (BS)。其他字符转义序列(包括八进制转义序列)无效。

包含

includeincludeIf 部分允许您从另一个源包含配置指令。除了 includeIf 部分在条件未计算为真时可能会被忽略外,这些部分的行为彼此相同;请参阅下面的“条件包含”。

您可以通过将特殊的 include.path(或 includeIf.*.path)变量设置为要包含的文件的名称来包含来自另一个文件的配置文件。该变量采用路径名作为其值,并受波浪线展开的影响。这些变量可以多次给出。

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

条件包含

您可以通过将 includeIf.<condition>.path 变量设置为要包含的文件的名称来有条件地包含来自另一个文件的配置文件。

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

gitdir

gitdir: 关键字后面的数据用作全局模式。如果 .git 目录的位置与模式匹配,则满足包含条件。

.git 位置可能是自动发现的,或者来自 $GIT_DIR 环境变量。如果存储库是通过 .git 文件自动发现的(例如,来自子模块或链接的工作树),则 .git 位置将是 .git 目录的最终位置,而不是 .git 文件所在的位置。

模式可以包含标准的全局通配符和两个额外的通配符 **//**,它们可以匹配多个路径组件。有关详细信息,请参阅 gitignore[5]。为了方便起见

  • 如果模式以 ~/ 开头,则 ~ 将被替换为环境变量 HOME 的内容。

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

  • 如果模式既不以 ~/./ 也不以 / 开头,则会自动在前面添加 **/。例如,模式 foo/bar 将变为 **/foo/bar,并将匹配 /any/path/to/foo/bar

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

gitdir/i

这与 gitdir 相同,只是匹配不区分大小写(例如,在不区分大小写的文件系统上)

onbranch

紧跟关键字onbranch:之后的数据被视为一个模式,该模式使用标准的通配符以及两个额外的通配符**//**,它们可以匹配多个路径组件。如果我们在一个工作树中,并且当前签出的分支名称与该模式匹配,则满足包含条件。

如果模式以/结尾,则会自动添加**。例如,模式foo/将变成foo/**。换句话说,它匹配所有以foo/开头的分支。如果您以层次结构方式组织分支,并且希望将配置应用于该层次结构中的所有分支,则此功能很有用。

hasconfig:remote.*.url:

紧跟此关键字之后的数据被视为一个模式,该模式使用标准的通配符以及两个额外的通配符**//**,它们可以匹配多个组件。第一次遇到此关键字时,将扫描其余的配置文件以查找远程URL(不应用任何值)。如果存在至少一个与该模式匹配的远程URL,则满足包含条件。

通过此选项(直接或间接)包含的文件不允许包含远程URL。

请注意,与其他includeIf条件不同,解析此条件依赖于在读取条件时尚未知的信息。一个典型的用例是此选项作为系统级或全局级配置存在,而远程URL位于本地级配置中;因此,在解析此条件时需要向前扫描。为了避免可能包含的文件可能会影响这些文件是否被包含的“先有鸡还是先有蛋”的问题,Git 通过禁止这些文件影响这些条件的解析来打破循环(从而禁止它们声明远程URL)。

至于此关键字的命名,是为了与支持更多基于变量的包含条件的命名方案向前兼容,但目前Git仅支持上面描述的精确关键字。

关于通过gitdirgitdir/i匹配的一些其他说明

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

  • 路径的符号链接和真实路径版本都将在$GIT_DIR外部匹配。例如,如果~/git是/mnt/storage/git的符号链接,则gitdir:~/gitgitdir:/mnt/storage/git都将匹配。

    在v2.13.0中此功能的初始版本中并非如此,该版本仅匹配真实路径版本。希望与此功能的初始版本兼容的配置需要指定真实路径版本或两个版本。

  • 请注意,"../"没有特殊含义,它将按字面匹配,这可能不是您想要的。

示例

# 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

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

布尔值

当一个变量被认为采用布尔值时,会接受许多truefalse的同义词;这些都是不区分大小写的。

true

布尔值true文字为yesontrue1。此外,未定义= <value>的变量被视为true。

false

布尔值false文字为noofffalse0和空字符串。

使用--type=bool类型说明符将值转换为其规范形式时,git config将确保输出为“true”或“false”(以小写字母拼写)。

整数

许多指定各种大小的变量的值可以后缀kM等,表示“将数字乘以1024”、“乘以1024x1024”等。

颜色

采用颜色的变量的值是一个颜色列表(最多两个,一个用于前景色,一个用于背景色)和属性(任意多个),用空格分隔。

接受的基本颜色为normalblackredgreenyellowbluemagentacyanwhitedefault。第一个给定的颜色是前景色;第二个是背景色。除normaldefault之外的所有基本颜色都有一个亮变体,可以通过在颜色前添加bright来指定,例如brightred

颜色normal不会更改颜色。它与空字符串相同,但可以在仅指定背景色时用作前景色(例如,“normal red”)。

颜色default显式地将颜色重置为终端默认值,例如指定清除的背景。虽然终端之间有所不同,但这通常与设置为“white black”不同。

颜色也可以用0到255之间的数字表示;这些使用ANSI 256色模式(但请注意,并非所有终端都支持此模式)。如果您的终端支持,您还可以将24位RGB值指定为十六进制,例如#ff0ab3,或12位RGB值,例如#f1b,它等效于24位颜色#ff11bb

接受的属性为bolddimulblinkreverseitalicstrike(用于删除线或“删除线”字母)。任何属性相对于颜色的位置(之前、之后或之间)无关紧要。可以通过在属性前添加nono-来关闭特定属性(例如,noreverseno-ul等)。

伪属性reset在应用指定的着色之前重置所有颜色和属性。例如,reset green将导致绿色前景色和默认背景色,没有任何活动属性。

空颜色字符串根本不会产生任何颜色效果。这可以用来避免对特定元素进行着色,而不会完全禁用颜色。

对于git的预定义颜色槽,属性旨在在彩色输出的每个项目的开头重置。因此,将color.decorate.branch设置为black将以纯black绘制该分支名称,即使同一输出行上的前一个内容(例如,log --decorate输出中分支名称列表之前的左括号)设置为用bold或其他属性绘制也是如此。但是,自定义日志格式可能会执行更复杂的分层着色,并且否定形式在那里可能很有用。

路径名

采用路径名值的变量可以被赋予一个以“~/”或“~user/”开头的字符串,并且对这样的字符串执行通常的波浪号扩展:~/扩展为$HOME的值,~user/扩展为指定用户的家目录。

如果路径以%(prefix)/开头,则其余部分将被解释为相对于Git的“运行时前缀”的路径,即相对于Git本身安装的位置。例如,%(prefix)/bin/指的是Git可执行文件本身所在的目录。如果Git在没有运行时前缀支持的情况下编译,则将替换编译时内置的前缀。在不太可能需要指定不应扩展的文字路径的情况下,需要在其前面加上./,如下所示:./%(prefix)/bin

变量

请注意,此列表并非详尽无遗,也不一定是完整的。对于特定于命令的变量,您将在相应的联机帮助页中找到更详细的说明。

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

add.ignoreErrors
add.ignore-errors(已弃用)

告诉git add在某些文件由于索引错误而无法添加时继续添加文件。等效于git-add[1]--ignore-errors选项。add.ignore-errors已弃用,因为它不遵循配置变量的常用命名约定。

advice.*

这些变量控制各种可选帮助消息,这些消息旨在帮助新用户。当未配置时,Git 将在有关如何消除它的说明旁边提供该消息。您可以告诉Git您已经了解了问题,不再需要特定帮助消息,方法是将相应的变量设置为false

由于它们旨在帮助人类用户,因此这些消息会输出到标准错误。当作为子进程运行Git的工具发现这些消息具有干扰性时,它们可以在环境中设置GIT_ADVICE=0以消除所有建议消息。

addEmbeddedRepo

当用户意外地将一个git仓库添加到另一个仓库中时显示。

addEmptyPathspec

当用户在不提供pathspec参数的情况下运行git add时显示。

addIgnoredFile

当用户尝试将被忽略的文件添加到索引时显示。

amWorkDir

git-am[1]无法应用补丁文件时显示,以告诉用户该文件的位置。

ambiguousFetchRefspec

当多个远程的fetch refspec映射到同一个远程跟踪分支命名空间并导致分支跟踪设置失败时显示。

checkoutAmbiguousRemoteBranchName

git-checkout[1]git-switch[1] 的参数在多个远程仓库中都模糊地解析为一个远程跟踪分支时显示,在这种情况下,如果参数明确,则会检出一个远程跟踪分支。请参阅 checkout.defaultRemote 配置变量,了解如何在某些情况下设置一个指定的远程仓库作为默认使用,这些情况下会打印此建议。

commitBeforeMerge

git-merge[1] 拒绝合并以避免覆盖本地更改时显示。

detachedHead

当用户使用 git-switch[1]git-checkout[1] 切换到分离 HEAD 状态时显示,告诉用户如何事后创建本地分支。

diverging

当无法进行快进时显示。

fetchShowForcedUpdates

git-fetch[1] 在 ref 更新后花费很长时间计算强制更新时显示,或者警告检查被禁用。

forceDeleteBranch

当用户尝试删除一个未完全合并的分支且未设置强制选项时显示。

ignoredHook

当一个钩子被忽略,因为该钩子未设置为可执行文件时显示。

implicitIdentity

当用户的身份信息从系统用户名和域名猜测而来时显示,告诉用户如何设置其身份配置。

mergeConflict

当各种命令因冲突而停止时显示。

nestedTag

当用户尝试递归标记一个标签对象时显示。

pushAlreadyExists

git-push[1] 拒绝不符合快进更新的更新(例如,标签)时显示。

pushFetchFirst

git-push[1] 拒绝尝试覆盖指向我们没有的对象的远程 ref 的更新时显示。

pushNeedsForce

git-push[1] 拒绝尝试覆盖指向非提交对象的远程 ref 的更新,或使远程 ref 指向非提交对象时显示。

pushNonFFCurrent

git-push[1] 由于对当前分支的非快进更新而失败时显示。

pushNonFFMatching

当用户运行 git-push[1] 并显式推送“匹配的 ref”(即使用 : 或指定非当前分支的 refspec)导致非快进错误时显示。

pushRefNeedsUpdate

git-push[1] 拒绝分支的强制更新时显示,此时其远程跟踪 ref 有我们本地没有的更新。

pushUnqualifiedRefname

git-push[1] 放弃尝试根据源和目标 ref 猜测源属于哪个远程 ref 命名空间,但我们仍然可以根据源对象的类型建议用户推送到 refs/heads/*refs/tags/* 时显示。

pushUpdateRejected

如果要同时禁用 pushNonFFCurrentpushNonFFMatchingpushAlreadyExistspushFetchFirstpushNeedsForcepushRefNeedsUpdate,请将此变量设置为 false

rebaseTodoError

在编辑 rebase 待办事项列表后出现错误时显示。

refSyntax

当用户提供非法的 ref 名称时显示,告诉用户有关 ref 语法文档的信息。

resetNoRefresh

git-reset[1] 在重置后花费超过 2 秒刷新索引时显示,告诉用户可以使用 --no-refresh 选项。

resolveConflict

当各种命令因冲突而无法执行操作时显示。

rmHints

git-rm[1] 的输出失败时显示,提供有关如何从当前状态继续的说明。

sequencerInUse

当排序器命令已经在进行时显示。

skippedCherryPicks

git-rebase[1] 跳过一个已经 cherry-pick 到上游分支的提交时显示。

sparseIndexExpanded

当稀疏索引扩展到完整索引时显示,这可能是由于在稀疏检出之外存在意外的文件集导致的。

statusAheadBehind

git-status[1] 计算本地 ref 相对于其远程跟踪 ref 的前/后计数,并且计算时间超过预期时显示。如果 status.aheadBehind 为 false 或给出 --no-ahead-behind 选项,则不会出现。

statusHints

git-status[1] 的输出中显示有关如何从当前状态继续的说明,在 git-commit[1] 中编写提交消息时显示的模板中,以及在 git-switch[1]git-checkout[1] 切换分支时显示的帮助消息中。

statusUoption

git-status[1] 花费超过 2 秒枚举未跟踪文件时显示,告诉用户可以使用 -u 选项。

submoduleAlternateErrorStrategyDie

当配置为“die”的 submodule.alternateErrorStrategy 选项导致致命错误时显示。

submoduleMergeConflict

遇到非平凡的子模块合并冲突时显示的建议。

submodulesNotUpdated

当用户运行一个子模块命令失败,因为未运行 git submodule update --init 时显示。

suggestDetachingHead

git-switch[1] 拒绝在没有显式 --detach 选项的情况下分离 HEAD 时显示。

updateSparsePath

git-add[1]git-rm[1] 被要求更新当前稀疏检出之外的索引条目时显示。

waitingForEditor

当 Git 等待编辑器输入时显示。例如,当编辑器未在终端内启动时相关。

worktreeAddOrphan

当用户尝试从无效的引用创建工作树时显示,告诉用户如何创建新的未出生的分支。

alias.*

用于 git[1] 命令包装器的命令别名 - 例如,在定义 alias.last = cat-file commit HEAD 后,调用 git last 等效于 git cat-file commit HEAD。为了避免与脚本使用混淆和麻烦,隐藏现有 Git 命令的别名将被忽略。参数以空格分隔,支持常见的 shell 引号和转义。可以使用一对引号或反斜杠来引用它们。

请注意,别名的第一个词不一定必须是命令。它可以是一个命令行选项,该选项将传递到 git 的调用中。特别是,这在与 -c 一起使用时很有用,用于传递一次性配置,或与 -p 一起使用时强制分页。例如,可以定义 loud-rebase = -c commit.verbose=true rebase,以便运行 git loud-rebase 等效于 git -c commit.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 将为 mbox 格式的补丁调用 git-mailsplit,并使用参数 --keep-cr。在这种情况下,git-mailsplit 不会从以 \r\n 结尾的行中删除 \r。可以通过从命令行给出 --no-keep-cr 来覆盖。请参阅 git-am[1]git-mailsplit[1]

am.threeWay

默认情况下,如果补丁未干净地应用,则 git am 将失败。当设置为 true 时,此设置告诉 git am 如果补丁记录了它应该应用的 blob 的标识,并且我们本地有这些 blob 可用,则回退到 3 路合并(相当于从命令行给出 --3way 选项)。默认为 false。请参阅 git-am[1]

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命令行选项时,此配置变量无效。

注意
bitmapPseudoMerge.*中的配置选项被认为是实验性的,将来可能会发生更改或完全删除。有关伪合并位图功能的更多信息,请参阅gitpacking[7]的“伪合并位图”部分。
bitmapPseudoMerge.<name>.pattern

用于匹配引用名称的正则表达式。指向与该模式匹配的引用的提交(并满足以下条件,例如bitmapPseudoMerge.<name>.sampleRatebitmapPseudoMerge.<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

确定非位图提交(在引用提示中)中选择包含在不稳定伪合并位图中的比例。必须在01(含)之间。默认值为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

这决定了应用于归责输出的着色方案。它可以是repeatedLineshighlightRecentnone,后者是默认值。

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 branchgit switchgit checkout设置新分支,以便git-pull[1]将从起始点分支适当地合并。请注意,即使未设置此选项,也可以使用--track--no-track选项为每个分支选择此行为。有效设置包括:false — 不执行自动设置;true — 当起始点是远程跟踪分支时执行自动设置;always — 当起始点是本地分支或远程跟踪分支时执行自动设置;inherit — 如果起始点具有跟踪配置,则将其复制到新分支;simple — 仅当起始点是远程跟踪分支且新分支与远程分支具有相同的名称时执行自动设置。此选项默认为true。

branch.autoSetupRebase

当使用git branchgit switchgit checkout创建一个跟踪另一个分支的新分支时,此变量告诉Git将pull设置为rebase而不是merge(参见“branch.<name>.rebase”)。当为never时,rebase永远不会自动设置为true。当为local时,对于其他本地分支的跟踪分支,rebase将设置为true。当为remote时,对于远程跟踪分支的跟踪分支,rebase将设置为true。当为always时,对于所有跟踪分支,rebase都将设置为true。有关如何设置分支以跟踪另一个分支的详细信息,请参阅“branch.autoSetupMerge”。此选项默认为never。

branch.sort

此变量控制git-branch[1]显示分支时的排序顺序。如果没有提供“--sort=<value>”选项,则此变量的值将用作默认值。有关有效值,请参阅git-for-each-ref[1]字段名称。

branch.<name>.remote

在<name>分支上时,它告诉git fetchgit 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

如果为真,则将分支 <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--browse[1]。)

browser.<tool>.path

覆盖可能用于浏览 HTML 帮助(参见 git-help[1] 中的 -w 选项)或 gitweb 中的工作存储库(参见 git-instaweb[1])的给定工具的路径。

bundle.*

bundle.* 密钥可能出现在通过 git clone --bundle-uri 选项找到的 bundle 列表文件中。如果放在存储库配置文件中,这些密钥目前没有效果,尽管这将在将来发生变化。有关更多详细信息,请参阅 bundle URI 设计文档

bundle.version

此整数值宣传 bundle 列表使用的 bundle 列表格式的版本。目前,唯一接受的值是 1

bundle.mode

此字符串值应为 allany。此值描述是否需要所有已发布的 bundle 才能解包对 bundle 信息的完整理解(all),或者是否列出的任何一个 bundle URI 就足够了(any)。

bundle.heuristic

如果此字符串值密钥存在,则 bundle 列表旨在与增量 git fetch 命令配合使用。启发式表示每个 bundle 可用其他密钥来帮助确定客户端应下载的 bundle 子集。目前唯一理解的值是 creationToken

bundle.<id>.*

bundle.<id>.* 密钥用于描述 bundle 列表中的单个项目,在 <id> 下分组以进行识别。

bundle.<id>.uri

此字符串值定义 Git 可以通过其访问此 <id> 内容的 URI。此 URI 可以是 bundle 文件或其他 bundle 列表。

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 checkoutgit switch--guess--no-guess 选项的默认值。参见 git-switch[1]git-checkout[1]

checkout.workers

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

注意:对于位于 SSD 上或通过 NFS 的存储库,并行检出通常可以提供更好的性能。对于旋转磁盘上的存储库和/或核心数量少的机器,默认的顺序检出通常性能更好。存储库的大小和压缩级别也可能会影响并行版本执行的效果。

checkout.thresholdForParallelism

使用少量文件运行并行检出时,子进程生成和进程间通信的成本可能会超过并行化的收益。此设置允许您定义应尝试进行并行检出的文件的最小数量。默认为 100。

clean.requireForce

一个布尔值,使 git-clean 拒绝删除文件,除非给出 -f。默认为 true。

clone.defaultRemoteName

克隆存储库时要创建的远程的名称。默认为 origin。可以通过将 --origin 命令行选项传递给 git-clone[1] 来覆盖它。

clone.rejectShallow

如果存储库是浅存储库,则拒绝克隆它;这可以通过在命令行上传递 --reject-shallow 选项来覆盖。参见 git-clone[1]

clone.filterSubmodules

如果提供了部分克隆过滤器(参见 git-rev-list[1] 中的 --filter)并使用了 --recurse-submodules,则也将过滤器应用于子模块。

color.advice

一个布尔值,用于启用/禁用提示中的颜色(例如,当推送失败时,请参阅 advice.* 以获取列表)。可以设置为 alwaysfalse(或 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] 输出中的颜色。可以设置为 alwaysfalse(或 never)或 auto(或 true),在这种情况下,仅当输出到终端时才使用颜色。如果未设置,则使用 color.ui 的值(默认为 auto)。

color.branch.<slot>

为分支着色使用自定义颜色。<slot>current(当前分支)、local(本地分支)、remote(refs/remotes/ 中的远程跟踪分支)、upstream(上游跟踪分支)、plain(其他 refs)之一。

color.diff

是否使用 ANSI 转义序列向补丁添加颜色。如果将其设置为 always,则 git-diff[1]git-log[1]git-show[1] 将为所有补丁使用颜色。如果将其设置为 trueauto,则这些命令仅在输出到终端时才使用颜色。如果未设置,则使用 color.ui 的值(默认为 auto)。

这不会影响 git-format-patch[1]git-diff-* 管道命令。可以使用 --color[=<when>] 选项在命令行中覆盖它。

color.diff.<slot>

为 diff 着色使用自定义颜色。<slot> 指定要使用指定颜色的补丁的哪个部分,并且是 context(上下文文本 - plain 是历史同义词)、meta(元信息)、frag(块标题)、func(块标题中的函数)、old(删除的行)、new(添加的行)、commit(提交标题)、whitespace(突出显示空格错误)、oldMoved(删除的行)、newMoved(添加的行)、oldMovedDimmedoldMovedAlternativeoldMovedAlternativeDimmednewMovedDimmednewMovedAlternative newMovedAlternativeDimmed(有关详细信息,请参阅 git-diff[1]--color-moved<mode> 设置)、contextDimmedoldDimmednewDimmedcontextBoldoldBoldnewBold(有关详细信息,请参阅 git-range-diff[1])之一。

color.decorate.<slot>

git log --decorate 输出使用自定义颜色。<slot> 分别是 branchremoteBranchtagstashHEAD,用于本地分支、远程跟踪分支、标签、存储和 HEAD,以及 grafted 用于嫁接的提交。

color.grep

当设置为always时,始终突出显示匹配项。当设置为false(或never)时,永不突出显示。当设置为trueauto时,仅在输出写入终端时才使用颜色。如果未设置,则使用color.ui的值(默认值为auto)。

color.grep.<slot>

使用自定义颜色进行 grep 着色。<slot> 指定要使用指定颜色的行的哪个部分,并且是以下之一:

context

上下文行中的不匹配文本(当使用-A-B-C时)

filename

文件名前缀(不使用-h时)

function

函数名称行(当使用-p时)

lineNumber

行号前缀(当使用-n时)

column

列号前缀(当使用--column时)

match

匹配文本(与设置matchContextmatchSelected相同)

matchContext

上下文行中的匹配文本

matchSelected

选定行中的匹配文本。此外,还用于自定义以下git-log[1]子命令:--grep--author--committer

selected

选定行中的不匹配文本。此外,还用于自定义以下git-log[1]子命令:--grep--author--committer

separator

行上字段之间的分隔符(:-=)以及块之间的分隔符(--

color.interactive

当设置为always时,始终为交互式提示和显示使用颜色(例如“git-add --interactive”和“git-clean --interactive”使用的提示和显示)。当设置为false(或never)时,永不使用颜色。当设置为trueauto时,仅在输出到终端时才使用颜色。如果未设置,则使用color.ui的值(默认值为auto)。

color.interactive.<slot>

git add --interactivegit clean --interactive输出使用自定义颜色。<slot>可以是promptheaderhelperror,用于交互式命令的四种不同类型的普通输出。

color.pager

一个布尔值,用于指定auto颜色模式是否应为发送到分页器的输出着色。默认为true;如果您的分页器不理解ANSI颜色代码,请将其设置为false。

color.push

一个布尔值,用于启用/禁用推送错误中的颜色。可以设置为alwaysfalse(或never)或auto(或true),在这种情况下,仅当错误输出发送到终端时才使用颜色。如果未设置,则使用color.ui的值(默认值为auto)。

color.push.error

为推送错误使用自定义颜色。

color.remote

如果设置,则突出显示行开头的关键字。关键字为“error”、“warning”、“hint”和“success”,并且不区分大小写进行匹配。可以设置为alwaysfalse(或never)或auto(或true)。如果未设置,则使用color.ui的值(默认值为auto)。

color.remote.<slot>

为每个远程关键字使用自定义颜色。<slot>可以是hintwarningsuccesserror,它们与相应的关键字匹配。

color.showBranch

一个布尔值,用于启用/禁用git-show-branch[1]输出中的颜色。可以设置为alwaysfalse(或never)或auto(或true),在这种情况下,仅当输出到终端时才使用颜色。如果未设置,则使用color.ui的值(默认值为auto)。

color.status

一个布尔值,用于启用/禁用git-status[1]输出中的颜色。可以设置为alwaysfalse(或never)或auto(或true),在这种情况下,仅当输出到终端时才使用颜色。如果未设置,则使用color.ui的值(默认值为auto)。

color.status.<slot>

使用自定义颜色进行状态着色。<slot>可以是header(状态消息的标题文本)、addedupdated(已添加但未提交的文件)、changed(已更改但未添加到索引中的文件)、untracked(Git 未跟踪的文件)、branch(当前分支)、nobranch(显示“no branch”警告的颜色,默认为红色)、localBranchremoteBranch(分别为本地和远程分支名称,当在状态简短格式中显示分支和跟踪信息时)或unmerged(具有未合并更改的文件)。

color.transport

一个布尔值,用于启用/禁用推送被拒绝时的颜色。可以设置为alwaysfalse(或never)或auto(或true),在这种情况下,仅当错误输出发送到终端时才使用颜色。如果未设置,则使用color.ui的值(默认值为auto)。

color.transport.rejected

推送被拒绝时使用自定义颜色。

color.ui

此变量确定诸如color.diffcolor.grep等变量的默认值,这些变量控制每个命令族的颜色使用情况。随着更多命令学习配置以设置--color选项的默认值,其作用域将扩大。如果希望 Git 命令在未通过其他配置或--color选项明确启用时不使用颜色,请将其设置为falsenever。如果希望所有不打算供机器使用的输出都使用颜色,请将其设置为always;如果希望此类输出在写入终端时使用颜色,请将其设置为trueauto(这是 Git 1.8.4 之后的默认值)。

column.ui

指定支持的命令是否应以列的形式输出。此变量由以空格或逗号分隔的标记列表组成

这些选项控制何时应启用该功能(默认为never

always

始终以列显示

never

永不以列显示

auto

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

这些选项控制布局(默认为column)。如果未指定alwaysneverauto中的任何一个,则设置这些选项中的任何一个都意味着always

column

先填充列,再填充行

row

先填充行,再填充列

plain

在一列中显示

最后,这些选项可以与布局选项结合使用(默认为nodense

dense

使大小不等的列以利用更多空间

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

commit.cleanup

此设置会覆盖git commit--cleanup选项的默认值。有关详细信息,请参阅git-commit[1]。当您始终希望在日志消息中保留以注释字符#开头的行时,更改默认值会很有用,在这种情况下,您将执行git config commit.cleanup whitespace(请注意,如果您这样做,则必须自己删除提交日志模板中以#开头的帮助行)。

commit.gpgSign

一个布尔值,用于指定是否应对所有提交进行GPG签名。在执行诸如rebase之类的操作时使用此选项可能会导致大量提交被签名。使用代理来避免多次输入您的GPG密码可能会很方便。

commit.status

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

commit.template

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

commit.verbose

一个布尔值或整数,用于指定git commit的详细程度。请参阅git-commit[1]

commitGraph.generationVersion

指定在写入或读取commit-graph文件时要使用的生成号版本类型。如果指定版本1,则不会写入或读取已更正的提交日期。默认为2。

commitGraph.maxNewFilters

指定git commit-graph write--max-new-filters选项的默认值(参见git-commit-graph[1])。

commitGraph.readChangedPaths

已弃用。如果为真,则等效于commitGraph.changedPathsVersion=-1,如果为假,则等效于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用于向已完成命令列表中添加或删除命令。通常,只有瓷器命令和一些其他选定的命令会被完成。您可以在此变量中添加更多命令,命令之间用空格分隔。在命令前加上-将从现有列表中删除它。

core.fileMode

告诉Git是否要遵守工作树中文件的可执行位。

某些文件系统在检出标记为可执行的文件时会丢失可执行位,或者检出具有可执行位的不可执行文件。 git-clone[1]git-init[1]探测文件系统以查看它是否正确处理了可执行位,并且此变量会根据需要自动设置。

但是,存储库可能位于正确处理文件模式的文件系统上,并且在创建时此变量设置为true,但随后可能从另一个丢失文件模式的环境访问它(例如,通过CIFS挂载导出ext4,使用Git for Windows或Eclipse访问Cygwin创建的存储库)。在这种情况下,可能需要将此变量设置为false。参见git-update-index[1]

默认为true(当配置文件中未指定core.filemode时)。

core.hideDotFiles

(仅限Windows) 如果为真,则将名称以点开头的最新创建的目录和文件标记为隐藏。如果为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

此选项仅由Mac OS实现的Git使用。当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--daemon[1])。

与基于钩子的文件系统监视器类似,内置文件系统监视器可以加快需要刷新Git索引的Git命令的速度(例如,在具有许多文件的目录中使用git status)。内置监视器无需安装和维护外部第三方工具。

内置文件系统监视器目前仅在有限的一组受支持平台上可用。目前,包括Windows和MacOS。

Otherwise, this variable contains the pathname of the "fsmonitor"
hook command.

此钩子命令用于识别自请求日期/时间以来可能已更改的所有文件。此信息用于通过避免不必要地扫描未更改的文件来加快Git的速度。

请参阅githooks[5]的“fsmonitor-watchman”部分。

请注意,如果您同时使用多个版本的Git,例如在命令行上使用一个版本,在IDE工具中使用另一个版本,则core.fsmonitor的定义已扩展为允许布尔值以及钩子路径名。Git版本2.35.1及更早版本将不理解布尔值,并将“true”或“false”值视为要调用的钩子路径名。Git版本2.26到2.35.1默认为钩子协议V2,并且将回退到无fsmonitor(完全扫描)。Git版本2.26之前的版本默认为钩子协议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-filesdiff)将通过将路径名括在双引号中并将这些字符用反斜杠转义来引用路径名中的“不寻常”字符,其方式与C转义控制字符(例如\t用于TAB,\n用于LF,\\用于反斜杠)或值大于0x80的字节(例如UTF-8中的“micro”的八进制\302\265)相同。如果此变量设置为false,则大于0x80的字节不再被视为“不寻常”。双引号、反斜杠和控制字符始终会被转义,而不管此变量的设置如何。简单的空格字符不被视为“不寻常”。许多命令可以使用-z选项完全逐字输出路径名。默认值为true。

core.eol

设置工作目录中标记为文本的文件(通过设置text属性或通过设置text=auto并由Git自动检测内容为文本)要使用的行结束类型。备选方案为lfcrlfnative,后者使用平台的本机行结束符。默认值为native。有关行结束符转换的更多信息,请参见gitattributes[5]。请注意,如果core.autocrlf设置为trueinput,则忽略此值。

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.eolcore.autocrlf 的设置不同,也仅适用于当前设置。例如,包含 LF 的文本文件在 core.eol=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 属性中使用(参见 gitattributes[5]),Git 将对其执行 UTF-8 往返检查。默认值为 SHIFT-JIS

如果为 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 fetchgit push 在需要连接到远程系统时将使用指定的命令而不是 ssh。该命令的格式与 GIT_SSH_COMMAND 环境变量相同,并且在设置环境变量时会被覆盖。

core.ignoreStat

如果为 true,Git 将避免使用 lstat() 调用来检测文件是否已更改,方法是为那些在索引和工作树中都以相同方式更新的已跟踪文件设置“assume-unchanged”位。

当文件在 Git 之外修改时,用户需要显式地暂存已修改的文件(例如,参见 git-update-index[1] 中的“示例”部分)。Git 通常不会检测到这些文件的更改。

这在 lstat() 调用非常慢的系统(如 CIFS/Microsoft Windows)上很有用。

默认情况下为 false。

core.preferSymlinkRefs

使用符号链接代替 HEAD 和其他符号引用文件的默认“symref”格式。有时需要与期望 HEAD 为符号链接的旧脚本一起使用。

core.alternateRefsCommand

在从备用存储库发布可用历史记录的提示时,使用 shell 执行指定的命令,而不是 git-for-each-ref[1]。第一个参数是备用存储库的绝对路径。输出必须包含每行一个十六进制对象 ID(即,与 git for-each-ref --format='%(objectname)' 生成的相同)。

请注意,您通常不能将 git for-each-ref 直接放入配置值中,因为它不接受存储库路径作为参数(但您可以将上述命令包装在 shell 脚本中)。

core.alternateRefsPrefixes

在列出备用存储库中的引用时,仅列出以给定前缀开头的引用。前缀的匹配方式如同将其作为参数传递给 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”结尾的存储库被假定为非裸存储库(裸存储库 = false),而所有其他存储库被假定为裸存储库(裸存储库 = 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.logAllRefUpdates

启用 reflog。对 ref <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

用于标识存储库格式和布局版本的内部变量。

core.sharedRepository

当为 group(或 true)时,存储库将对组中的多个用户共享(确保所有文件和对象都是组可写的)。当为 all(或 worldeverybody)时,存储库将可供所有用户读取,此外还可以与组共享。当为 umask(或 false)时,Git 将使用 umask(2) 报告的权限。当为 0xxx 时,其中 0xxx 是一个八进制数,存储库中的文件将具有此模式值。0xxx 将覆盖用户的 umask 值(而其他选项只会覆盖用户 umask 值的请求部分)。例如:0660 将使存储库对所有者和组可读/可写,但对其他人不可访问(等效于 group,除非 umask 为例如 0022)。0640 是一个组可读但不可组写的存储库。参见 git-init[1]。默认情况下为 false。

core.warnAmbiguousRefs

如果为 true,Git 将在您传递的 ref 名称不明确并且可能与存储库中的多个 ref 匹配时发出警告。默认为 true。

core.compression

一个整数 -1..9,表示默认压缩级别。-1 是 zlib 的默认值。0 表示不压缩,1..9 是各种速度/大小权衡,9 最慢。如果设置,则为其他压缩变量(如 core.looseCompressionpack.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。这对于所有用户/操作系统来说都是合理的。您可能不需要调整此值。

支持常见的单位后缀 kmg

core.packedGitLimit

从打包文件中同时映射到内存中的最大字节数。如果 Git 需要一次访问超过这么多字节才能完成操作,它将取消映射现有区域以在进程中回收虚拟地址空间。

在 32 位平台上默认为 256 MiB,在 64 位平台上默认为 32 TiB(实际上是无限的)。这对于所有用户/操作系统来说都是合理的,除了最大的项目。您可能不需要调整此值。

支持常见的单位后缀 kmg

core.deltaBaseCacheLimit

每个线程为缓存可能被多个增量对象引用的基本对象保留的最大字节数。通过将整个解压缩的基本对象存储在缓存中,Git 能够避免多次解压缩和解压缩常用基本对象。

在所有平台上默认为 96 MiB。这对于所有用户/操作系统来说都是合理的,除了最大的项目。您可能不需要调整此值。

支持常见的单位后缀 kmg

core.bigFileThreshold

被认为是“大”文件的尺寸,如下所述,它会改变许多 git 命令的行为,以及这些文件在存储库中的存储方式。默认为 512 MiB。支持常见的单位后缀 kmg

大于配置限制的文件将

  • 存储在打包文件中,并且不尝试进行增量压缩。

    默认限制主要是在考虑此用例的情况下设置的。有了它,大多数项目的源代码和其他文本文件将进行增量压缩,但较大的二进制媒体文件不会。

    在不进行增量压缩的情况下存储大文件可以避免过度使用内存,但会稍微增加磁盘使用量。

  • 将被视为已标记为“二进制”(请参阅 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(每个目录)和 .git/info/attributes 之外,Git 还查看此文件以获取属性(请参阅 gitattributes[5])。路径扩展的方式与 core.excludesFile 相同。其默认值为 $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] 的“DESCRIPTION”部分)。

此配置变量在您希望集中配置 Git 钩子而不是在每个存储库中配置它们,或者作为对具有已更改默认钩子的 init.templateDir 的更灵活和集中的替代方案时很有用。

core.editor

诸如 committag 之类的命令允许您通过启动编辑器来编辑消息,当设置此变量且未设置环境变量 GIT_EDITOR 时,它们会使用此变量的值。请参阅 git-var[1]

core.commentChar
core.commentString

诸如 committag 之类的命令允许您编辑消息,它们会将以该字符开头的行视为注释,并在编辑器返回后将其删除(默认为 #)。

如果设置为“auto”,则 git-commit 将选择一个字符,该字符不是现有提交消息中任何行的开头字符。

请注意,这两个变量是彼此的别名,在 Git 的现代版本中,您可以自由地使用字符串(例如,//⁑⁕⁑)与 commentChar 一起使用。Git v2.45.0 之前的版本将忽略 commentString,但会拒绝一个值 commentChar,该值包含多个 ASCII 字节。如果您计划将您的配置与旧版和新版 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(即重试 100 毫秒)。

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,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-eolblank-at-eof

  • cr-at-eol 将行尾的回车符视为行终止符的一部分,即,使用它时,如果此类回车符之前的字符不是空格,则 trailing-space 不会触发(默认未启用)。

  • tabwidth=<n> 指示一个制表符占据多少个字符位置;这与 indent-with-non-tab 以及 Git 修复 tab-in-indent 错误时相关。默认制表符宽度为 8。允许的值为 1 到 63。

core.fsync

在创建或修改存储库时,应通过 core.fsyncMethod 加固的存储库组件的逗号分隔列表。您可以通过在组件前添加-来禁用任何组件的加固。在系统非正常关闭的情况下,未加固的项目可能会丢失。除非您有特殊要求,否则建议您将此选项留空或选择committedaddedall之一。

当遇到此配置时,组件集将以平台默认值开头,删除禁用的组件,并添加其他组件。none重置状态,使平台默认值失效。

空字符串将 fsync 配置重置为平台默认值。大多数平台上的默认值等效于core.fsync=committed,-loose-object,这具有良好的性能,但在系统非正常关闭的情况下,可能会丢失最近的工作。

  • none清除已同步组件的集合。

  • 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启用一种模式,该模式使用 writeout-only 刷新将磁盘回写缓存中的多个更新分阶段处理,然后对一个虚拟文件执行一次完整的 fsync 以在操作结束时触发磁盘缓存刷新。

    目前,batch模式仅适用于松散对象文件。其他存储库数据将像指定了fsync一样变得持久。在 macOS 上用于存储在 HFS+ 或 APFS 文件系统上的存储库以及在 Windows 上用于存储在 NTFS 或 ReFS 文件系统上的存储库时,此模式预计与fsync一样安全。

core.fsyncObjectFiles

此布尔值将在写入对象文件时启用fsync()。此设置已弃用。请使用 core.fsync 代替。

此设置影响以松散对象形式添加到 Git 存储库中的数据。当设置为 true 时,Git 将发出 fsync 或类似的系统调用来刷新缓存,以便在系统非正常关闭时松散对象保持一致。

core.preloadIndex

git diff等操作启用并行索引预加载

这可以加快git diffgit status等操作的速度,尤其是在 NFS 等缓存语义较弱且因此 IO 延迟相对较高的文件系统上。启用后,Git 将并行执行索引与文件系统数据的比较,从而允许重叠 IO。默认为 true。

core.unsetenvvars

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

core.restrictinheritedhandles

仅限 Windows:覆盖生成的进程是否仅继承标准文件句柄(stdinstdoutstderr)或所有句柄。可以是autotruefalse。默认为auto,这意味着在 Windows 7 及更高版本上为true,在较旧的 Windows 版本上为false

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

使用多包索引文件使用单个索引跟踪多个包文件。有关更多信息,请参阅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.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与工作树文件进行比较时,不要将仅状态更改视为已更改。而是静默运行git update-index --refresh以更新工作树中内容与索引中内容匹配的路径的缓存状态信息。此选项默认为 true。请注意,这仅影响git diff Porcelain,而不影响较低级别的diff命令,例如git diff-files

diff.dirstat

一个用逗号分隔的--dirstat参数列表,用于指定--dirstat选项对git-diff[1]及其相关命令的默认行为。这些默认值可以在命令行中被覆盖(使用--dirstat=<param1,param2,...>)。回退默认值(当未被diff.dirstat修改时)为changes,noncumulative,3。以下参数可用:

changes

通过计算从源代码中删除的行数或添加到目标中的行数来计算dirstat数值。这忽略了文件中纯代码移动的数量。换句话说,文件中的行重新排列不会像其他更改那样被计入。当没有给出参数时,这是默认行为。

lines

通过执行常规的基于行的diff分析并对删除/添加的行数求和来计算dirstat数值。(对于二进制文件,请改为计算64字节的块,因为二进制文件没有自然的行概念)。这比changes行为更昂贵的--dirstat行为,但它确实将文件中重新排列的行与其他更改一样多地计入。结果输出与您从其他--*stat选项获得的结果一致。

files

通过计算更改的文件数来计算dirstat数值。每个更改的文件在dirstat分析中都同等重要。这是计算成本最低的--dirstat行为,因为它根本不需要查看文件内容。

cumulative

将子目录中的更改也计入父目录。请注意,当使用cumulative时,报告的百分比总和可能会超过100%。默认(非累积)行为可以使用noncumulative参数指定。

<limit>

一个整数参数指定一个截止百分比(默认为3%)。贡献少于此百分比更改的目录不会显示在输出中。

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

diff.statNameWidth

限制--stat输出中文件名部分的宽度。如果设置,则应用于所有生成--stat输出的命令,除了format-patch。

diff.statGraphWidth

限制--stat输出中图形部分的宽度。如果设置,则应用于所有生成--stat输出的命令,除了format-patch。

diff.context

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

diff.interHunkContext

显示diff块之间的上下文,最多指定行数,从而融合彼此靠近的块。此值用作--inter-hunk-context命令行选项的默认值。

diff.external

如果设置了此配置变量,则diff生成不会使用内部diff机制,而是使用给定的命令。可以通过‘GIT_EXTERNAL_DIFF’环境变量覆盖。该命令的参数调用方式如git[1]中“git Diffs”部分所述。注意:如果您只想对部分文件使用外部diff程序,则可能需要改为使用gitattributes[5]

diff.trustExitCode

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

diff.ignoreSubmodules

设置--ignore-submodules的默认值。请注意,这仅影响git diff Porcelain,而不影响较低级别的diff命令,如git diff-filesgit checkoutgit switch在报告未提交的更改时也会遵循此设置。将其设置为all将禁用git commitgit statusstatus.submoduleSummary设置时通常显示的子模块摘要,除非使用--ignore-submodules命令行选项覆盖它。git submodule命令不受此设置影响。默认情况下,此设置为untracked,以便忽略任何未跟踪的子模块。

diff.mnemonicPrefix

如果设置,git diff将使用与标准“a/”和“b/”不同的前缀对,具体取决于比较的内容。当此配置生效时,反向diff输出也会交换前缀的顺序。

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事物(1)和(2)。

diff.noPrefix

如果设置,git diff不会显示任何源或目标前缀。

diff.srcPrefix

如果设置,git diff将使用此源前缀。默认为“a/”。

diff.dstPrefix

如果设置,git diff将使用此目标前缀。默认为“b/”。

diff.relative

如果设置为truegit diff不会显示目录之外的更改,并显示相对于当前目录的路径名。

diff.orderFile

指示如何在diff中排序文件的文件。有关详细信息,请参阅git-diff[1]-O选项。如果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”格式显示子模块更改内容的内联diff。默认为“short”。

diff.wordRegex

一个POSIX扩展正则表达式,用于在执行逐词差异计算时确定什么是“词”。与正则表达式匹配的字符序列是“词”,所有其他字符都是可忽略的空格。

diff.<driver>.command

自定义diff驱动程序命令。有关详细信息,请参阅gitattributes[5]

diff.<driver>.trustExitCode

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

diff.<driver>.xfuncname

diff驱动程序应用于识别块头的正则表达式。也可以使用内置模式。有关详细信息,请参阅gitattributes[5]

diff.<driver>.binary

将此选项设置为true,以使diff驱动程序将文件视为二进制文件。有关详细信息,请参阅gitattributes[5]

diff.<driver>.textconv

diff驱动程序应调用的命令,用于生成文件的文本转换版本。转换结果用于生成人类可读的diff。有关详细信息,请参阅gitattributes[5]

diff.<driver>.wordRegex

diff驱动程序应用于拆分行中单词的正则表达式。有关详细信息,请参阅gitattributes[5]

diff.<driver>.cachetextconv

将此选项设置为true,以使diff驱动程序缓存文本转换输出。有关详细信息,请参阅gitattributes[5]

  • araxis

  • bc

  • codecompare

  • deltawalker

  • diffmerge

  • diffuse

  • ecmerge

  • emerge

  • examdiff

  • guiffy

  • gvimdiff

  • kdiff3

  • kompare

  • meld

  • nvimdiff

  • opendiff

  • p4merge

  • smerge

  • tkdiff

  • vimdiff

  • vscode

  • winmerge

  • xxdiff

diff.indentHeuristic

将此选项设置为false以禁用默认启发式算法,该算法会移动 diff 片段边界以使补丁更易于阅读。

diff.algorithm

选择一个 diff 算法。变体如下所示

default, myers

基本的贪婪 diff 算法。目前,这是默认值。

minimal

花费额外的时间以确保生成尽可能小的 diff。

patience

在生成补丁时使用“耐心 diff”算法。

histogram

此算法扩展了耐心算法以“支持低出现率的公共元素”。

diff.wsErrorHighlight

突出显示 diff 中contextoldnew行的空白错误。多个值用逗号分隔,none重置先前值,default将列表重置为new,而allold,new,context的简写。空白错误用color.diff.whitespace着色。命令行选项--ws-error-highlight=<kind>会覆盖此设置。

diff.colorMoved

如果设置为有效<mode>或真值,则 diff 中移动的行将以不同的颜色显示,有关有效模式的详细信息,请参阅git-diff[1]中的--color-moved。如果仅设置为 true,则将使用默认颜色模式。设置为 false 时,移动的行不会着色。

diff.colorMovedWS

当使用例如diff.colorMoved设置对移动的行进行着色时,此选项控制如何处理空格的<mode>。有关有效模式的详细信息,请参阅git-diff[1]中的--color-moved-ws

diff.tool

控制git-difftool[1]使用的 diff 工具。此变量会覆盖在merge.tool中配置的值。以下列表显示了有效的内置值。任何其他值都被视为自定义 diff 工具,并且需要定义相应的difftool.<tool>.cmd变量。

diff.guitool

当指定-g/--gui标志时,控制git-difftool[1]使用的 diff 工具。此变量会覆盖在merge.guitool中配置的值。以下列表显示了有效的内置值。任何其他值都被视为自定义 diff 工具,并且需要定义相应的difftool.<guitool>.cmd变量。

difftool.<tool>.cmd

指定用于调用指定 diff 工具的命令。指定的命令在 shell 中执行,并提供以下变量:LOCAL设置为包含 diff 前映像内容的临时文件的名称,REMOTE设置为包含 diff 后映像内容的临时文件的名称。

有关更多详细信息,请参阅git-difftool[1]中的--tool=<tool>选项。

difftool.<tool>.path

覆盖给定工具的路径。如果您的工具不在 PATH 中,这将很有用。

difftool.trustExitCode

如果调用的 diff 工具返回非零退出状态,则退出 difftool。

有关更多详细信息,请参阅git-difftool[1]中的--trust-exit-code选项。

difftool.prompt

在每次调用 diff 工具之前提示。

difftool.guiDefault

设置为true以默认使用diff.guitool(相当于指定--gui参数),或设置为auto以根据DISPLAY环境变量值的存在选择diff.guitooldiff.tool。默认为false,其中必须明确提供--gui参数才能使用diff.guitool

extensions.objectFormat

指定要使用的哈希算法。可接受的值为sha1sha256。如果未指定,则假定为sha1。除非core.repositoryFormatVersion为 1,否则指定此键是错误的。

请注意,此设置只能由git-init[1]git-clone[1]设置。初始化后尝试更改它将不起作用,并会导致难以诊断的问题。

extensions.compatObjectFormat

指定要使用的兼容性哈希算法。可接受的值为sha1sha256。指定的值必须不同于extensions.objectFormat的值。这允许在objectFormat与该compatObjectFormat匹配的git存储库之间进行客户端级别的互操作性。特别是当完全实现时,来自objectFormat与compatObjectFormat匹配的存储库的推送和拉取。以及能够使用compatObjectFormat中编码的oids以及使用objectFormat编码的oids来本地指定对象。

extensions.refStorage

指定要使用的 ref 存储格式。可接受的值为

  • 对于带有packed-refs的松散文件,使用files。这是默认值。

  • 对于reftable格式,使用reftable。此格式是实验性的,其内部结构可能会发生变化。

除非core.repositoryFormatVersion为 1,否则指定此键是错误的。

+ 请注意,此设置只能由git-init[1]git-clone[1]设置。初始化后尝试更改它将不起作用,并会导致难以诊断的问题。

extensions.worktreeConfig

如果启用,则工作树除了加载$GIT_COMMON_DIR/config文件之外,还会加载$GIT_DIR/config.worktree文件中的配置设置。请注意,对于主工作树,$GIT_COMMON_DIR$GIT_DIR相同,而其他工作树的$GIT_DIR等于$GIT_COMMON_DIR/worktrees/<id>/config.worktree文件中的设置将覆盖任何其他配置文件中的设置。

启用extensions.worktreeConfig时,必须小心地将某些值从公共配置文件移动到主工作树的config.worktree文件(如果存在)。

  • core.worktree必须从$GIT_COMMON_DIR/config移动到$GIT_COMMON_DIR/config.worktree

  • 如果core.bare为 true,则必须将其从$GIT_COMMON_DIR/config移动到$GIT_COMMON_DIR/config.worktree

    根据您对每个工作树的自定义稀疏检出设置的期望,调整core.sparseCheckoutcore.sparseCheckoutCone的位置也可能是有益的。默认情况下,git sparse-checkout内置函数启用extensions.worktreeConfig,在每个工作树的基础上分配这些配置值,并使用$GIT_DIR/info/sparse-checkout文件独立地为每个工作树指定稀疏性。有关更多详细信息,请参阅git-sparse-checkout[1]

    出于历史原因,无论core.repositoryFormatVersion设置如何,都会尊重extensions.worktreeConfig

fastimport.unpackLimit

如果git-fast-import[1]导入的对象数量低于此限制,则这些对象将解压到松散的对象文件中。但是,如果导入的对象数量等于或超过此限制,则包将存储为包。从快速导入存储包可以使导入操作更快地完成,尤其是在速度较慢的文件系统上。如果未设置,则使用transfer.unpackLimit的值。

feature.*

feature.开头的配置设置会修改一组其他配置设置的默认值。这些组由 Git 开发者社区创建作为推荐的默认值,并且可能会发生变化。特别是,可能会添加新的配置选项,并具有不同的默认值。

feature.experimental

启用 Git 中的新配置选项,并且正在考虑将其作为未来的默认值。此处包含的配置设置可能会在每个版本(包括次要版本更新)中添加或删除。由于这些设置非常新,因此它们可能存在意外的交互。如果您有兴趣提供有关实验性功能的反馈,请启用此设置。新的默认值为

  • fetch.negotiationAlgorithm=skipping可以通过一次跳过更多提交来提高获取协商时间,从而减少往返次数。

  • pack.useBitmapBoundaryTraversal=true可以通过遍历较少的对象来提高位图遍历时间。

  • pack.allowPackReuse=multi可以通过重用多个包中的对象而不是仅重用一个包来缩短创建包所需的时间。

feature.manyFiles

启用针对工作目录中包含许多文件的存储库进行优化的配置选项。对于许多文件,诸如git statusgit checkout之类的命令可能会很慢,这些新的默认值可以提高性能

  • index.skipHash=true通过不计算尾随校验和来加快索引写入速度。请注意,这会导致早于 2.13.0 的 Git 版本拒绝解析索引,并且早于 2.40.0 的 Git 版本会在git fsck期间报告索引损坏。

  • index.version=4在索引中启用路径前缀压缩。

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

fetch.recurseSubmodules

此选项控制git fetch(以及git pull中的底层获取)是否会递归地获取到填充的子模块中。此选项可以设置为布尔值或on-demand。将其设置为布尔值会更改 fetch 和 pull 的行为,以便在设置为 true 时无条件地递归到子模块中,或者在设置为 false 时根本不递归。设置为on-demand时,fetch 和 pull 仅在超级项目检索更新子模块引用的提交时才会递归到填充的子模块中。默认为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 原生传输获取的对象数量低于此限制,则这些对象将解压到松散的对象文件中。但是,如果接收到的对象数量等于或超过此限制,则接收到的包将在添加任何缺失的 delta 基数后存储为包。从推送中存储包可以使推送操作更快完成,尤其是在文件系统速度较慢的情况下。如果未设置,则使用 transfer.unpackLimit 的值。

fetch.prune

如果为真,则 fetch 将自动表现得好像在命令行上给出了 --prune 选项。另请参阅 remote.<name>.prunegit-fetch[1] 的 PRUNING 部分。

fetch.pruneTags

如果为真,则 fetch 将自动表现得好像在修剪时提供了 refs/tags/*:refs/tags/* refspec(如果尚未设置)。这允许同时设置此选项和 fetch.prune 以维护与上游 ref 的 1=1 映射。另请参阅 remote.<name>.pruneTagsgit-fetch[1] 的 PRUNING 部分。

fetch.all

如果为真,则 fetch 将尝试更新所有可用的远程仓库。可以通过传递 --no-all 或显式指定要从中获取的一个或多个远程仓库来覆盖此行为。默认为 false。

fetch.output

控制如何打印 ref 更新状态。有效值为 fullcompact。默认值为 full。有关详细信息,请参阅 git-fetch[1] 中的 OUTPUT 部分。

fetch.negotiationAlgorithm

控制在协商服务器要发送的包文件内容时如何发送本地存储库中提交的信息。设置为 "consecutive" 以使用一种算法,该算法遍历连续的提交并检查每一个提交。设置为 "skipping" 以使用一种算法,该算法跳过提交以加快收敛速度,但可能导致包文件比必要的大;或者设置为 "noop" 以根本不发送任何信息,这几乎肯定会导致包文件比必要的大,但会跳过协商步骤。设置为 "default" 以覆盖之前做出的设置并使用默认行为。默认值通常为 "consecutive",但如果 feature.experimental 为 true,则默认值为 "skipping"。未知值会导致 git fetch 发生错误。

另请参阅 git-fetch[1]--negotiate-only--negotiation-tip 选项。

fetch.showForcedUpdates

设置为 false 以在 git-fetch[1]git-pull[1] 命令中启用 --no-show-forced-updates。默认为 true。

fetch.parallel

指定同时并行运行的最大 fetch 操作数(子模块,或在 git-fetch[1]--multiple 选项生效时使用的远程仓库)。

值为 0 将提供一些合理的默认值。如果未设置,则默认为 1。

对于子模块,可以使用 submodule.fetchJobs 配置设置覆盖此设置。

fetch.writeCommitGraph

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

fetch.bundleURI

此值存储一个 URI,用于在从原始 Git 服务器执行增量获取之前从捆绑包 URI 下载 Git 对象数据。这类似于 git-clone[1]--bundle-uri 选项的行为。如果提供的捆绑包 URI 包含为增量获取组织的捆绑包列表,则 git clone --bundle-uri 将设置 fetch.bundleURI 值。

如果修改此值并且存储库具有 fetch.bundleCreationToken 值,则在从新的捆绑包 URI 获取之前删除该 fetch.bundleCreationToken 值。

fetch.bundleCreationToken

当使用 fetch.bundleURI 从使用“creationToken”启发式的捆绑包列表增量获取时,此配置值存储已下载捆绑包的最大 creationToken 值。如果广告的 creationToken 不严格大于此值,则此值用于将来防止下载捆绑包。

creation token 值由提供特定捆绑包 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

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

format.forceInBodyFrom

提供 --[no-]force-in-body-from 选项到 format-patch 的默认值。默认为 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

使用“Q-编码”(RFC 2047 中描述)对具有非 ASCII 字符的电子邮件标头进行编码以进行电子邮件传输。默认为 true。

format.pretty

log/show/whatchanged 命令的默认漂亮格式。请参阅 git-log[1]git-show[1]git-whatchanged[1]

format.thread

git format-patch 的默认线程样式。可以是布尔值,也可以是 shallowdeepshallow 线程使每封邮件都回复到系列的头部,其中头部是从介绍信、--in-reply-to 和第一封补丁邮件中选择的,按此顺序。deep 线程使每封邮件都回复到前一封邮件。布尔值 true 与 shallow 相同,布尔值 false 禁用线程。

format.signOff

一个布尔值,允许您默认启用 format-patch 的 -s/--signoff 选项。**注意:**将 Signed-off-by 尾部添加到补丁应该是深思熟虑的行为,这意味着您证明您有权在相同的开源许可下提交此工作。请参阅 SubmittingPatches 文档以获取进一步讨论。

format.coverLetter

一个布尔值,控制在调用 format-patch 时是否生成介绍信,但此外可以设置为“auto”,仅当有多个补丁时才生成介绍信。默认为 false。

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将否定以前的配置并且不显示注释。

例如,

[format]
	notes = true
	notes = foo
	notes = false
	notes = bar

将仅显示来自refs/notes/bar的注释。

format.mboxrd

一个布尔值,当使用--stdout转义"^>+From "行时,启用强大的“mboxrd”格式。

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.uicore.editor等变量不同,如果未设置receive.fsck.<msg-id>fetch.fsck.<msg-id>变量,则不会回退到fsck.<msg-id>配置。为了在不同的情况下统一配置相同的fsck设置,必须将所有三个变量都设置为相同的值。

当设置fsck.<msg-id>时,可以通过配置fsck.<msg-id>设置将错误切换为警告,反之亦然,其中<msg-id>是fsck消息ID,值是errorwarnignore之一。为了方便起见,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.skipListfetch.fsck.skipList变体。

color.uicore.editor等变量不同,如果未设置receive.fsck.skipListfetch.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将打包它们。一些瓷器命令使用此命令不时执行轻量级垃圾回收。默认值为6700。

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

gc.autoPackLimit

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

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

gc.autoDetach

如果系统支持,则使git gc --auto立即返回并在后台运行。默认为true。如果未设置maintenance.autoDetach,则此配置变量充当后备。

gc.bigPackThreshold

如果非零,则运行git gc时,所有大于此限制的非废弃包都将保留。这与--keep-largest-pack非常相似,只是所有满足阈值的非废弃包都将保留,而不仅仅是最大的包。默认为零。支持kmg的常用单位后缀。

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

如果估计用于git repack平稳运行的内存不可用并且未设置gc.bigPackThreshold,则也将排除最大的包(这等效于使用--keep-largest-pack运行git gc)。

gc.writeCommitGraph

如果为true,则在运行git-gc[1]时,gc将重写commit-graph文件。当使用git gc --auto时,如果需要进行日常维护,则将更新commit-graph。默认为true。有关详细信息,请参阅git-commit-graph[1]

gc.logExpiry

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

gc.packRefs

在存储库中运行git pack-refs会使Git 1.5.1.2之前的版本无法通过HTTP等哑传输克隆它。此变量确定git gc是否运行git pack-refs。可以将其设置为notbare以在所有非裸存储库中启用它,也可以将其设置为布尔值。默认为true

gc.cruftPacks

将不可达对象存储在废弃包中(请参阅git-repack[1]),而不是作为松散对象。默认为true

gc.maxCruftSize

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

gc.pruneExpire

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

gc.worktreePruneExpire

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

gc.reflogExpire
gc.<pattern>.reflogExpire

git reflog expire 删除早于此时间之前的 reflog 条目;默认为 90 天。值“now”会立即过期所有条目,而“never”则完全抑制过期。在中间使用“<pattern>” (例如“refs/stash”) 时,设置仅适用于与 <pattern> 匹配的 refs。

gc.reflogExpireUnreachable
gc.<pattern>.reflogExpireUnreachable

git reflog expire 删除早于此时间且无法从当前顶端访问的 reflog 条目;默认为 30 天。值“now”会立即过期所有条目,而“never”则完全抑制过期。在中间使用“<pattern>” (例如“refs/stash”) 时,设置仅适用于与 <pattern> 匹配的 refs。

这些类型的条目通常是使用git commit --amendgit rebase的结果,并且是修改或变基之前提交的提交。由于这些更改不是当前项目的一部分,因此大多数用户希望更快地使它们过期,这就是默认值比gc.reflogExpire更激进的原因。

gc.recentObjectsHook

在考虑是否删除对象时(无论是在生成废弃包还是将无法访问的对象存储为松散对象时),都使用 shell 执行指定的命令。将它们的输出解释为 Git 将视为“最近”的对象 ID,无论其年龄如何。通过将它们的修改时间视为“now”,输出中提到的任何对象(及其后代)都将保留,无论其真实年龄如何。

输出必须每行恰好包含一个十六进制对象 ID,以及其他任何内容。存储库中找不到的对象将被忽略。支持多个钩子,但所有钩子都必须成功退出,否则操作(无论是生成废弃包还是解压缩无法访问的对象)都将停止。

gc.repackFilter

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

gc.repackFilterTo

重新打包并使用过滤器时,请参阅gc.repackFilter,指定的路径将用于创建包含已过滤对象的包文件。**警告:**指定的路径应该是可访问的,例如使用 Git 备用机制,否则 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

如果为真,则服务器将查找文件的换行符转换属性以确定要使用的-k模式。如果属性强制 Git 将文件视为文本,则-k模式将留空,以便 CVS 客户端将其视为文本。如果它们抑制文本转换,则文件将设置为-kb模式,这将抑制客户端可能执行的任何换行符修改。如果属性不允许确定文件类型,则使用gitcvs.allBinary。请参阅gitattributes[5]

gitcvs.allBinary

如果gitcvs.usecrlfattr无法解析要使用的正确的-kb模式,则使用此模式。如果为真,则所有未解析的文件都将以-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.usecrlfattrgitcvs.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 签名时,使用此自定义程序而不是$PATH上找到的“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.programgpg.formatgpg.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 公钥组成。例如:[email protected],[email protected] 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

设置默认匹配行为。使用 basicextendedfixedperl 值将分别启用 --basic-regexp--extended-regexp--fixed-strings--perl-regexp 选项,而 default 值将使用 grep.extendedRegexp 选项在 basicextended 之间进行选择。

grep.extendedRegexp

如果设置为 true,则默认启用 --extended-regexp 选项。当 grep.patternType 选项设置为除 default 以外的值时,此选项将被忽略。

grep.threads

要使用的 grep 工作线程数。如果未设置(或设置为 0),Git 将使用与可用逻辑核心数相同的线程数。

grep.fullName

如果设置为 true,则默认启用 --full-name 选项。

grep.fallbackToNoIndex

如果设置为 true,则如果在 Git 存储库之外执行 git grep,则回退到 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

如果 git-gui[1] 在执行 fetch 时应修剪远程跟踪分支,则为“true”。默认值为“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 调用“显示历史上下文”菜单项时,在 gitk[1] 中显示所选提交的历史上下文半径(以天为单位)。如果此变量设置为零,则显示整个历史记录。

guitool.<name>.cmd

指定当调用 git-gui[1] 的“工具”菜单中的相应项时要执行的 shell 命令行。此选项对于每个工具都是必需的。该命令从工作目录的根目录执行,并在环境中接收工具的名称作为 GIT_GUITOOL、当前选择的文件的名称作为 FILENAME 以及当前分支的名称作为 CUR_BRANCH(如果 HEAD 已分离,则 CUR_BRANCH 为空)。

guitool.<name>.needsFile

仅当在 GUI 中选择差异时才运行工具。它保证 FILENAME 不为空。

guitool.<name>.noConsole

静默运行命令,不创建窗口来显示其输出。

guitool.<name>.noRescan

工具执行完成后,不要重新扫描工作目录以查找更改。

guitool.<name>.confirm

在实际运行工具之前显示确认对话框。

guitool.<name>.argPrompt

向用户请求字符串参数,并通过 ARGS 环境变量将其传递给工具。由于请求参数意味着确认,因此如果启用了此选项,则 confirm 选项无效。如果选项设置为 trueyes1,则对话框使用内置的通用提示;否则使用变量的精确值。

guitool.<name>.revPrompt

向用户请求单个有效修订版,并设置 REVISION 环境变量。在其他方面,此选项类似于 argPrompt,并且可以与它一起使用。

guitool.<name>.revUnmerged

仅在 revPrompt 子对话框中显示未合并的分支。这对于类似于合并或变基的工具很有用,但不适用于检出或重置等操作。

guitool.<name>.title

指定用于提示对话框的标题。默认值为工具名称。

guitool.<name>.prompt

指定在 argPromptrevPrompt 的子部分之前显示在对话框顶部的通用提示字符串。默认值包含实际命令。

help.browser

指定将用于以 web 格式显示帮助的浏览器。请参阅 git-help[1]

help.format

覆盖 git-help[1] 使用的默认帮助格式。支持 maninfowebhtml 值。man 为默认值。webhtml 相同。

help.autoCorrect

如果 Git 检测到拼写错误并且可以识别与错误完全相同的有效命令,Git 将尝试建议正确的命令,甚至自动运行建议。可能的配置值为

  • 0(默认):显示建议的命令。

  • 正数:在指定的十分之一秒(0.1 秒)后运行建议的命令。

  • “immediate”:立即运行建议的命令。

  • “prompt”:显示建议并提示确认是否运行命令。

  • “never”:不运行或显示任何建议的命令。

help.htmlPath

指定 HTML 文档所在的路径。支持文件系统路径和 URL。在以web格式显示帮助时,HTML 页面将以该路径为前缀。默认为 Git 安装的文档路径。

http.proxy

覆盖 HTTP 代理,通常使用http_proxyhttps_proxyall_proxy环境变量配置(参见curl(1))。除了 curl 理解的语法之外,还可以指定一个包含用户名但没有密码的代理字符串,在这种情况下,git 将尝试以与获取其他凭据相同的方式获取密码。有关更多信息,请参见gitcredentials[7]。语法为[protocol://][user[:password]@]proxyhost[:port][/path]。可以在每个远程的基础上覆盖此设置;请参阅remote.<name>.proxy

无论如何配置,任何代理都必须完全透明,并且绝不能以任何方式修改、转换或缓冲请求或响应。已知不完全透明的代理会导致 Git 出现各种故障。

http.proxyAuthMethod

设置用于对 HTTP 代理进行身份验证的方法。只有当配置的代理字符串包含用户名部分(即格式为user@hostuser@host:port)时,此设置才会生效。可以在每个远程的基础上覆盖此设置;请参阅remote.<name>.proxyAuthMethod。两者都可以被GIT_HTTP_PROXY_AUTHMETHOD环境变量覆盖。可能的值为

  • anyauth - 自动选择合适的身份验证方法。假设代理会以 407 状态代码和一个或多个包含支持的身份验证方法的 Proxy-authenticate 标头来响应未经身份验证的请求。这是默认值。

  • basic - HTTP 基本身份验证

  • digest - HTTP 摘要身份验证;这可以防止密码以明文形式传输到代理

  • negotiate - GSS-Negotiate 身份验证(比较curl(1)的 --negotiate 选项)

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

http.proxySSLCert

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

http.proxySSLKey

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

http.proxySSLCertPasswordProtected

启用 Git 对代理 SSL 证书的密码提示。否则,如果证书或私钥已加密,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字段),则将使用该值;如果提供了用户名和密码但没有方案,则使用基本身份验证。选项的值确定从助手请求的方案。可能的值为

  • basic - 从助手请求基本身份验证。

  • auto - 允许助手选择合适的方案。

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

请注意,应始终在此配置中使用 TLS,因为否则如果选择了基本身份验证,则很容易意外地公开明文凭据。

http.delegation

控制 GSSAPI 凭据委托。从 libcurl 7.21.7 版开始,默认情况下禁用委托。设置参数以告诉服务器在涉及用户凭据时允许委托的内容。与 GSS/kerberos 一起使用。可能的值为

  • none - 不允许任何委托。

  • policy - 当且仅当 Kerberos 服务票证中设置了 OK-AS-DELEGATE 标志时才进行委托,这取决于领域的策略。

  • always - 无条件地允许服务器进行委托。

http.extraHeader

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

http.cookieFile

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

http.saveCookies

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

http.version

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

  • HTTP/2

  • HTTP/1.1

http.curloptResolve

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

  • [+]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

启用 Git 对 SSL 证书的密码提示。否则,如果证书或私钥已加密,OpenSSL 可能会多次提示用户。可以被GIT_SSL_CERT_PASSWORD_PROTECTED环境变量覆盖。

http.sslCAInfo

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

http.sslCAPath

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

http.sslBackend

要使用的 SSL 后端名称(例如“openssl”或“schannel”)。如果 cURL 缺少在运行时选择 SSL 后端的支持,则会忽略此选项。

http.schannelCheckRevoke

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

http.schannelUseSSLCAInfo

从 cURL v7.60.0 开始,安全通道后端可以使用通过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 用于避免在本地创建大型的 pack 文件。默认为 1 MiB,这足以满足大多数请求。

请注意,提高此限制仅对禁用分块传输编码有效,因此仅应在远程服务器或代理仅支持 HTTP/1.0 或不符合 HTTP 标准的情况下使用。通常,提高此限制不是解决大多数推送问题的好方法,但会显着增加内存消耗,因为即使对于小的推送也会分配整个缓冲区。

http.lowSpeedLimit, http.lowSpeedTime

如果 HTTP 传输速度(以每秒字节数计)低于 http.lowSpeedLimit 持续时间超过 http.lowSpeedTime 秒,则传输将中止。可以被 GIT_HTTP_LOW_SPEED_LIMITGIT_HTTP_LOW_SPEED_TIME 环境变量覆盖。

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 的元素进行比较

  1. 方案(例如,https://example.com/ 中的 https)。此字段必须在配置键和 URL 之间完全匹配。

  2. 主机/域名(例如,https://example.com/ 中的 example.com)。此字段必须在配置键和 URL 之间匹配。可以在主机名中指定 * 以匹配此级别的所有子域名。例如,https://*.example.com/ 将匹配 https://foo.example.com/,但不会匹配 https://foo.bar.example.com/

  3. 端口号(例如,http://example.com:8080/ 中的 8080)。此字段必须在配置键和 URL 之间完全匹配。在匹配之前,省略的端口号会自动转换为方案的正确默认值。

  4. 路径(例如,https://example.com/repo.git 中的 repo.git)。配置键的路径字段必须与 URL 的路径字段完全匹配或作为斜杠分隔的路径元素的前缀匹配。这意味着路径为 foo/ 的配置键与 URL 路径 foo/bar 匹配。前缀只能在斜杠 (/) 边界处匹配。更长的匹配优先(因此路径为 foo/bar 的配置键与 URL 路径 foo/bar 的匹配优于仅路径为 foo/ 的配置键)。

  5. 用户名(例如,https://[email protected]/repo.git 中的 user)。如果配置键具有用户名,则它必须与 URL 中的用户名完全匹配。如果配置键没有用户名,则该配置键将与具有任何用户名的 URL(包括无用户名)匹配,但优先级低于具有用户名的配置键。

以上列表按优先级递减排序;与配置键的路径匹配的 URL 优先于与它的用户名匹配的 URL。例如,如果 URL 为 https://[email protected]/foo/bar,则配置键匹配 https://example.com/foo 将优先于配置键匹配 https://[email protected]

在尝试任何匹配之前,所有 URL 都会被规范化(如果嵌入在 URL 中,密码部分始终会被忽略以进行匹配),以便简单拼写不同的等效 URL 可以正确匹配。环境变量设置始终会覆盖任何匹配。匹配的 URL 是直接提供给 Git 命令的 URL。这意味着由于重定向而访问的任何 URL 都不参与匹配。

i18n.commitEncoding

存储提交消息的字符编码;Git 本身并不关心,但此信息对于例如从电子邮件导入提交或在 gitk 图形历史浏览器中(以及将来或其他瓷器中的其他地方)是必要的。例如,请参阅 git-mailinfo[1]。默认为 utf-8

i18n.logOutputEncoding

运行 git log 及其相关命令时提交消息转换为的字符编码。

imap.folder

将邮件放入的文件夹,通常是草稿文件夹。例如:“INBOX.Drafts”、“INBOX/Drafts”或“[Gmail]/Drafts”。必需。

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,则唯一支持的方法是 CRAM-MD5。如果未设置此选项,则 git imap-send 使用基本的 IMAP 纯文本 LOGIN 命令。

include.path
includeIf.<condition>.path

包含其他配置文件的特殊变量。请参阅主要 git-config[1] 文档中的“配置文件”部分,特别是“包含”和“条件包含”小节。

index.recordEndOfIndexEntries

指定索引文件是否应包含“索引条目结束”部分。这减少了多处理器机器上的索引加载时间,但在使用 2.20 之前的 Git 版本读取索引时会显示消息“忽略 EOIE 扩展”。如果已明确启用 index.threads,则默认为 true,否则默认为 false

index.recordOffsetTable

指定索引文件是否应包含“索引条目偏移表”部分。这减少了多处理器机器上的索引加载时间,但在使用 2.20 之前的 Git 版本读取索引时会显示消息“忽略 IEOT 扩展”。如果已明确启用 index.threads,则默认为 true,否则默认为 false

index.sparse

启用后,使用稀疏目录条目写入索引。除非同时启用了 core.sparseCheckoutcore.sparseCheckoutCone,否则此选项无效。默认为 false

index.threads

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

index.version

指定应使用哪个版本初始化新的索引文件。这不会影响现有存储库。如果启用了 feature.manyFiles,则默认为 4。

index.skipHash

启用后,不要为索引文件计算尾随哈希。这加快了操作索引的 Git 命令(例如 git addgit commitgit status)的速度。不存储校验和,而是写入一组值为零的尾随字节,指示已跳过计算。

如果启用 index.skipHash,则 2.13.0 之前的 Git 客户端将拒绝解析索引,并且 2.40.0 之前的 Git 客户端将在 git fsck 期间报告错误。

init.templateDir

指定将从中复制模板的目录。(请参阅 git-init[1] 的“模板目录”部分。)

init.defaultBranch

例如,在初始化新存储库时允许覆盖默认分支名称。

init.defaultObjectFormat

允许覆盖新仓库的默认对象格式。请参阅 git-init[1] 中的 --object-format=。命令行选项和 GIT_DEFAULT_HASH 环境变量优先于此配置。

init.defaultRefFormat

允许覆盖新仓库的默认引用存储格式。请参阅 git-init[1] 中的 --ref-format=。命令行选项和 GIT_DEFAULT_REF_FORMAT 环境变量优先于此配置。

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)显示彩色 diff 时,git 会将 diff 通过此配置变量定义的 shell 命令传递。该命令可以进一步标记 diff 以供人类使用,前提是它与原始 diff 中的行保持一对一对应关系。默认为禁用(不进行过滤)。

log.abbrevCommit

如果为 true,则 git-log[1]git-show[1]git-whatchanged[1] 将假定 --abbrev-commit。可以使用 --no-abbrev-commit 覆盖此选项。

log.date

设置 log 命令的默认日期时间模式。为 log.date 设置值类似于使用 git log--date 选项。有关详细信息,请参阅 git-log[1]

如果格式设置为 "auto:foo" 并且正在使用分页器,则格式 "foo" 将用于日期格式。否则,将使用 "default"。

log.decorate

打印出 log 命令显示的任何提交的引用名称。如果指定了 short,则不会打印引用名称前缀 refs/heads/refs/tags/refs/remotes/。如果指定了 full,则将打印完整的引用名称(包括前缀)。如果指定了 auto,则如果输出到终端,则引用名称将显示为如果给出了 short 一样,否则不显示引用名称。这与 git log--decorate 选项相同。

log.initialDecorationSet

默认情况下,git log 仅显示某些已知引用命名空间的修饰。如果指定了 all,则将所有引用显示为修饰。

log.excludeDecoration

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

log.diffMerges

指定 --diff-merges=on 时使用的 diff 格式,有关详细信息,请参阅 git-log[1] 中的 --diff-merges。默认为 separate

log.follow

如果为 true,则当给定单个 <path> 时,git log 将表现得好像使用了 --follow 选项一样。这与 --follow 具有相同的限制,即它不能用于跟踪多个文件,并且在非线性历史记录中效果不佳。

log.graphColors

一系列颜色,用逗号分隔,可用于在 git log --graph 中绘制历史记录线。

log.showRoot

如果为 true,则初始提交将显示为一个大型创建事件。这等效于针对空树的 diff。像 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.filemailmap.blob,则两者都会被解析,其中 mailmap.file 中的条目优先。在裸仓库中,默认为 HEAD:.mailmap。在非裸仓库中,默认为空。

maintenance.auto

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

maintenance.autoDetach

许多 Git 命令在将数据写入仓库后会触发自动维护。此布尔型配置选项控制此自动维护是否在前景发生,或者维护进程是否应分离并在后台继续运行。

如果未设置,则 gc.autoDetach 的值将用作后备。如果两者都未设置,则默认为 true,这意味着维护进程将分离。

maintenance.strategy

此字符串配置选项提供了一种方法来指定一些推荐的后台维护计划。这仅影响在 git maintenance run --schedule=X 命令期间运行的任务,前提是没有提供 --task=<task> 参数。此外,如果设置了 maintenance.<task>.schedule 配置值,则将使用该值而不是 maintenance.strategy 提供的值。可能的策略字符串为

  • none:此默认设置表示在任何计划中都不运行任何任务。

  • incremental:此设置针对执行不会删除任何数据的小型维护活动进行了优化。这不会安排 gc 任务,但会每小时运行 prefetchcommit-graph 任务,每天运行 loose-objectsincremental-repack 任务,每周运行 pack-refs 任务。

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

此整数配置选项控制作为 git maintenance run --auto 的一部分运行 commit-graph 任务的频率。如果为零,则 commit-graph 任务不会使用 --auto 选项运行。负值将强制每次运行该任务。否则,正值表示当不在 commit-graph 文件中的可到达提交数至少为 maintenance.commit-graph.auto 的值时,应运行该命令。默认值为 100。

maintenance.loose-objects.auto

此整数值配置选项控制在 git maintenance run --auto 中运行 loose-objects 任务的频率。如果为零,则 loose-objects 任务不会在使用 --auto 选项时运行。负值将强制任务每次都运行。否则,正值表示当松散对象的数量至少为 maintenance.loose-objects.auto 的值时运行该命令。默认值为 100。

maintenance.incremental-repack.auto

此整数值配置选项控制在 git maintenance run --auto 中运行 incremental-repack 任务的频率。如果为零,则 incremental-repack 任务不会在使用 --auto 选项时运行。负值将强制任务每次都运行。否则,正值表示当不在多包索引中的包文件数量至少为 maintenance.incremental-repack.auto 的值时运行该命令。默认值为 10。

man.viewer

指定可用于以 man 格式显示帮助的程序。请参阅 git-help[1]

man.<tool>.cmd

指定用于调用指定 man 查看器的命令。指定的命令在 shell 中执行,并将手册页作为参数传递。(请参阅 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

通过向此多值配置变量添加匹配集成分支名称的通配符,为合并到这些集成分支计算的默认合并消息将从其标题中省略“into <branch name>”。

可以使用具有空值的元素来清除从以前的配置条目中累积的通配符列表。当没有定义 merge.suppressDest 变量时,出于向后兼容性,将使用 master 的默认值。

merge.renameLimit

在合并期间重命名检测的详尽部分中要考虑的文件数量。如果未指定,则默认为 diff.renameLimit 的值。如果既未指定 merge.renameLimit 也未指定 diff.renameLimit,则当前默认为 7000。如果关闭了重命名检测,则此设置无效。

merge.renames

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

merge.directoryRenames

Git 是否检测目录重命名,这会影响在合并时如何处理在历史记录的一侧添加到目录的新文件,而该目录在历史记录的另一侧已重命名。如果 merge.directoryRenames 设置为“false”,则禁用目录重命名检测,这意味着此类新文件将保留在旧目录中。如果设置为“true”,则启用目录重命名检测,这意味着此类新文件将移动到新目录中。如果设置为“conflict”,则将报告此类路径的冲突。如果 merge.renames 为 false,则忽略 merge.directoryRenames 并将其视为 false。默认为“conflict”。

merge.renormalize

告诉 Git 存储库中文件的规范表示形式已随时间变化(例如,较早的提交记录带有 CRLF 行结尾的文本文件,但最近的提交使用 LF 行结尾)。在这样的存储库中,Git 可以在执行合并之前将提交中记录的数据转换为规范形式,以减少不必要的冲突。有关更多信息,请参阅 gitattributes[5] 中的“合并具有不同签入/签出属性的分支”部分。

merge.stat

是否在合并结束时打印 ORIG_HEAD 和合并结果之间的 diffstat。默认为 true。

merge.autoStash

当设置为 true 时,在操作开始之前自动创建一个临时存储条目,并在操作结束之后应用它。这意味着您可以在脏工作树上运行合并。但是,请谨慎使用:成功合并后的最终存储应用可能会导致非平凡的冲突。此选项可以通过 git-merge[1]--no-autostash--autostash 选项覆盖。默认为 false。

merge.tool

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

merge.guitool

当指定 -g/--gui 标志时,控制 git-mergetool[1] 使用哪个合并工具。以下列表显示了有效的内置值。任何其他值都被视为自定义合并工具,并且需要定义相应的 mergetool.<guitool>.cmd 变量。

  • araxis

  • bc

  • codecompare

  • deltawalker

  • diffmerge

  • diffuse

  • ecmerge

  • emerge

  • examdiff

  • guiffy

  • gvimdiff

  • kdiff3

  • meld

  • nvimdiff

  • opendiff

  • p4merge

  • smerge

  • tkdiff

  • tortoisemerge

  • vimdiff

  • vscode

  • winmerge

  • xxdiff

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,并且仅在可用时使用--auto-merge。值为false完全避免使用--auto-merge,这是默认值。

mergetool.<vimdiff variant>.layout

配置vimdiff的<variant>的分割窗口布局,其中<variant>可以是vimdiffnvimdiffgvimdiff。在使用--tool=<variant>(或者如果merge.tool配置为<variant>则不使用--tool)启动git mergetool时,Git将查阅mergetool.<variant>.layout以确定工具的布局。如果无法使用特定于变体的配置,则将使用vimdiff的配置作为后备。如果该配置也无法使用,则将使用具有4个窗口的默认布局。有关如何配置布局,请参阅git-mergetool[1]中的“BACKEND SPECIFIC HINTS”部分。

mergetool.hideResolved

在合并过程中,Git会自动解决尽可能多的冲突,并写入包含冲突标记的MERGED文件,这些标记围绕着它无法解决的任何冲突;LOCALREMOTE通常代表Git冲突解决之前文件的版本。此标志导致LOCALREMOTE被覆盖,以便仅将未解决的冲突呈现给合并工具。可以通过mergetool.<tool>.hideResolved配置变量为每个工具进行配置。默认为false

mergetool.keepBackup

执行合并后,可以将包含冲突标记的原始文件保存为扩展名为.orig的文件。如果此变量设置为false,则不会保留此文件。默认为true(即保留备份文件)。

mergetool.keepTemporaries

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

mergetool.writeToTemp

默认情况下,Git会在工作树中写入冲突文件的临时BASELOCALREMOTE版本。当设置为true时,Git将尝试为这些文件使用临时目录。默认为false

mergetool.prompt

在每次调用合并解决程序之前提示。

mergetool.guiDefault

设置为true以默认使用merge.guitool(相当于指定--gui参数),或设置为auto以根据DISPLAY环境变量值的存在选择merge.guitoolmerge.tool。默认为false,其中必须显式提供--gui参数才能使用merge.guitool

notes.mergeStrategy

在解决注释冲突时默认选择哪种合并策略。必须是manualourstheirsunioncat_sort_uniq之一。默认为manual。有关每种策略的更多信息,请参阅git-notes[1]的“NOTES MERGE STRATEGIES”部分。

可以通过将--strategy选项传递给git-notes[1]来覆盖此设置。

notes.<name>.mergeStrategy

在将注释合并到refs/notes/<name>时选择哪种合并策略。这将覆盖更通用的“notes.mergeStrategy”。有关可用策略的更多信息,请参阅git-notes[1]的“NOTES MERGE STRATEGIES”部分。

notes.displayRef

除了core.notesRefGIT_NOTES_REF设置的默认值之外,还要读取哪个ref(或refs,如果为glob或指定多次)的注释,以便在使用git log系列命令显示提交消息时使用。

此设置可以通过GIT_NOTES_DISPLAY_REF环境变量覆盖,该变量必须是冒号分隔的ref或glob列表。

将对不存在的ref发出警告,但与任何ref都不匹配的glob将被静默忽略。

此设置可以通过git log系列命令的--no-notes选项或这些命令接受的--notes=<ref>选项禁用。

“core.notesRef”的有效值(可能被GIT_NOTES_REF覆盖)也会隐式添加到要显示的ref列表中。

notes.rewrite.<command>

使用<command>(目前为amendrebase)重写提交时,如果此变量为false,则git将不会从原始提交复制注释到重写后的提交。默认为true。另请参阅下面的“notes.rewriteRef”。

此设置可以通过GIT_NOTES_REWRITE_REF环境变量覆盖,该变量必须是冒号分隔的ref或glob列表。

notes.rewriteMode

在重写期间复制注释时(请参阅“notes.rewrite.<command>”选项),如果目标提交已具有注释,则确定该怎么办。必须是overwriteconcatenatecat_sort_uniqignore之一。默认为concatenate

此设置可以通过GIT_NOTES_REWRITE_MODE环境变量覆盖。

notes.rewriteRef

在重写期间复制注释时,指定应复制其注释的(完全限定的)ref。可以是glob,在这种情况下,将复制所有匹配ref中的注释。您也可以多次指定此配置。

没有默认值;您必须配置此变量才能启用注释重写。将其设置为refs/notes/commits以启用对默认提交注释的重写。

可以通过GIT_NOTES_REWRITE_REF环境变量覆盖。有关其格式的进一步说明,请参阅上面的notes.rewrite.<command>

pack.window

当命令行上未给出窗口大小时,git-pack-objects[1]使用的窗口大小。默认为10。

pack.depth

当命令行上未给出最大深度时,git-pack-objects[1]使用的最大delta深度。默认为50。最大值为4095。

pack.windowMemory

当命令行上未给出限制时,git-pack-objects[1]中每个线程为打包窗口内存消耗的最大内存大小。该值可以后缀“k”、“m”或“g”。未配置(或显式设置为0)时,将没有限制。

pack.compression

一个整数-1..9,指示打包文件中对象的压缩级别。-1是zlib的默认值。0表示不压缩,1..9是各种速度/大小权衡,9是最慢的。如果未设置,则默认为core.compression。如果未设置,则默认为-1,即zlib的默认值,即“速度和压缩之间的默认折衷(目前相当于级别6)”。

请注意,更改压缩级别不会自动重新压缩所有现有对象。可以通过将-F选项传递给git-repack[1]来强制重新压缩。

pack.allowPackReuse

当为true或“single”,并且启用可达性位图时,pack-objects将尝试逐字发送位图打包文件的部分内容。当为“multi”,并且可以使用多打包可达性位图时,pack-objects将尝试发送MIDX中所有打包文件的部分内容。

如果仅可使用单个打包位图,并且pack.allowPackReuse设置为“multi”,则重用仅位图打包文件的部分内容。这可以减少内存和CPU使用量以服务获取,但可能导致发送稍大的打包文件。默认为true。

pack.island

配置一组delta岛的扩展正则表达式。有关详细信息,请参阅git-pack-objects[1]中的“DELTA ISLANDS”。

pack.islandCore

指定一个岛屿名称,该名称可以首先打包其对象。这会在一个打包文件的前面创建一种伪打包,以便来自指定岛屿的对象有望更快地复制到应提供给请求这些对象的用户的任何打包文件中。在实践中,这意味着指定的岛屿应该可能对应于存储库中最常克隆的内容。另请参阅git-pack-objects[1]中的“DELTA ISLANDS”。

pack.deltaCacheSize

在写入打包文件之前,git-pack-objects[1]用于缓存delta的最大内存(以字节为单位)。此缓存用于通过在找到所有对象的最佳匹配后不必重新计算最终的delta结果来加快写入对象阶段的速度。不过,在内存紧张的机器上重新打包大型存储库可能会受到严重影响,尤其是在此缓存将系统推入交换的情况下。值为0表示没有限制。可以使用最小的1字节大小来虚拟地禁用此缓存。默认为256 MiB。

pack.deltaCacheLimit

git-pack-objects[1]中缓存的delta的最大大小。此缓存用于通过在找到所有对象的最佳匹配后不必重新计算最终的delta结果来加快写入对象阶段的速度。默认为1000。最大值为65535。

pack.threads

指定在搜索最佳delta匹配时要生成的线程数。这需要git-pack-objects[1]使用pthreads编译,否则此选项将被忽略并发出警告。这旨在减少多处理器机器上的打包时间。但是,delta搜索窗口所需的内存量将乘以线程数。指定0将导致Git自动检测CPU数量并相应地设置线程数。

pack.indexVersion

指定默认的打包索引版本。有效值为1,用于Git 1.5.2之前的版本使用的旧打包索引,以及2,用于新的打包索引,该索引具有大于4 GB的打包文件的功能以及针对损坏的打包文件重新打包的适当保护。版本2是默认值。请注意,每当相应的打包文件大于2 GB时,版本2都会被强制执行,并且此配置选项将被忽略。

如果您拥有一个不理解版本2 *.idx文件的旧Git,则通过非本地协议(例如“http”)克隆或获取将从另一端复制*.pack文件和相应的*.idx文件可能会导致您拥有一个无法使用旧版Git访问的存储库。但是,如果*.pack文件小于2 GB,则可以使用git-index-pack[1]在*.pack文件上重新生成*.idx文件。

pack.packSizeLimit

打包文件的大小上限。此设置仅影响重新打包时打包到文件的情况,即git://协议不受影响。它可以通过git-repack[1]--max-pack-size选项覆盖。达到此限制会导致创建多个打包文件。

请注意,此选项很少有用,并且可能导致磁盘总大小增加(因为 Git 不会存储包之间的增量),并且运行时性能下降(在多个包中查找对象比在单个包中查找对象慢,并且可达性位图等优化无法处理多个包)。

如果您需要使用较小的 packfile 积极运行 Git(例如,因为您的文件系统不支持大文件),此选项可能会有所帮助。但是,如果您的目标是通过支持有限大小的介质传输 packfile(例如,无法存储整个存储库的可移动介质),您最好创建一个单个大型 packfile 并使用通用的多卷归档工具(例如,Unix 的 split)将其拆分。

允许的最小大小限制为 1 MiB。默认值为无限制。支持常见的单位后缀 kmg

pack.useBitmaps

如果为 true,则 git 将在打包到标准输出时(例如,在获取的服务器端)使用 pack 位图(如果可用)。默认为 true。您通常不需要关闭它,除非您正在调试 pack 位图。

pack.useBitmapBoundaryTraversal

如果为 true,则 Git 将使用一种实验性算法来计算使用位图的可达性查询。与其为所有否定的提示构建完整的位图然后将它们组合在一起,不如将具有现有位图的否定提示视为附加(即,如果它们存在则将其 OR 到结果中,否则忽略它们),并在边界处构建位图。

使用此算法时,Git 可能会由于未打开属于某些 UNINTERESTING 提交的树而导致包含过多的对象。这种不精确性与非位图遍历算法相匹配。

在许多情况下,这可以比精确算法提供更快的速度,尤其是在查询的否定方面位图覆盖率较差时。

pack.useSparse

如果为 true,则当存在 --revs 选项时,git 将默认使用 git pack-objects 中的 --sparse 选项。此算法仅遍历出现在引入新对象的路径中的树。在计算要发送的小更改的包时,这可以带来显着的性能优势。但是,如果包含的提交包含某些类型的直接重命名,则可能会将额外对象添加到包文件中。默认为 true

pack.preferBitmapTips

在选择哪些提交将接收位图时,优先考虑任何此配置值的任何后缀的任何引用的顶端的提交,而不是“选择窗口”中的任何其他提交。

请注意,将此配置设置为 refs/foo 并不意味着 refs/foo/barrefs/foo/baz 顶端的提交一定会被选中。这是因为提交是从一系列可变长度的窗口中为位图选择的。

如果在窗口中看到任何此配置值的任何后缀的任何引用的顶端的提交,则会立即优先于该窗口中的任何其他提交。

pack.writeBitmaps(已弃用)

这是 repack.writeBitmaps 的已弃用同义词。

pack.writeBitmapHashCache

如果为 true,则 git 将在位图索引中包含“哈希缓存”部分(如果写入了一个)。此缓存可用于为 git 的增量启发式提供信息,从而可能导致位图对象和非位图对象之间产生更好的增量(例如,在旧的位图包和自上次 gc 以来已推送的对象之间提供获取时)。缺点是它消耗每个对象 4 字节的磁盘空间。默认为 true。

在写入多包可达性位图时,不会计算新的 namehash;相反,在写入新的位图时,将任何存储在现有位图中的 namehash 重新排列到其适当的位置。

pack.writeBitmapLookupTable

如果为 true,则 Git 将在位图索引中包含“查找表”部分(如果写入了一个)。此表用于尽可能延迟加载各个位图。这在具有相对较大的位图索引的存储库中可能很有用。默认为 false。

pack.readReverseIndex

如果为 true,则 git 将读取任何可能可用的 .rev 文件(请参阅:gitformat-pack[5])。如果为 false,则将从头开始生成反向索引并将其存储在内存中。默认为 true。

pack.writeReverseIndex

如果为 true,则 git 将为其在所有位置(除了 git-fast-import[1] 和批量签入机制中)写入的每个新 packfile 写入相应的 .rev 文件(请参阅:gitformat-pack[5])。默认为 true。

pager.<cmd>

如果值为布尔值,则在写入 tty 时打开或关闭特定 Git 子命令输出的分页。否则,使用 pager.<cmd> 的值指定的分页程序为子命令打开分页。如果在命令行上指定了 --paginate--no-pager,则它优先于此选项。要禁用所有命令的分页,请将 core.pagerGIT_PAGER 设置为 cat

pretty.<name>

git-log[1] 中所述,--pretty= 格式字符串的别名。此处定义的任何别名都可以像内置漂亮格式一样使用。例如,运行 git config pretty.changelog "format:* %H %s" 将导致调用 git log --pretty=changelog 等效于运行 git log "--pretty=format:* %H %s"。请注意,与内置格式同名的别名将被静默忽略。

promisor.quiet

如果设置为“true”,则在为部分克隆获取其他对象时假定 --quiet

protocol.allow

如果设置,则为所有未明确具有策略的协议(protocol.<name>.allow)提供用户定义的默认策略。默认情况下,如果未设置,则已知安全的协议(http、https、git、ssh)的默认策略为 always,已知危险的协议(ext)的默认策略为 never,所有其他协议(包括文件)的默认策略为 user。支持的策略

  • always - 协议始终可以使用。

  • never - 协议永远无法使用。

  • user - 仅当 GIT_PROTOCOL_FROM_USER 未设置或值为 1 时,协议才能使用。当您希望用户可以直接使用协议但又不想让不带用户输入的执行克隆/获取/推送命令的命令使用它时,应使用此策略,例如递归子模块初始化。

protocol.<name>.allow

设置克隆/获取/推送命令使用的协议 <name> 的策略。有关可用策略,请参见上面的 protocol.allow

git 当前使用的协议名称为

  • file:任何基于文件的本地路径(包括 file:// URL 或本地路径)

  • git:通过直接 TCP 连接(或代理,如果已配置)的匿名 git 协议。

  • ssh:通过 ssh 的 git(包括 host:path 语法、ssh:// 等)。

  • http:通过 http 的 git,“智能 http”和“哑 http”。请注意,这包括 https;如果要配置两者,则必须分别进行配置。

  • 任何外部帮助程序都以其协议命名(例如,使用 hg 允许 git-remote-hg 帮助程序)。

protocol.version

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

  • 0 - 原始线协议。

  • 1 - 原始线协议,并在服务器的初始响应中添加了版本字符串。

  • 2 - 线协议版本 2,请参阅 gitprotocol-v2[5]

pull.ff

默认情况下,当合并作为当前提交的后代的提交时,Git 不会创建额外的合并提交。相反,当前分支的顶端将快速转发。当设置为 false 时,此变量告诉 Git 在这种情况下创建额外的合并提交(相当于从命令行提供 --no-ff 选项)。当设置为 only 时,仅允许此类快速转发合并(相当于从命令行提供 --ff-only 选项)。此设置在拉取时会覆盖 merge.ff

pull.rebase

如果为 true,则在运行“git pull”时,将分支重新定位到已获取的分支之上,而不是合并来自默认远程的默认分支。有关在每个分支的基础上设置此选项,请参阅“branch.<name>.rebase”。

当值为 merges(或仅为 m)时,将 --rebase-merges 选项传递给 git rebase,以便将本地合并提交包含在重新定位中(有关详细信息,请参阅 git-rebase[1])。

当值为 interactive(或仅为 i)时,将以交互模式运行重新定位。

注意:这是一个可能很危险的操作;除非您了解其含义,否则不要使用它(有关详细信息,请参阅 git-rebase[1])。

pull.octopus

一次拉取多个分支时要使用的默认合并策略。

pull.twohead

拉取单个分支时要使用的默认合并策略。

push.autoSetupRemote

如果设置为“true”,则在当前分支不存在上游跟踪时,在默认推送时假定 --set-upstream;此选项对 simpleupstreamcurrent 的 push.default 选项有效。如果默认情况下您希望将新分支推送到默认远程(类似于 push.default=current 的行为),并且您还想设置上游跟踪,则此选项很有用。最有可能从此选项中受益的工作流程是所有分支都期望在远程具有相同名称的 simple 中心工作流程。

push.default

定义如果未给出 refspec(无论来自命令行、配置还是其他位置),则 git push 应采取的操作。不同的值非常适合特定的工作流程;例如,在纯中心工作流程中(即获取源等于推送目标),upstream 可能就是您想要的。可能的值为

  • nothing - 除非提供 refspec,否则不推送任何内容(报错)。这主要面向希望通过始终明确操作来避免错误的用户。

  • current - 将当前分支推送到接收端具有相同名称的分支以进行更新。在集中式和非集中式工作流程中均有效。

  • upstream - 将当前分支推回通常将其更改集成到当前分支的分支(称为 @{upstream})。只有在您推送到通常从中拉取的相同存储库时(即集中式工作流程),此模式才有意义。

  • tracking - 这是 upstream 的已弃用同义词。

  • simple - 将当前分支推送到远程具有相同名称的分支。

    如果您正在使用集中式工作流程(推送到您从中拉取的相同存储库,通常是 origin),则需要配置一个具有相同名称的上游分支。

    自 Git 2.0 以来,此模式为默认模式,并且是适合初学者的最安全选项。

  • matching - 推送两端具有相同名称的所有分支。这使得您正在推送到存储库记住将要推送的分支集(例如,如果您始终推送 maintmaster 以及其他分支,则您推送到存储库将具有这两个分支,并且您的本地 maintmaster 将被推送到那里)。

    要有效地使用此模式,您必须确保在运行 git push 之前,您要推送的所有分支都已准备好推送,因为此模式的全部意义在于允许您一次推送所有分支。如果您通常只完成一个分支上的工作并推送结果,而其他分支尚未完成,则此模式不适合您。此外,此模式不适合推送到共享的集中式存储库,因为其他人可能会在那里添加新分支,或在您无法控制的情况下更新现有分支的顶端。

    这曾经是默认值,但自 Git 2.0 以来不再是(simple 是新的默认值)。

push.followTags

如果设置为 true,则默认启用 --follow-tags 选项。您可以在推送时通过指定 --no-follow-tags 来覆盖此配置。

push.gpgSign

可以设置为布尔值或字符串 if-asked。true 值会导致所有推送都进行 GPG 签名,就像将 --signed 传递给 git-push[1] 一样。字符串 if-asked 会在服务器支持的情况下对推送进行签名,就像将 --signed=if-asked 传递给 git push 一样。false 值可能会覆盖来自较低优先级配置文件的值。显式命令行标志始终会覆盖此配置选项。

push.pushOption

当从命令行未给出 --push-option=<option> 参数时,git push 的行为就像将此变量的每个 <value> 作为 --push-option=<value> 给出一样。

这是一个多值变量,可以在较高优先级的配置文件(例如存储库中的 .git/config)中使用空值来清除从较低优先级配置文件(例如 $HOME/.gitconfig)继承的值。

Example:

/etc/gitconfig
  push.pushoption = a
  push.pushoption = b

~/.gitconfig
  push.pushoption = c

repo/.git/config
  push.pushoption =
  push.pushoption = b

This will result in only b (a and c are cleared).
push.recurseSubmodules

可以是 "check"、"on-demand"、"only" 或 "no",其行为与 "push --recurse-submodules" 相同。如果未设置,则默认使用 no,除非设置了 submodule.recurse(在这种情况下,true 值表示 on-demand)。

push.useForceIfIncludes

如果设置为 "true",则等效于在命令行中将 --force-if-includes 指定为 git-push[1] 的选项。在推送时添加 --no-force-if-includes 会覆盖此配置设置。

push.negotiate

如果设置为 "true",则尝试通过协商轮次来减小发送的 packfile 的大小,在协商轮次中,客户端和服务器尝试查找共同的提交。如果为 "false",Git 将仅依赖于服务器的 ref 广告来查找共同的提交。

push.useBitmaps

如果设置为 "false",则即使 pack.useBitmaps 为 "true",也会禁用 "git push" 的位图使用,而不会阻止其他 git 操作使用位图。默认为 true。

rebase.backend

用于变基的默认后端。可能的选项是 applymerge。将来,如果合并后端获得了应用后端的全部剩余功能,则此设置可能会变得未使用。

rebase.stat

是否显示自上次变基以来上游发生更改的 diffstat。默认为 false。

rebase.autoSquash

如果设置为 true,则默认情况下为交互模式启用 git-rebase[1]--autosquash 选项。这可以通过 --no-autosquash 选项覆盖。

rebase.autoStash

设置为 true 时,会在操作开始前自动创建一个临时存储条目,并在操作结束后应用它。这意味着您可以在脏工作树上运行变基。但是,请谨慎使用:成功变基后最终的存储应用可能会导致非平凡的冲突。此选项可以通过 git-rebase[1]--no-autostash--autostash 选项覆盖。默认为 false。

rebase.updateRefs

如果设置为 true,则默认启用 --update-refs 选项。

rebase.missingCommitsCheck

如果设置为 "warn",则 git rebase -i 会在删除一些提交(例如删除一行)时打印警告,但变基仍将继续。如果设置为 "error",则会打印先前的警告并停止变基,然后可以使用 git rebase --edit-todo 来更正错误。如果设置为 "ignore",则不会进行任何检查。要删除提交而不发出警告或错误,请在待办事项列表中使用 drop 命令。默认为 "ignore"。

rebase.instructionFormat

一个格式字符串,如 git-log[1] 中指定,用于交互式变基期间的待办事项列表。格式将自动在格式前加上提交哈希。

rebase.abbreviateCommands

如果设置为 true,则 git rebase 将在待办事项列表中使用缩写命令名称,从而产生如下内容

	p deadbee The oneline of the commit
	p fa1afe1 The oneline of the next commit
	...

而不是

	pick deadbee The oneline of the commit
	pick fa1afe1 The oneline of the next commit
	...

默认为 false。

rebase.rescheduleFailedExec

自动重新安排失败的 exec 命令。这仅在交互模式下(或提供 --exec 选项时)才有意义。这与指定 --reschedule-failed-exec 选项相同。

rebase.forkPoint

如果设置为 false,则默认设置 --no-fork-point 选项。

rebase.rebaseMerges

是否以及如何默认设置 --rebase-merges 选项。可以是 rebase-cousinsno-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-receivepost-receive 中编写检查更容易一些。他们不必检查记录 nonce 过期多少秒的 GIT_PUSH_CERT_NONCE_SLOP 环境变量来决定是否要接受证书,他们只需要检查 GIT_PUSH_CERT_NONCE_STATUS 是否为 OK

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

如果推送接收到的对象数量低于此限制,则这些对象将被解包到松散的对象文件中。但是,如果接收到的对象数量等于或超过此限制,则接收到的包将在添加任何缺少的 delta 基数后存储为包。从推送中存储包可以使推送操作更快地完成,尤其是在文件系统速度较慢的情况下。如果未设置,则使用transfer.unpackLimit的值。

receive.maxInputSize

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

receive.denyDeletes

如果设置为 true,则 git-receive-pack 将拒绝删除 ref 的 ref 更新。使用此选项可通过推送防止此类 ref 删除。

receive.denyDeleteCurrent

如果设置为 true,则 git-receive-pack 将拒绝删除非裸仓库当前签出分支的 ref 更新。

receive.denyCurrentBranch

如果设置为 true 或 "refuse",则 git-receive-pack 将拒绝对非裸仓库当前签出分支的 ref 更新。此类推送可能很危险,因为它会导致 HEAD 与索引和工作树不同步。如果设置为 "warn",则将此类推送的警告打印到 stderr,但允许推送继续。如果设置为 false 或 "ignore",则允许此类推送,且不显示任何消息。默认为 "refuse"。

另一个选项是 "updateInstead",如果推送到的目标是当前分支,它将更新工作树。此选项旨在在一方不容易通过交互式 ssh 访问时(例如,一个实时网站,因此需要工作目录干净)同步工作目录。此模式在虚拟机内部开发以在不同的操作系统上测试和修复代码时也很有用。

默认情况下,如果工作树或索引与 HEAD 存在任何差异,"updateInstead" 将拒绝推送,但可以使用push-to-checkout钩子来自定义此行为。请参阅githooks[5]

receive.denyNonFastForwards

如果设置为 true,则 git-receive-pack 将拒绝不是快进的 ref 更新。使用此选项可通过推送防止此类更新,即使该推送是强制的。初始化共享仓库时会设置此配置变量。

receive.hideRefs

此变量与transfer.hideRefs相同,但仅适用于receive-pack(因此会影响推送,但不会影响获取)。git push尝试更新或删除隐藏的 ref 将被拒绝。

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 接收数据并更新 ref 后运行 git-update-server-info。

receive.shallowUpdate

如果设置为 true,则当新的 ref 需要新的浅根时,可以更新 .git/shallow。否则,将拒绝这些 ref。

reftable.blockSize

reftable 后端在写入块时使用的字节大小。块大小由写入器确定,不一定是 2 的幂。块大小必须大于存储库中使用的最长引用名称或日志条目,因为引用不能跨越块。

建议使用对虚拟内存系统或文件系统友好的 2 的幂(例如 4kB 或 8kB)。更大的尺寸(64kB)可以产生更好的压缩,但读者在访问期间可能会产生更高的成本。

最大的块大小为16777215字节(15.99 MiB)。默认值为4096字节(4kB)。值为0将使用默认值。

reftable.restartInterval

创建重启点的间隔。reftable 后端在文件创建时确定重启点。对于较小的块大小(4k 或 8k),每 16 个可能更合适,对于较大的块大小(64k),每 64 个更合适。

更频繁的重启点会减少前缀压缩并增加重启表占用的空间,这两者都会增加文件大小。

更不频繁的重启点使前缀压缩更有效,减少总体文件大小,但在二分查找步骤之后,读者遍历更多记录的代价会增加。

每个块最多支持65535个重启点。

默认值是每 16 条记录创建一个重启点。值为0将使用默认值。

reftable.indexObjects

reftable 后端是否应写入对象块。对象块是对象 ID 到指向它们的引用的反向映射。

默认值为true

reftable.geometricFactor

每当 reftable 后端将新表附加到堆栈时,它都会执行自动压缩以确保只有少量表。后端通过确保表在每个表的相应大小方面形成一个几何序列来做到这一点。

默认情况下,几何序列使用因子 2,这意味着对于任何表,下一个最大的表必须至少是其两倍大。最大支持因子为 256。

reftable.lockTimeout

每当 reftable 后端将新表附加到堆栈时,它都必须在更新中央 "tables.list" 文件之前锁定它。此配置控制如果另一个进程已获取锁,则该进程将等待多长时间才能获取锁。值 0 表示根本不重试;-1 表示无限期重试。默认为 100(即,重试 100 毫秒)。

remote.pushDefault

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

remote.<name>.url

远程仓库的 URL。请参阅git-fetch[1]git-push[1]。配置的远程仓库可以有多个 URL;在这种情况下,第一个用于获取,所有 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>.prunefetch.prune--prune在一般情况下启用了修剪。如果存在,则覆盖fetch.pruneTags设置。

另请参阅remote.<name>.prunegit-fetch[1]的修剪部分。

remote.<name>.promisor

当设置为 true 时,此远程仓库将用于获取承诺者对象。

remote.<name>.partialclonefilter

从该承诺者远程仓库获取时将应用的过滤器。更改或清除此值只会影响新提交的获取。要获取已存在于本地对象数据库中的提交关联的对象,请使用 git-fetch[1]--refetch 选项。

remotes.<group>

"git remote update <group>" 获取的远程仓库列表。请参阅 git-remote[1]

repack.useDeltaBaseOffset

默认情况下,git-repack[1] 创建使用 delta-base 偏移量的包。如果您需要与低于 1.4.4 版本的 Git 共享您的仓库(无论是直接共享还是通过 http 等哑协议共享),则需要将此选项设置为 "false" 并重新打包。通过原生协议访问旧版 Git 不受此选项影响。

repack.packKeptObjects

如果设置为 true,则使 git repack 的行为如同传递了 --pack-kept-objects。有关详细信息,请参阅 git-repack[1]。通常默认为 false,但如果正在写入位图索引(通过 --write-bitmap-indexrepack.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] 使用的参数,并且未在命令行上给出相应的参数。有关默认值和含义,请参阅类似命名的 pack.* 配置变量。

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 与所有裸仓库交互。这是默认值。

  • explicit:Git 仅与通过顶级 --git-dir 命令行选项或 GIT_DIR 环境变量指定的裸仓库交互(请参阅 git[1])。

    如果您在工作流程中不使用裸仓库,那么在全局配置中将 safe.bareRepository 设置为 explicit 可能会有益。这将保护您免受涉及克隆包含裸仓库的仓库并在该目录中运行 Git 命令的攻击。

    此配置设置仅在受保护的配置中受尊重(请参阅 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 环境变量,并且除了 root 的 id 之外,还允许访问其值中记录的 uid。这样做是为了简化安装期间的常见序列“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-certificates 的路径(目录或单个文件)。将其设置为空字符串以禁用证书验证。

sendemail.<identity>.*

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

sendemail.multiEdit

如果为 true(默认值),则将生成一个编辑器实例来编辑您必须编辑的文件(使用 --annotate 时为补丁,使用 --compose 时为摘要)。如果为 false,则将依次编辑文件,每次生成一个新的编辑器。

sendemail.confirm

设置发送前是否确认的默认值。必须是 alwaysnevercccomposeauto 之一。有关这些值的含义,请参阅 git-send-email[1] 文档中的 --confirm

sendemail.mailmap

如果为 true,则使 git-send-email[1] 假设 --mailmap,否则假设 --no-mailmap。默认为 false。

sendemail.mailmap.file

特定于 git-send-email[1] 的增强邮件映射文件的路径。首先加载默认邮件映射和 mailmap.file。因此,此文件中的条目优先于默认邮件映射位置中的条目。请参阅 gitmailmap[5]

sendemail.mailmap.blob

类似于 sendemail.mailmap.file,但将值视为对仓库中 blob 的引用。sendemail.mailmap.file 中的条目优先于此处的条目。请参阅 gitmailmap[5]

sendemail.aliasesFile

要避免键入长的电子邮件地址,请将其指向一个或多个电子邮件别名文件。您还必须提供 sendemail.aliasFileType

sendemail.aliasFileType

sendemail.aliasesFile 中指定的文件的格式。必须是 muttmailrcpineelmgnussendmail 之一。

每种格式的别名文件的外观可以在同名电子邮件程序的文档中找到。标准格式的差异和限制在下面描述

sendmail
  • 不支持带引号的别名和带引号的地址:包含 " 符号的行将被忽略。

  • 不支持重定向到文件(/path/name)或管道(|command)。

  • 不支持文件包含(:include: /path/name)。

  • 对于任何明确不支持的结构以及解析器无法识别的任何其他行,都会在标准错误输出上打印警告。

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.thread
sendemail.transferEncoding
sendemail.validate
sendemail.xmailer

这些配置变量都为 git-send-email[1] 命令行选项提供默认值。有关详细信息,请参阅其文档。

sendemail.signedOffCc(已弃用)

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 使用时由 shell 解释。它可以通过 GIT_SEQUENCE_EDITOR 环境变量覆盖。如果未配置,则使用默认的提交消息编辑器。

showBranch.default

git-show-branch[1] 的默认分支集。请参阅 git-show-branch[1]

sparse.expectFilesOutsideOfPatterns

通常情况下,使用稀疏检出时,与任何稀疏模式都不匹配的文件将在索引中标记为 SKIP_WORKTREE 位,并且在工作树中不存在。因此,Git 通常会检查是否确实存在工作树中具有 SKIP_WORKTREE 位的文件,这与预期不符。如果 Git 找到任何文件,它会通过清除相关的 SKIP_WORKTREE 位来标记这些路径为存在。此选项可用于告诉 Git 预期存在这些尽管已跳过但仍然存在的文件,并停止检查它们。

默认值为 false,这允许 Git 自动从索引和工作树中文件列表不同步的状态中恢复。

如果您的设置中存在某些外部因素使 Git 免于维护工作树文件的存在和稀疏模式之间的一致性,请将其设置为 true。例如,如果您有一个 Git 感知的虚拟文件系统,该系统具有强大的机制,可以根据访问模式保持工作树和稀疏模式的最新状态。

无论此设置如何,除非启用稀疏检出,否则 Git 不会检查尽管已跳过但仍然存在的文件,因此,除非 core.sparseCheckouttrue,否则此配置选项无效。

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_SSHGIT_SSH_COMMAND 或配置设置 core.sshCommand 配置)的基名确定要使用的命令行参数。如果基名无法识别,Git 将尝试通过首先使用 -G(打印配置)选项调用配置的 SSH 命令来检测 OpenSSH 选项的支持,并且随后将使用 OpenSSH 选项(如果成功)或除了主机和远程命令之外没有其他选项(如果失败)。

配置变量 ssh.variant 可以设置为覆盖此检测。有效值为 ssh(使用 OpenSSH 选项)、plinkputtytortoiseplinksimple(除了主机和远程命令之外没有其他选项)。可以使用值 auto 显式请求默认的自动检测。任何其他值都将被视为 ssh。此设置也可以通过环境变量 GIT_SSH_VARIANT 覆盖。

每个变体当前使用的命令行参数如下所示

  • ssh - [-p port] [-4] [-6] [-o option] [username@]host command

  • simple - [username@]host command

  • plinkputty - [-P port] [-4] [-6] [username@]host command

  • tortoiseplink - [-P port] [-4] [-6] -batch [username@]host command

除了 simple 变体之外,命令行参数可能会随着 git 获得新功能而发生变化。

stash.showIncludeUntracked

如果将其设置为 true,则 git stash show 命令将显示存储条目未跟踪的文件。默认为 false。请参阅 git-stash[1]show 命令的说明。

stash.showPatch

如果将其设置为 true,则没有选项的 git stash show 命令将以补丁形式显示存储条目。默认为 false。请参阅 git-stash[1]show 命令的说明。

stash.showStat

如果将其设置为 true,则没有选项的 git stash show 命令将显示存储条目的 diffstat。默认为 true。请参阅 git-stash[1]show 命令的说明。

status.relativePaths

默认情况下,git-status[1] 显示相对于当前目录的路径。将此变量设置为 false 将显示相对于存储库根目录的路径(这是 Git 在 v1.5.4 之前的默认设置)。

status.short

设置为 true 以在 git-status[1] 中默认启用 --short。选项 --no-short 优先于此变量。

status.branch

设置为 true 以在 git-status[1] 中默认启用 --branch。选项 --no-branch 优先于此变量。

status.aheadBehind

设置为 true 以在 git-status[1] 中为非瓷器状态格式默认启用 --ahead-behind,并设置为 false 以启用 --no-ahead-behind。默认为 true。

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() 整个存储库中的所有文件,这在某些系统上可能会很慢。因此,此变量控制命令如何显示未跟踪的文件。可能的值为

  • no - 不显示未跟踪的文件。

  • normal - 显示未跟踪的文件和目录。

  • all - 还显示未跟踪目录中的单个文件。

如果未指定此变量,则默认为 normal。布尔值 true 的所有常用拼写都被视为 normalfalse 被视为 no。此变量可以通过 git-status[1]git-commit[1] 的 -u|--untracked-files 选项覆盖。

status.submoduleSummary

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

submodule.<name>.url

子模块的 URL。此变量从 .gitmodules 文件复制到 git 配置中,方法是使用 git submodule init。用户可以在通过 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.activepull.rebase 等设置更具体。它由 git submodule initgitmodules[5] 文件填充。有关 update 命令的说明,请参阅 git-submodule[1]

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" 时,它永远不会被视为已修改(但当它已暂存时,它仍将在 status 和 commit 的输出中显示),"dirty" 将忽略对子模块工作树的所有更改,只考虑子模块的 HEAD 与上游项目中记录的提交之间的差异。"untracked" 还会让其工作树中修改了跟踪文件的子模块显示出来。使用 "none"(未设置此选项时的默认值)还会将工作树中包含未跟踪文件的子模块显示为已更改。此设置会覆盖为该子模块在 .gitmodules 中进行的任何设置,这两个设置都可以在命令行上通过使用 "--ignore-submodules" 选项来覆盖。git submodule 命令不受此设置的影响。

submodule.<name>.active

布尔值,指示子模块是否与 git 命令相关。此配置选项优先于 submodule.active 配置选项。有关详细信息,请参阅 gitsubmodules[7]

submodule.active

一个重复字段,其中包含一个路径规范,用于匹配子模块的路径,以确定子模块是否与 git 命令相关。有关详细信息,请参阅 gitsubmodules[7]

submodule.recurse

一个布尔值,指示命令是否应默认启用 --recurse-submodules 选项。默认为 false。

当设置为 true 时,可以通过 --no-recurse-submodules 选项停用它。请注意,某些缺少此选项的 Git 命令可能会调用受 submodule.recurse 影响的上述某些命令;例如 git remote update 将调用 git fetch 但没有 --no-recurse-submodules 选项。对于这些命令,解决方法是使用 git -c submodule.recurse=0 临时更改配置值。

以下列表显示了接受 --recurse-submodules 的命令以及此设置是否支持它们。

  • checkoutfetchgreppullpushread-treeresetrestoreswitch 始终受支持。

  • clonels-files 不受支持。

  • 仅当启用 submodule.propagateBranches 时才支持 branch

submodule.propagateBranches

[实验性] 一个布尔值,在使用 --recurse-submodulessubmodule.recurse=true 时启用分支支持。启用此选项将允许某些命令接受 --recurse-submodules,并且某些已经接受 --recurse-submodules 的命令现在将考虑分支。默认为 false。

submodule.fetchJobs

指定同时获取/克隆多少个子模块。正整数允许并行获取最多该数量的子模块。值为 0 将提供一些合理的默认值。如果未设置,则默认为 1。

submodule.alternateLocation

指定子模块在克隆时如何获取备用。可能的值为 nosuperproject。默认情况下假定为 no,它不添加引用。当值设置为 superproject 时,要克隆的子模块将计算其备用位置相对于上游项目的备用位置。

submodule.alternateErrorStrategy

指定如何处理通过 submodule.alternateLocation 计算的子模块的备用错误。可能的值为 ignoreinfodie。默认为 die。请注意,如果设置为 ignoreinfo,并且如果计算的备用存在错误,则克隆将继续进行,就好像没有指定备用一样。

tag.forceSignAnnotated

一个布尔值,用于指定创建的带注释标签是否应进行 GPG 签名。如果在命令行上指定了 --annotate,则它优先于此选项。

tag.sort

此变量控制 git-tag[1] 显示标签时的排序顺序。如果没有提供 “--sort=<value>” 选项,则此变量的值将用作默认值。

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 环境变量覆盖。下表显示了可能的值。

  • 0false - 禁用目标。

  • 1true - 写入 STDERR

  • [2-9] - 写入已打开的文件描述符。

  • <absolute-pathname> - 以追加模式写入文件。如果目标已存在且是目录,则跟踪将写入给定目录下的文件(每个进程一个)。

  • af_unix:[<socket-type>:]<absolute-pathname> - 写入 Unix 域套接字(在支持它们的平台上)。套接字类型可以是 streamdgram;如果省略,Git 将尝试两者。

trace2.normalBrief

布尔值。当为 true 时,timefilenameline 字段将从正常输出中省略。可以被 GIT_TRACE2_BRIEF 环境变量覆盖。默认为 false。

trace2.perfBrief

布尔值。当为 true 时,timefilenameline 字段将从 PERF 输出中省略。可以被 GIT_TRACE2_PERF_BRIEF 环境变量覆盖。默认为 false。

trace2.eventBrief

布尔值。当为 true 时,timefilenameline 字段将从事件输出中省略。可以被 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

布尔值。当为真时,Git 会在无法打开跟踪目标目的地进行写入时打印错误消息。默认情况下,这些错误会被抑制,并且跟踪会被静默禁用。可以被 GIT_TRACE2_DST_DEBUG 环境变量覆盖。

trace2.maxFiles

整数。当将跟踪文件写入目标目录时,如果这样做会导致文件数量超过此值,则不要写入额外的跟踪信息。相反,写入一个哨兵文件,阻止对此目录的进一步跟踪。默认为 0,禁用此检查。

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.fsckObjectsreceive.fsckObjects 时,将使用此变量的值。默认为 false。

当设置此选项时,如果遇到格式错误的对象或指向不存在对象的链接,则 fetch 或 receive 将中止。此外,还会检查各种其他问题,包括遗留问题(请参阅 fsck.<msg-id>)以及潜在的安全问题,例如 .GIT 目录的存在或恶意的 .gitmodules 文件(有关详细信息,请参阅 v2.2.1 和 v2.17.1 的发行说明)。在将来的版本中可能会添加其他健全性和安全检查。

在接收端,如果 fsckObjects 失败,则这些对象将无法访问,请参阅 git-receive-pack[1] 中的“隔离环境”。在 fetch 端,格式错误的对象将保留在存储库中,但不会被引用。

由于 fetch.fsckObjects 实现的非隔离特性,无法依赖它像 receive.fsckObjects 一样清理对象存储。

在解包对象时,它们会被写入对象存储,因此可能存在即使“fetch”失败但恶意对象仍被引入的情况,只是后续的“fetch”成功,因为仅检查新的传入对象,而不检查已写入对象存储的对象。不应依赖这种行为差异。将来,此类对象也可能被隔离用于“fetch”。

目前,如果希望获得与“push”相同的保护,则偏执的用户需要找到某种方法来模拟隔离环境。例如,在内部镜像的情况下,分两步进行镜像,一步获取不受信任的对象,然后执行第二次“push”(这将使用隔离)到另一个内部存储库,并让内部客户端使用此推送到存储库,或者禁止内部 fetch 并仅在运行完整的“fsck”(并且在此期间没有发生新的 fetch)后才允许它们。

transfer.hideRefs

字符串。receive-packupload-pack 用于决定从其初始广告中省略哪些引用。使用多个定义来指定多个前缀字符串。在此变量的值中列出的层次结构下的引用会被排除,并且在响应 git pushgit fetch 时会被隐藏。有关此配置的特定于程序的版本,请参阅 receive.hideRefsuploadpack.hideRefs

您还可以包含一个 ! 在引用名称前面以否定该条目,即使较早的条目将其标记为隐藏,也明确地公开它。如果您有多个 hideRefs 值,则后面的条目会覆盖前面的条目(更具体的配置文件中的条目会覆盖不太具体的条目)。

如果正在使用命名空间,则在将每个引用与 transfer.hiderefs 模式匹配之前,会从该引用中剥离命名空间前缀。为了在剥离之前匹配引用,请在引用名称前面添加一个 ^。如果您组合使用 !^,则必须先指定 !

例如,如果 refs/heads/mastertransfer.hideRefs 中指定,并且当前命名空间为 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.unpackLimitreceive.unpackLimit 时,将使用此变量的值。默认值为 100。

transfer.advertiseSID

布尔值。当为真时,客户端和服务器进程会将其唯一的会话 ID 公告给远程对应方。默认为 false。

transfer.bundleURI

当为 true 时,本地 git clone 命令将向远程服务器请求捆绑信息(如果已公告)并在继续通过 Git 协议克隆之前下载捆绑包。默认为 false

transfer.advertiseObjectInfo

当为 true 时,服务器会公布 object-info 功能。默认为 false。

uploadarchive.allowUnreachable

如果为真,则允许客户端使用 git archive --remote 请求任何树,无论它是否可以从 ref 提示符访问。有关更多详细信息,请参阅 git-upload-archive[1] 的“安全”部分中的讨论。默认为 false

uploadpack.hideRefs

此变量与 transfer.hideRefs 相同,但仅适用于 upload-pack(因此仅影响 fetch,而不影响 push)。git fetch 尝试获取隐藏的引用将失败。另请参阅 uploadpack.allowTipSHA1InWant

uploadpack.allowTipSHA1InWant

uploadpack.hideRefs 生效时,允许 upload-pack 接受请求隐藏引用顶端对象的 fetch 请求(默认情况下,此类请求会被拒绝)。另请参阅 uploadpack.hideRefs。即使此值为 false,客户端也可能能够通过 gitnamespaces[7] 手册页的“安全”部分中描述的技术来窃取对象;最好将私有数据保存在单独的存储库中。

uploadpack.allowReachableSHA1InWant

允许 upload-pack 接受请求从任何 ref 提示符可访问的对象的 fetch 请求。但是,请注意,计算对象可访问性在计算上代价很高。默认为 false。即使此值为 false,客户端也可能能够通过 gitnamespaces[7] 手册页的“安全”部分中描述的技术来窃取对象;最好将私有数据保存在单独的存储库中。

uploadpack.allowAnySHA1InWant

允许 upload-pack 接受请求任何对象的 fetch 请求。默认为 false

uploadpack.keepAlive

upload-pack 启动 pack-objects 时,在 pack-objects 准备打包时可能会有一个静默期。通常它会输出进度信息,但是如果为 fetch 使用了 --quiet,则 pack-objects 在打包数据开始之前完全不会输出任何内容。某些客户端和网络可能会认为服务器已挂起并放弃。设置此选项指示 upload-packuploadpack.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:noneblob:limitobject:typetreesparse:oidcombine。如果使用组合过滤器,则必须允许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.nameuser.email变量决定了提交对象中的authorcommitter字段最终包含的内容。如果您需要authorcommitter不同,则可以设置author.nameauthor.emailcommitter.namecommitter.email变量。所有这些都可以被GIT_AUTHOR_NAMEGIT_AUTHOR_EMAILGIT_COMMITTER_NAMEGIT_COMMITTER_EMAILEMAIL环境变量覆盖。

请注意,这些变量的name形式通常指的是某种个人姓名。有关这些设置的更多信息,请参阅git-commit[1]git[1]的环境变量部分,如果您正在寻找身份验证凭据,请参阅credential.username选项。

user.useConfigOnly

指示 Git 避免尝试猜测user.emailuser.name的默认值,而是仅从配置中检索这些值。例如,如果您有多个电子邮件地址,并且希望为每个存储库使用不同的电子邮件地址,那么通过在全局配置中将此配置选项设置为true以及一个名称,Git 将提示您在对新克隆的存储库进行新的提交之前设置电子邮件。默认为false

user.signingKey

如果git-tag[1]git-commit[1]在创建签名标签或提交时没有自动选择您想要的密钥,您可以使用此变量覆盖默认选择。此选项会原样传递给 gpg 的 --local-user 参数,因此您可以使用 gpg 支持的任何方法指定密钥。如果 gpg.format 设置为ssh,则可以包含您的私有 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(已弃用)

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会尝试查找其名称与新分支名称唯一匹配的远程跟踪分支。如果存在这样的分支,则将其检出并设置为新分支的“上游”。如果找不到这样的匹配项,则将回退到从当前 HEAD 创建一个新分支。

错误

使用已弃用的[section.subsection]语法时,如果子部分至少包含一个大写字符,则更改值将导致添加多行键而不是更改。例如,当配置如下所示时

  [section.subsection]
    key = value1

运行git config section.Subsection.key value2将导致

  [section.subsection]
    key = value1
    key = value2

Git

git[1]套件的一部分

scroll-to-top