我已经阅读了git-config文档，并检查了SO questsions here和here，但我似乎找不到答案。
我正在为Git编写一个自定义工具，我想测试一下。我想备份我的全局和系统Git配置文件，然后在我的测试中写入新的配置文件，这样我就不会覆盖我已经存在的配置文件（供参考，我正在测试多个不同的可移植（本地构建）版本的Git，无论是Linux还是Windows，都在我的项目的子目录中）。
我最初的想法是简单地使用cp：
# Backup the system config file
# NOTE: How do I test this automatically? (I have to enter root password)...
sudo cp ${PREFIX}/etc/gitconfig ${PREFIX}/etc/gitconfig.bak
# Backup the global config file
cp ~/.gitconfig ~/.gitconfig.bak
# DO MY TESTS HERE
# Restore system config file and delete backup
sudo cp ${PREFIX}/etc/gitconfig.bak ${PREFIX}/etc/gitconfig
sudo rm ${PREFIX}/etc/gitconfig.bak
# Restore global config file and delete backup
cp ~/.gitconfig.bak ~/.gitconfig
rm ~/.gitconfig.bak字符串
然而，我没有看到t/t1300-config.sh中这样做（在撰写本文时，主存储库的当前版本是v2.32）。我看到的最接近的事情是这样的（第2147-2158行）：
test_expect_success 'write to overridden global and system config' '
cat >expect <<EOF &&
[config]
key = value
EOF
GIT_CONFIG_GLOBAL=write-to-global git config --global config.key value &&
test_cmp expect write-to-global &&
GIT_CONFIG_SYSTEM=write-to-system git config --system config.key value &&
test_cmp expect write-to-system
'型
我不明白这是怎么回事。Git文档解释说，GIT_CONFIG是一个环境变量，可以设置它来覆盖git config文件，但是如果我在终端中输入上述命令，不会创建write-to-global或write-to-system文件（这些也不是测试脚本中的函数）。
谁能解释一下如何正确使用GIT_CONFIG环境变量，以及在测试脚本中正确的方法是什么？
2条答案
按热度按时间4c8rllxm1#
Git Docs解释
GIT_CONFIG是一个环境变量，可以设置为覆盖git配置文件。随着Git 2.33（2021年第3季度），关于
GIT_CONFIG的文档已经更新，并澄清了当前的情况。参见commit 7342838，commit b3b1862，commit 4bb9eb5（2021年7月14日）由Jeff King (
peff)。（由Junio C Hamano --
gitster--合并到commit 5a9b455，2021年8月2日）doc/git-config：我的天啊澄清GIT_CONFIG环境变量签收人：杰夫·金
审核人：泰勒·布劳
GIT_CONFIG变量的作用范围和实用性被dc87183（仅使用GIT_CONFIG in，2008-06-30，Git v1.6.0-rc 0--merge）（仅在“git config“（man）中使用GIT_CONFIG，而不是其他程序，2008-06-30）大大减少。但是git-config（1）中的文档早于此，这使得它具有误导性。
现在，它实际上只是另一种方式说“
--file”。所以让我们这么说吧，并且明确地说明它不会影响其他Git命令（比如
GIT_CONFIG_SYSTEM,等）。我还把它放在变量列表的底部，并警告人们不要使用它。
我们目前还没有任何弃用的计划，但是鼓励人们使用它，把它放在清单的顶部是没有什么意义的。
git config现在在其手册页中包括：GIT_CONFIG如果未向
git config提供--file选项，请使用GIT_CONFIG提供的文件，就像通过--file提供的文件一样。这个变量对其他Git命令没有任何影响，主要是为了历史兼容性;通常没有理由使用它来代替
--file选项。还有：
doc/git-config：我的天啊explain --file而不是引用GIT_CONFIG签收人：杰夫·金
审核人：泰勒·布劳
--file选项的说明仅涉及GIT_CONFIG。这种重定向到环境变量的做法令人困惑，但由于
GIT_CONFIG的描述已经过时了，这让人更加困惑。让我们从头开始学习
describe（man）--file，详细描述阅读和写行为，就像我们对其他类似选项（如--system等）所做的那样。git config现在在其手册页中包括：对于写入选项：写入指定的文件而不是存储库
.git/config。阅读选项：只从指定文件读取，而不是从所有可用文件读取。
Git 2.42（2023年第3季度）为“
git var”（man）添加了更多内容，让工具匠通过配置或硬编码默认值了解Git配置的各种位置。参见commit ed773a1，commit 576a37f，commit 15780bb，commit cdd489e，commit f74c90d，commit 1e65721，commit d6546af（2023年6月27日）by brian m. carlson (
bk2204)。请参阅commit 4db16f5（2023年6月27日）。
（由Junio C Hamano --
gitster--合并到commit 89d62d5，2023年7月4日）var：添加配置文件位置签收人：布赖恩·卡尔森
与属性文件非常相似，有时程序希望知道配置文件在全局或系统级别的位置。
然而，并不总是清楚这些可能存在于何处，特别是对于系统文件，系统文件可能在编译时被硬编码或基于运行时前缀动态计算。
由于其他各方无法直观地知道Git是如何编译的，以及它在哪里查找这些文件，所以可以通过提供可以查询的变量来帮助他们。
因为全局配置值有多个路径，所以按优先级从高到低的顺序打印它们，并确保拆分换行符，以便“
git var -l”（man）为全局值生成两个条目。但是，请注意不要在换行符上拆分所有值，因为我们的编辑器值很可能包含这样的字符，在这种情况下我们不想拆分它们。
请注意，在文档中，某些值可能包含多个路径，调用方应该对此做好准备。
这可以帮助人们编写代码，在将来我们允许在其他地方使用多个项目的情况下，这些代码将继续工作。
git var现在在其手册页中包括：GIT_CONFIG_SYSTEM系统配置文件的路径（如果已启用）。
GIT_CONFIG_GLOBAL全局（每个用户）配置文件的路径（如果有）。
大多数路径值只包含一个值。但是，有些可以包含多个值，这些值由换行符分隔，并按优先级从高到低的顺序列出。调用方应准备任何此类路径值包含多个项。
请注意，即使路径不存在也会打印，但如果路径被其他环境变量禁用，则不会打印。
w46czmvw2#
环境变量
GIT_CONFIG是古老的，早于Git 1.5.3，其中添加了git config --file。它仍然是一种欺骗 * 其他 * Git命令的方法，使它们像被赋予了一个--file参数，以传递 * 给 *git config。它可能应该被删除，但是，好吧，Git保持了很多向后兼容性！这让我想起了英特尔把“向后兼容”中的“向后”的老笑话...在Git 1.8.2之前，
git clone依赖于在内部设置GIT_CONFIG，然后取消设置。看起来（从链接的问题和他们的答案）这里可能仍然有一些剩菜。（我在发行说明中发现了以上两项。所有添加的snark是我自己的虽然。）
Git版本2.31.0添加了新的
GIT_CONFIG_COUNT和GIT_CONFIG_KEY_$i，GIT_CONFIG_VALUE_$i环境变量。它们似乎是为了增加某种程度的安全性，以避免传递-c参数，这些参数可以从ps阅读命令行。但是由于ps也可以（至少在许多系统上）读取环境变量，我认为这种“安全性”大多是虚幻的。有人能解释一下如何正确地使用GIT_CONFIG环境变量以及在测试脚本中正确的方法吗？
除非你需要把配置放在
.git/config以外的地方，否则简单的回答是“根本不要使用这个”。如果您想确保 system 配置文件不影响您，请设置GIT_CONFIG_NOSYSTEM（设置为任意值，尽管我使用true只是为了保持一致）。然后你可以设置$HOME和$XCD_CONFIG_HOME，让其他Git命令在一个可预测的位置查找全局Git配置文件，当然本地和每个工作树配置文件的位置已经是可预测的了。这个方法有点笨拙。
. in
t/t1300-config.sh最近（不是在任何版本中，而是在2.32.0版本 * 候选版本中）获得了新的
GIT_CONFIG_SYSTEM和GIT_CONFIG_GLOBAL变量。他们的目的是解决上述一些笨拙的问题。除非您正在构建各种发布候选版本或其他尖端分支，否则您根本不会拥有这些功能。但在我看来，这确实是一个更好的方式来处理这一切。