Git 中文参考（一）（8）

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

如果为 true，则等效于–verify-signatures 命令行选项。有关详细信息，请参阅 git-merge [1] 。

merge.branchdesc 

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

merge.log 

除了分支名称之外，还要从正在合并的实际提交中填充最多具有指定数量的单行描述的日志消息。默认为 false，true 是 20 的同义词。

merge.renameLimit 

合并期间执行重命名检测时要考虑的文件数;如果未指定，则默认为 diff.renameLimit 的值。如果关闭重命名检测，此设置无效。

merge.renames 

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

merge.renormalize 

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

merge.stat 

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

merge.tool 

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

merge.guitool 

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

• araxis
  
• bc
  
• BC3
  
• codecompare
  
• deltawalker
  
• diffmerge
  
• diffuse
  
• ecmerge
  
• emerge
  
• examdiff
  
• guiffy
  
• gvimdiff
  
• gvimdiff2
  
• gvimdiff3
  
• kdiff3
  
• meld
  
• opendiff
  
• p4merge
  
• tkdiff
  
• tortoisemerge
  
• vimdiff
  
• vimdiff2
  
• vimdiff3
  
• 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>.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.keepBackup 

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

mergetool.keepTemporaries 

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

mergetool.writeToTemp 

Git 默认在工作树中写入临时 BASE ， LOCAL 和 REMOTE 版本的冲突文件。设置true时，Git 将尝试为这些文件使用临时目录。默认为false。

mergetool.prompt 

在每次调用合并解决方案之前提示。

notes.mergeStrategy 

在解决笔记冲突时默认选择哪种合并策略。必须是manual，ours，theirs，union或cat_sort_uniq中的一个。默认为manual。有关每种策略的更多信息，请参阅 git-notes [1] 的“NOTES MERGE STRATEGIES”部分。

notes.<name>.mergeStrategy 

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

notes.displayRef 

（完全限定的）refname，用于在显示提交消息时显示注释。此变量的值可以设置为 glob，在这种情况下，将显示来自所有匹配引用的注释。您也可以多次指定此配置变量。将为不存在的引用发出警告，但是会自动忽略与任何引用不匹配的 glob。

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

“core.notesRef”的有效值（可能被 GIT_NOTES_REF 覆盖）也隐式添加到要显示的引用列表中。

notes.rewrite.<command>

使用重写提交时（当前amend或rebase）并且此变量设置为true，Git 会自动将您的笔记从原始文件复制到重写的提交。默认为true，但请参阅下面的“notes.rewriteRef”。

notes.rewriteMode 

在重写期间复制备注时（请参阅“notes.rewrite.”选项），确定目标提交已有备注时要执行的操作。必须是overwrite，concatenate，cat_sort_uniq或ignore中的一个。默认为concatenate。

可以使用GIT_NOTES_REWRITE_MODE环境变量覆盖此设置。

notes.rewriteRef 

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

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

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

pack.window 

在命令行上没有给出窗口大小时， git-pack-objects [1] 使用的窗口大小。默认为 10。

pack.depth 

当命令行没有给出最大深度时， git-pack-objects [1] 使用的最大增量深度。默认为 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.island 

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

pack.islandCore 

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

pack.deltaCacheSize 

在将它们写入包之前，用于缓存 git-pack-objects [1]  中的增量的最大内存字节数。此缓存用于加速写入对象阶段，一旦找到所有对象的最佳匹配，就不必重新计算最终的增量结果。尽管如此，在内存紧张的计算机上重新打包大型存储库可能会受到严重影响，特别是如果此缓存将系统推送到交换中。值为  0 表示没有限制。可以使用 1 字节的最小大小来虚拟地禁用该高速缓存。默认为 256 MiB。

pack.deltaCacheLimit 

在 git-pack-objects [1] 中缓存的 delta 的最大大小。此缓存用于加速写入对象阶段，一旦找到所有对象的最佳匹配，就不必重新计算最终的增量结果。默认为 1000.最大值为 65535。

pack.threads

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

pack.indexVersion 

指定默认包索引版本。对于 1.5.2 之前的 Git 版本使用的旧版程序包索引，有效值为 1;对于具有大于 4 GB  的程序包的功能的新打包索引，有效值为 2，以及对重新打包已损坏的程序包的适当保护。版本 2 是默认值。请注意，强制执行版本  2，并且只要相应的包大于 2 GB，就会忽略此配置选项。

如果您有一个不懂版本 2 *.idx文件的旧 Git，则克隆或获取非本机协议（例如“http”），该协议将从另一端复制*.pack文件和相应的*.idx文件可能会为您提供一个无法使用旧版本的 Git 访问的存储库。但是，如果*.pack文件小于 2 GB，则可以在* .pack 文件中使用 git-index-pack [1] 来重新生成*.idx文件。

pack.packSizeLimit 

包的最大尺寸。此设置仅影响重新打包时对文件的打包，即 git：//协议不受影响。它可以被 git-repack [1] 的--max-pack-size选项覆盖。达到此限制会导致创建多个 packfiles;这反过来又会阻止创建位图。允许的最小尺寸限制为 1 MiB。默认值是无限制的。支持 k ， m 或 g 的共同单位后缀。

pack.useBitmaps 

如果为 true，git 将在打包到 stdout 时使用 pack 位图（如果可用）（例如，在获取的服务器端期间）。默认为 true。除非您正在调试包位图，否则通常不需要关闭它。

pack.useSparse 

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

pack.writeBitmaps (deprecated) 

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

pack.writeBitmapHashCache 

如果为 true，git 将在位图索引中包含“哈希缓存”部分（如果有的话）。此缓存可用于提供 git 的 delta  启发式，可能导致位图和非位图对象之间更好的增量（例如，在较旧的位图包和自上一个 gc 以来已推送的对象之间提取时）。缺点是每个磁盘空间对象消耗 4  个字节，并且 JGit 的位图实现不理解它，如果在同一个存储库中使用 Git 和 JGit，则会导致它抱怨。默认为 false。

pager.<cmd> 

如果值为 boolean，则在写入 tty 时打开或关闭特定 Git 子命令输出的分页。否则，使用pager.值指定的寻呼机打开子命令的分页。如果在命令行中指定了--paginate或--no-pager，则它优先于此选项。要禁用所有命令的分页，请将core.pager或GIT_PAGER设置为cat。

pretty.<name> 

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

protocol.allow 

如果设置，请为未明确拥有策略的所有协议（protocol..allow）提供用户定义的默认策略。默认情况下，如果未设置，已知安全协议（http，https，git，ssh，file）的默认策略为always，则已知危险协议（ext）的默认策略为never，并且所有其他协议默认策略为user。支持的政策：

• always - 始终可以使用协议。
  
• never - 永远不能使用协议。
  
• user - 仅当GIT_PROTOCOL_FROM_USER未设置或值为 1 时才能使用该协议。当您希望协议可由用户直接使用但不希望由此使用时，应使用此策略。在没有用户输入的情况下执行 clone / fetch / push 命令的命令，例如递归子模块初始化。
  

protocol.<name>.allow 

使用 clone / fetch / push 命令设置协议使用的策略。有关可用的政策，请参阅上面的protocol.allow。

git 当前使用的协议名称是：

• file：任何基于文件的本地路径（包括file:// URL 或本地路径）
  
• git：直接 TCP 连接上的匿名 git 协议（或代理，如果已配置）
  
• ssh：git over ssh（包括host:path语法，ssh://等）。
  
• http：git over http，“smart http”和“dumb http”。注意，这 _ 不是 _ 包括https;如果要同时配置两者，则必须单独执行此操作。
  
• 任何外部助手都按其协议命名（例如，使用hg来允许git-remote-hg助手）
  

protocol.version 

实验。如果设置，客户端将尝试使用指定的协议版本与服务器通信。如果未设置，客户端将不会尝试使用特定协议版本进行通信，这会导致使用协议版本 0。支持的版本：

• 0 - 原始线路协议。
  
• 1 - 原始有线协议，在服务器的初始响应中添加了一个版本字符串。
  
• 2 - 有线协议版本 2 。
  

pull.ff 

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

pull.rebase 

如果为 true，则 rebase 在获取的分支顶部分支，而不是在运行“git pull”时合并默认远程的默认分支。请参阅“branch。< name> .rebase”，以便在每个分支的基础上进行设置。

当merges时，将--rebase-merges选项传递给 git rebase ，以便本地合并提交包含在 rebase 中（有关详细信息，请参阅 git-rebase [1] ）。

保留时，也将--preserve-merges传递给 git rebase ，以便通过运行 git pull 不会使本地提交的合并提交变平。

当值为interactive时，rebase 以交互模式运行。

注：这可能是危险的操作;做而不是使用它，除非你理解其含义（详见 git-rebase [1] ）。

pull.octopus 

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

pull.twohead 

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

push.default 

如果未明确给出 refspec，则定义git push应采取的操作。不同的值非常适合特定的工作流程;例如，在纯粹的中央工作流程中（即获取源等于推送目的地），upstream可能就是你想要的。可能的值是：

• nothing - 除非明确给出 refspec，否则不要推送任何内容（错误输出）。这主要是针对那些希望通过始终明确避免错误的人。
  
• current - 推送当前分支以更新接收端具有相同名称的分支。适用于中央和非中央工作流程。
  
• upstream - 将当前分支推回到分支，该分支的更改通常集成到当前分支（称为@{upstream}）。如果您要推送到通常从中拉出的相同存储库（即中央工作流），则此模式才有意义。
  
• tracking - 这是upstream的已弃用的同义词。
  
• simple - 在集中式工作流程中，像upstream一样工作，如果上游分支的名称与本地分支不同，则可以更加安全地拒绝推送。
  当推送到与通常拉出的遥控器不同的遥控器时，请作为current。这是最安全的选择，适合初学者。
  此模式已成为 Git 2.0 中的默认模式。
  
• matching - 推送两端具有相同名称的所有分支。这使你正在推动的存储库记住将被推出的分支集合（例如，如果你总是在那里推动 maint 和 master 而没有其他分支，你推送到的存储库将有这两个分支，你的本地 maint 和 _ 主 _ 将被推到那里。
  要有效地使用这种模式，你必须确保 _ 所有 _ 你要推出的分支都准备好在运行 git push 之前被推出，因为这个模式的重点是允许你一次推动所有分支。如果您通常只在一个分支上完成工作并推出结果，而其他分支未完成，则此模式不适合您。此模式也不适合推入共享中央存储库，因为其他人可能会在那里添加新分支，或者更新控制之外的现有分支的提示。
  这曾经是默认值，但不是因为 Git 2.0（simple是新的默认值）。
  

push.followTags 

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

push.gpgSign 

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

push.pushOption 

当没有从命令行给出--push-option=参数时，git push表现得好像每个< value>该变量的值为--push-option=。

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

例：

/ etc / gitconfig push.pushoption =一个 push.pushoption = b

〜/ .gitconfig push.pushoption = c

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

这将导致仅 b（a 和 c 被清除）。

push.recurseSubmodules 

确保要推送的修订使用的所有子模块提交都可在远程跟踪分支上使用。如果值为 check，然后 Git 将验证在要推送的修订版本中更改的所有子模块提交在子模块的至少一个远程处可用。如果缺少任何提交，则推送将中止并以非零状态退出。如果值为 on-demand，那么将推送在要推送的修订中更改的所有子模块。如果按需无法推送所有必要的修订，它也将被中止并退出非零状态。如果值为 _ 否 _，则保留推送时忽略子模块的默认行为。您可以通过指定 –recurse-submodules = check | on-demand | no 在推送时覆盖此配置。

rebase.useBuiltin 

设置为false以使用 git-rebase [1] 的旧版 shellcript 实现。默认情况下是true，这意味着在 C 中使用内置的重写。

C 重写首先包含在 Git 版本 2.20 中。如果在重写中发现任何错误，此选项可用于重新启用旧版本。此选项和 git-rebase [1] 的 shellscript 版本将在以后的某个版本中删除。

如果您发现某些理由将此选项设置为false而非一次性测试，则应将行为差异报告为 git 中的错误。

rebase.stat 

是否显示自上次 rebase 以来上游改变的差异。默认为 False。

rebase.autoSquash 

如果设置为 true，则默认启用--autosquash选项。

rebase.autoStash 

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

rebase.missingCommitsCheck 

如果设置为“warn”，git rebase -i 将在删除某些提交时打印警告（例如删除了一行），但是 rebase 仍将继续。如果设置为“error”，它将打印上一个警告并停止 rebase，然后可以使用 git rebase --edit-todo 来纠正错误。如果设置为“忽略”，则不进行检查。要在没有警告或错误的情况下删除提交，请使用待办事项列表中的drop命令。默认为“ignore”。

rebase.instructionFormat 

git-log [1] 中指定的格式字符串，用于交互式 rebase 期间的待办事项列表。格式将自动在格式之前添加长提交哈希。

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

receive.advertiseAtomic 

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

receive.advertisePushOptions 

设置为 true 时，git-receive-pack 将向其客户端通告推送选项功能。默认为 False。

receive.autogc 

默认情况下，git-receive-pack 在从 git-push 接收数据并更新 refs 后将运行“git-gc --auto”。您可以通过将此变量设置为 false 来停止它。

receive.certNonceSeed 

通过将此变量设置为字符串，git receive-pack将接受git push --signed并使用此字符串作为密钥使用 HMAC 保护的“nonce”进行验证。

receive.certNonceSlop 

当git push --signed在这么多秒内发送一个带有“nonce”的推送证书时，将由证书中的“nonce”导出到GIT_PUSH_CERT_NONCE到挂钩（而不是接收包要求发送方包括什么）。这可以使pre-receive和post-receive中的检查更容易一些。而不是检查GIT_PUSH_CERT_NONCE_SLOP环境变量，记录 nonce 过时的秒数，以决定是否要接受证书，他们只能检查GIT_PUSH_CERT_NONCE_STATUS是OK。

receive.fsckObjects 

如果设置为 true，git-receive-pack 将检查所有收到的对象。有关已检查的内容，请参阅transfer.fsckObjects。默认为 false。如果未设置，则使用transfer.fsckObjects的值。

receive.fsck.<msg-id> 

像fsck. 这样的行为，但被 git-receive-pack [1] 代替 git-fsck [1] 使用。有关详细信息，请参阅fsck. 文档。

receive.fsck.skipList 

像fsck.skipList这样的行为，但被 git-receive-pack [1] 代替 git-fsck [1] 使用。有关详细信息，请参阅fsck.skipList文档。

receive.keepAlive 

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

receive.unpackLimit 

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