Git 中文参考（一）（4）

Git 中文参考（一）（3）https://developer.aliyun.com/article/1565872

示例

# 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

值

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

boolean 

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

true 

字面意思是yes，on，true和1。此外，变量没有定义= 的话，默认值是 true。

false 

字面意思是no，off，false，0和空字符串。

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

integer 

指定各种大小的许多变量的值可以后缀为k，M，表示“将数字扩大 1024 倍”，“1024x1024 倍”等。

color 

采用颜色的变量的值是一个颜色列表（最多两个，一个用于前景，一个用于背景）和属性（多个您想要的），用空格分隔。

接受的基本颜色是normal，black，red，green，yellow，blue，magenta，cyan和white。给出的第一种颜色是前景，第二是背景。

颜色也可以作为 0 到 255 之间的数字给出，这些使用 ANSI 256 色模式（但请注意，并非所有终端都支持此功能）。如果您的终端支持它，您也可以将 24 位 RGB 值指定为十六进制，如#ff0ab3。

接受的属性有bold，dim，ul，blink，reverse，italic和strike（用于划掉或“删除”字母）。任何属性相对于颜色（之前，之后或之间）的位置都无关紧要。可以通过在前缀no或no-（例如，noreverse，no-ul等）来关闭特定属性。

空颜色字符串根本不产生颜色效果。这可用于避免在不完全禁用颜色的情况下着色特定元素。

对于 git 的预定义颜色槽，属性应在彩色输出中每个项目的开头重置。因此，将color.decorate.branch设置为black将在普通black中绘制该分支名称，即使同一输出行上的前一项（例如log --decorate输出中的分支名称列表前的左括号）设置为被涂上bold或其他一些属性。但是，自定义日志格式可能会执行更复杂和分层的着色，而否定的格式在那里可能会有用。

pathname 

获取路径名值的变量可以被赋予以“~/”或“~user/”开头的字符串，并且通常的波浪号扩展发生在这样的字符串中：~/扩展为$HOME的值，~user/为指定用户的根目录。

变量

请注意，此列表不全面，不一定完整。对于特定于命令的变量，您可以在相应的手册页中找到更详细的说明。

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

advice.* 

这些变量控制旨在帮助新用户的各种可选帮助消息。所有 advice.* 变量默认为 true，你可以通过将这些设置为false告诉 Git 你不需要帮助：

pushUpdateRejected 

如果要同时禁用 pushNonFFCurrent，pushNonFFMatching ， pushAlreadyExists ，和 pushFetchFirst，和 pushNeedsForce 变量，请将此变量设置为 false。

pushNonFFCurrent 

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

pushNonFFMatching 

当您运行 git-push [1] 并显式推送 _ 匹配 refs_ 时显示的建议（即您使用 ：，或指定了不是您当前的 refspe 分支）并导致非快进错误。

pushAlreadyExists 

当 git-push [1] 拒绝不符合快进条件的更新（例如，标签）时显示。

pushFetchFirst 

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

pushNeedsForce 

当 git-push [1] 拒绝尝试覆盖指向不是 commit-ish 的对象的远程 ref 的更新时，或者在不是 commit-ish 的对象上进行远程 ref 操作。

pushUnqualifiedRefname 

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

statusHints 

在 git-commit [1] 中写入提交消息时显示的模板中显示如何从 git-status [1] 的输出中的当前状态开始的指示，以及切换分支时，git-checkout [1] 显示的帮助信息。

statusUoption 

建议考虑在 git-status [1] 中使用-u选项，当命令需要超过 2 秒来枚举未跟踪文件时。

commitBeforeMerge 

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

resetQuiet 

建议考虑在 git-reset [1] 中使用--quiet选项，当命令需要 2 秒以上的时间来枚举复位后的非分段更改时。

resolveConflict 

当冲突阻止执行操作时，各种命令显示的建议。

implicitIdentity 

在从系统用户名和域名中猜出您的信息时，如何设置身份配置的建议。

detachedHead 

使用 git-checkout [1] 移动到分离 HEAD 状态时显示的建议，以指示如何在事后创建本地分支。

checkoutAmbiguousRemoteBranchName

当 git-checkout [1] 的参数，在有多个远端的场景下，模糊地解析为远程跟踪分支时，如果明确的参数会导致远程跟踪分支被检出，则显示建议。请参阅checkout.defaultRemote配置变量，如何在给定远端的某些场景下使用。

amWorkDir 

当 git-am [1] 无法应用时，显示补丁文件位置的建议。

rmHints 

如果 git-rm [1] 的输出失败，请显示如何从当前状态开始的指示。

addEmbeddedRepo 

当你意外地在另一个内部添加一个 git repo 时该怎么做的建议。

ignoredHook 

如果钩子被忽略，则显示建议，因为钩子未设置为可执行文件。

waitingForEditor 

只要 Git 正在等待用户的编辑输入，就将消息打印到终端。

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）如果为 true，将标记新创建的、以点开头的命名的目录和文件为隐藏。如果 dotGitOnly ，则只隐藏.git/目录，但没有其他以点开头的文件。默认模式为 dotGitOnly 。

core.ignoreCase 

内部变量，支持各种变通方法，使 Git 能够更好地处理不区分大小写的文件系统，如 APFS，HFS +，FAT，NTFS  等。例如，如果要在某个目录列表下找出“makefile”文件，Git 会将“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 之间共享存储库时，这非常有用。（需要适用于  Windows 1.7.10 或更高版本的 Git，或者在 cygwin 1.7 下使用 Git）。如果为 false，则 Git  会完全透明文件名，后者与旧版本的 Git 向后兼容。

core.protectHFS 

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

core.protectNTFS 

如果设置为 true，则不允许签出可能导致 NTFS 文件系统出现问题的路径，例如：与 8.3“short”冲突的名称。在 Windows 上默认为true，在其他地方默认为false。

core.fsmonitor

如果设置，则此变量的值将用作命令，该命令将标识自请求的日期/时间以来可能已更改的所有文件。此信息用于通过避免对未更改的文件进行不必要的处理来加速 git 操作。请参阅 githooks [5] 的“fsmonitor-watchman”部分。

core.trustctime 

如果为 false，则忽略索引与工作树之间的 ctime 差异；当 inode 更改时间被 Git 之外的某些东西（文件系统爬虫和一些备份系统）定期修改时，将非常有用。参见 git-update-index [1] 。默认为 True。

core.splitIndex 

如果为 true，则将使用索引的拆分索引功能。参见 git-update-index [1] 。默认为 False。

core.untrackedCache 

确定如何处理索引的未跟踪缓存功能。如果未设置此变量或将其设置为keep，则将保留该值。如果设置为true，将自动添加。如果设置为false，它将自动删除。在将其设置为true之前，您应该检查 mtime 是否在您的系统上正常工作。参见 git-update-index [1] 。 keep默认情况下。

core.checkStat 

当缺失或设置为default时，将检查 stat 结构中的许多字段以检测文件是否已被修改，因为 Git 查看了它。当此配置变量设置为minimal时，mtime 和 ctime 的亚秒部分，文件所有者的 uid 和 gid，inode 编号（以及设备编号，如果 Git 编译为使用它），从这些字段中的检查中排除，只留下 mtime 的整个第二部分（和 ctime，如果设置了core.trustCtime）和要检查的文件大小。

Git 的实现不会在某些字段中留下可用的值（例如 JGit）;通过从比较中排除这些字段，当同个仓库在被其他系统使用时，minimal模式可以帮助实现互操作性。

core.quotePath 

输出路径的命令（例如 ls-files ， diff ）将在路径名中引用“异常”字符，方法是将路径名括在双引号中并使用反斜杠转义那些字符。和在 C 语言中转义控制字符（例如 TAB 为\t，LF 为\n，反斜杠为\\）或值大于 0x80 的字节（例如，UTF-8 中为“micro”的八进制\302\265）使用的同样的方法。如果此变量设置为 false，则高于 0x80 的字节不再被视为“异常”。无论此变量的设置如何，双引号，反斜杠和控制字符始终都会被转义。简单的空格字符不被视为“不寻常”。许多命令可以使用-z选项完全逐字输出路径名。默认值是 true。

core.eol 

设置要在工作目录中用于标记为文本的文件的行结束类型（通过设置text属性，或者使text=auto和 Git 自动检测内容为文本）。替代品是 lf ， crlf 和 native，它使用平台的原生的行结束符。默认值为native。有关行尾转换的更多信息，请参见 gitattributes [5] 。请注意，如果core.autocrlf设置为true或input，则忽略该值。

core.safecrlf 

如果为 true，则当行结束转换处于活动状态时，使 Git 检查转换CRLF是否可逆。 Git 将验证命令是直接还是间接修改工作树中的文件。例如，提交文件后检出同一文件应该会在工作树中生成原始文件。如果core.autocrlf的当前设置不是这种情况，Git 将拒绝该文件。该变量可以设置为“警告”，在这种情况下，Git 只会警告不可逆转换，但继续操作。

CRLF 转换有可能破坏数据。启用时，Git 会在提交期间将 CRLF 转换为 LF，在检出时将 LF 转换为 CRLF。 Git  无法重新创建提交之前包含 LF 和 CRLF 混合的文件。对于文本文件，正确的做法是：它校正行结尾符，这样我们在存储库中只有 LF  行结尾。但对于意外归类为文本的二进制文件，转换可能会破坏数据。

如果您提前识别出此类损坏，则可以通过在.gitattributes 中明确设置转换类型来轻松解决此问题。提交后，您仍然在工作树中保留原始文件，此文件尚未损坏。你可以明确告诉 Git 这个文件是二进制文件，Git 会适当地处理文件。

不幸的是，无法区分清除具有混合行结尾的文本文件和破坏二进制文件的不良影响的期望效果。在这两种情况下，CRLF 都以不可逆转的方式被移除。对于文本文件，这是正确的做法，因为 CRLF 是行结尾，而对于二进制文件，转换 CRLF 会破坏数据。

请注意，此安全检查并不意味着在坚持文件时，将为core.eol和core.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 

逗号和/或空格分隔的编码列表，Git 执行 UTF-8 往返检查它们是否在working-tree-encoding属性中使用（参见 gitattributes [5] ）。默认值为SHIFT-JIS。

core.symlinks 

如果为 false，则将符号链接检出为包含链接文本的小型纯文本。 git-update-index [1] 和 git-add [1] 不会将记录类型更改为常规文件。在 FAT 等不支持符号链接的文件系统上很有用。

默认值为 true，除了 git-clone [1] 或 git-init [1] 将在创建存储库时预测并设置 core.symlinks 为 false。

core.gitProxy 

执行（作为 _ 命令主机端口 _）的“代理命令”，在使用 Git  协议进行更新时，将建立替代与远程服务器的直接连接方式。如果变量值在“COMMAND for  DOMAIN”格式中，则该命令仅应用于以指定域字符串结尾的主机名。该变量可以多次设置并按给定顺序匹配；第一次匹配上就不继续往下匹配了。

可以被GIT_PROXY_COMMAND环境变量覆盖（它总是普遍适用，没有特殊的“for”处理）。

特殊字符串none可用作代理命令，以指定不为给定的域模式使用代理。这对于从代理使用中排除防火墙内的服务器非常有用，同时默认为外部域的公共代理。

core.sshCommand 

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

core.ignoreStat 

如果为 true，Git 将避免使用 lstat（）调用来检测文件是否已更改，方法是为索引和工作树中相同更新的跟踪文件设置“假定未更改”位。

当在 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，则假定此存储库为 bare 并且没有与之关联的工作目录。如果是这种情况，将禁用许多与工作目录相关的命令，例如 git-add [1] 或 git-merge [1] 。

创建存储库时， git-clone [1] 或 git-init [1] 会自动预测此设置。默认情况下，假定以“/.git”结尾的存储库不是 bare（bare=false），而假定所有其他存储库都是 bare（bare=ture）。

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的更新记录到文件“$GIT_DIR/logs/”，方法是附加新旧 SHA-1，日期/时间和更新原因，但仅限于文件存在时。如果此配置变量设置为true，则会自动为分支头创建缺省的“$GIT_DIR/logs/”文件（即在refs/heads/下），远程 ref（即在refs/remotes/下），评论 ref（即在refs/notes/下） ）和符号 ref HEAD。如果设置为always，则会自动为refs/下的任何参考创建缺少的 reflog。

此信息可用于确定“2 天前”分支的提示是什么。

默认情况下，此值在具有与之关联的工作目录的存储库中为 true，默认情况下在空存储库中为 false。

core.repositoryFormatVersion 

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

core.sharedRepository 

当 _ 组 _（或 true ）时，存储库可在组中的多个用户之间共享（确保所有文件和对象都是组内可写的）。当 _ 所有 _（或 _ 世界 _ 或 _ 所有人 _）时，除了可分组之外，所有用户都可以读取存储库。当 umask （或 false ）时，Git 将使用 umask（2）报告的权限。当 0xxx ，其中 0xxx 是八进制数时，存储库中的文件将具有此模式值。 0xxx 将覆盖用户的 umask 值（而其他选项只会覆盖用户的 umask 值的请求部分）。示例： 0660 将对所有者和组进行可读/可写，但其他人无法访问（相当于 _ 组 _，除非 umask 是例如 0022 ） 。 0640 是一个可读取组但不可写入组的存储库。参见 git-init [1] 。默认为 False。

core.warnAmbiguousRefs 

如果为 true，Git 会警告您，如果您传递的引用名称不明确并且可能与存储库中的多个引用相匹配。默认为 True。

core.compression 

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

core.looseCompression 

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

core.packedGitWindowSize 

在单个映射操作中映射到内存的 pack 文件的字节数。设置大的值时，可以允许您的系统更快地处理较少数量的大包文件。设置较小值时，会因调用操作系统内存管理器频繁，而导致对性能产生负面影响，但在访问大量大型文件包时可能会提高性能。

如果在编译时设置 NO_MMAP，则默认值为 1 MiB，否则 32 位平台上为 32 MiB，64 位平台上为 1 GiB。这应该适用于所有用户/操作系统。您可能不需要调整此值。

支持 k ， m 或 g 的通用单位后缀。

core.packedGitLimit 

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

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

支持 k ， m 或 g 的通用单位后缀。

core.deltaBaseCacheLimit 

保留用于缓存可能由多个已分层对象引用的基础对象的最大字节数。通过将整个解压缩的基础对象存储在高速缓存中，Git 能够避免多次解包和解压缩经常使用的基础对象。

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

支持 k ， m 或 g 的通用单位后缀。

core.bigFileThreshold 

大于此大小的文件将直接存储，而不会尝试增量压缩。在没有增量压缩的情况下存储大型文件可以避免过多的内存使用，但会增加磁盘使用量。此外，大于此大小的文件始终被视为二进制文件。

所有平台上的默认值为 512 MiB。对于大多数项目来说这应该是合理的，因为源代码和其他文本文件仍然可以进行增量压缩，但是更大的二进制媒体文件不会。

支持 k ， m 或 g 的通用单位后缀。

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 

当此值被设置时，并且未设置环境变量GIT_EDITOR，在执行类似commit和tag等命令时，允许您通过启动编辑器编辑消息。见 git-var [1] 。

core.commentChar

在执行类似commit和tag等命令时，会在编辑消息的开头的添加设置的字符，并在编辑器退出后删除它们（默认 ＃）。

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

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 根本不会更改它）。如果您想有选择地覆盖LESS的 Git 默认设置，您可以将core.pager设置为例如less -S。这将由 Git 传递给 shell，它将最终命令转换为LESS=FRX less -S。环境不设置S选项，但命令行会设置，指示较少截断长行。同样，将core.pager设置为less -+F将从命令行取消激活环境指定的F选项，取消激活less的“退出，如果一个屏幕”行为。可以专门为特定命令激活一些标志：例如，将pager.blame设置为less -S只能为git blame启用行截断。

同样，当未设置LV环境变量时，Git 将其设置为-c。您可以通过将LV导出为其他值或将core.pager设置为lv +c来覆盖此设置。

core.whitespace 

要注意一系列以逗号分隔的常见空格问题。 git diff 将使用color.diff.whitespace突出显示它们， git apply --whitespace = error 会将它们视为错误。您可以为-添加前缀以禁用其中任何一个（例如-trailing-space）：

• blank-at-eol将行末尾的尾随空格视为错误（默认情况下启用）。
  
• space-before-tab将在行的初始缩进部分中的制表符之前出现的空格字符视为错误（默认情况下启用）。
  
• indent-with-non-tab将带有空格字符而不是等效选项卡缩进的行视为错误（默认情况下不启用）。
  
• tab-in-indent将行的初始缩进部分中的制表符视为错误（默认情况下不启用）。
  
• blank-at-eof将在文件末尾添加的空行视为错误（默认情况下启用）。
  
• trailing-space是涵盖blank-at-eol和blank-at-eof的简写。
  
• cr-at-eol将行尾处的回车处理作为行终止符的一部分，即使用它，如果此回车符之前的字符不是空格（默认情况下未启用），则trailing-space不会触发。
  
• tabwidth=告诉标签占用多少个字符位置;这与indent-with-non-tab和 Git 修复tab-in-indent错误有关。默认选项卡宽度为 8.允许的值为 1 到 63。
  

core.fsyncObjectFiles 

在编写目标文件时，此布尔值将启用 fsync（）。

这对于正确排序数据的文件系统来说是浪费时间和精力的，但对于不使用日志（传统 UNIX 文件系统）或仅使用日志元数据而不是文件内容（OS X 的 HFS+或 Linux）的文件系统非常有用。 ext3 带有“data = writeback”）。

core.preloadIndex 

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

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

core.unsetenvvars 

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

core.createObject 

您可以将其设置为 link ，在这种情况下，使用硬链接后删除源来确保对象创建不会覆盖现有对象。

在某些文件系统/操作系统组合上，这是不可靠的。将此配置设置为 rename；但是，这将删除检查，以确保不会覆盖现有的目标文件。

core.notesRef 

显示提交消息时，还会显示存储在给定引用中的注释。ref 必须完全合格。如果给定的 ref 不存在，则不是错误，而是表示不应打印任何注释。

此设置默认为“refs/notes/commits”，它可以被GIT_NOTES_REF环境变量覆盖。见 git-notes [1] 。

core.commitGraph 

如果为 true，则 git 将读取 commit-graph 文件（如果存在）以解析提交的图形结构。默认为 false。有关详细信息，请参阅 git-commit-graph [1] 。

core.useReplaceRefs 

如果设置为false，则表现为在命令行上给出了--no-replace-objects选项。有关详细信息，请参阅 git [1] 和 git-replace [1] 。

core.multiPackIndex 

Git 中文参考（一）（5）https://developer.aliyun.com/article/1565874