除了我之前介绍的
这里的
git config -l --show-origin，现在你还可以在Git 2.26（2020年第一季度）中使用。请注意，本文不提供解释，并保留HTML标签。
git config -l --show-scope
# you can combine both options:
git config -l --show-origin --show-scope
git config 已经学会显示每个配置设置来自哪个"scope"，除了显示来自哪个文件。
请查看提交 145d59f, 提交 9a83d08, 提交 e37efa4, 提交 5c105a8, 提交 6766e41, 提交 6dc905d, 提交 a5cb420 (2020年2月10日)，以及提交 417be08, 提交 3de7ee3, 提交 329e6ec (2020年1月24日) 由Matthew Rogers (ROGERSM94)完成。
(由Junio C Hamano -- gitster --在提交 5d55554中合并，2020年2月17日)
config: 添加 '--show-scope' 选项以打印配置值的作用域
签署者：Matthew Rogers
当用户使用 --show-origin 查询配置值时，通常很难确定给定值的实际 "作用域"（local、global 等）仅基于原始文件。
教 'git config' 使用 '--show-scope' 选项以打印所有显示的配置值的作用域。
请注意，我们永远不应该看到 "submodule" 作用域的任何内容，因为这只有在解析 '.gitmodules' 文件时由 submodule-config.c 使用。
git config -l --show-scope
global user.global=true
global user.override=global
global include.path=$INCLUDE_DIR/absolute.include
global user.absolute=include
local user.local=true
local user.override=local
local include.path=../include/relative.include
local user.relative=include
这使您能够快速区分以下内容：
- 受保护的配置：
system、global和command作用域。
- 标准配置：
local到存储库。
这是在Git 2.38（2022年第三季度）引入的：
请参阅由Glen Choo (chooglen)于2022年7月14日提交的提交8d1a744, 提交6061601, 提交5b3c650, 提交779ea93, 提交5f5af37。
（由Junio C Hamano -- gitster --在2022年7月22日合并至提交18bbc79）
文档: 定义受保护的配置
签名作者: Glen Choo
出于安全原因，有些配置变量只有在特定的配置范围内才被信任，有时在邮件列表上称之为“受保护的配置”（如
此线程中所述）。将来的提交将引入另一个这样的变量（
safe.bareRepository），因此让我们定义术语，以便我们可以有一致的文档和实现。
在我们的文档中，将“受保护的配置”定义为
system、
global和
command配置范围。简写为“仅受保护配置”，但不在文档中使用此术语。
受保护配置的定义基于Git是否可以通过忽略配置范围来合理地保护用户：
- 系统、全局和命令行配置被认为是受保护的，因为控制其中任何一个的攻击者都可以在没有Git的情况下造成很大的伤害，因此忽略这些范围几乎没有任何好处。
- 另一方面，本地（以及类似的工作树）配置不被认为是受保护的，因为攻击者相对容易控制本地配置，例如：
- 在某些共享用户环境中，非管理员攻击者可以在目录层次结构中高处创建一个存储库（例如Windows上的
C:\.git），当用户的PS1自动调用“git”命令时，用户可能会意外使用它。
safe.directory通过确保用户打算使用共享存储库来防止此类攻击。显然不应从存储库中读取它，因为这将信任Git应该拒绝的存储库。
- “
git upload-pack”
(man)预计在用户无法控制的存储库中运行。我们不能忽略该存储库中的所有配置（因为“
git upload-pack”将失败），但是我们可以通过忽略
uploadpack.packObjectsHook来限制风险。
只有
uploadpack.packObjectsHook是“仅受保护配置”。
以下变量被有意排除：
-
safe.directory应该是“仅受保护配置”，但从技术上讲，它不符合定义，因为它在“command”范围内不受尊重。将来的提交将解决此问题。
-
trace2.*恰好读取与
safe.directory相同的范围，因为它们共享实现。但是，这不是出于安全原因；而是因为我们希望尽早开始跟踪，以便存储库级别的配置和
"-c"不可用。这个要求对
trace2.*是独特的，因此受保护的配置不受相同约束的影响。
git config现在包含在其手册页面中：
受保护的配置
受保护的配置是指“系统”，“全局”和“命令”范围。
出于安全原因，只有在受保护的配置中指定某些选项时才会被尊重，否则将被忽略。
Git将这些范围视为由用户或可信管理员控制。这是因为控制这些范围的攻击者可以在不使用Git的情况下造成重大损害，因此假定用户的环境会保护这些范围免受攻击。
从 Git 2.39（2022年Q4）开始，允许在“受保护”的范围内的配置文件包含其他配置文件。
请参见提交记录ecec57b（由Glen Choo（chooglen）于2022年10月13日提交）。
（由Junio C Hamano -- gitster --合并于提交记录777f548，2022年10月25日）
config: 在受保护的配置中尊重 includes
签名作者: Glen Choo
保护配置是通过读取一组固定路径来实现的，这忽略了配置中的 [include]。将此实现替换为调用 config_with_options()，它处理 [include] 并避免我们重复逻辑：1）识别要读取的路径和2）读取命令行配置。
结果是，git_configset_add_parameters() 没有使用，因此删除它。它与受保护的配置同时引入
5b3c650（“config：学习 git_protected_config()”，2022-07-14，Git v2.38.0-rc0 --
merge 列在
batch #6 中），作为处理命令行配置的一种方式。
git config --list --show-origin，您将不必猜测哪个 git 配置在哪里。请参见下面的我的答案。 - VonC