将git config core.ignorecase设置为false是一个好主意吗？

我的团队目前管理跨多个文件系统的git repo。我们大多数人使用Windows，但有些人使用Linux。另外，我们将生产代码部署在Linux服务器上。这导致了代码库中文件名大小写的多个问题（即当文件实际上是

Foo.js

时导入

Foo.js

）。最近，我完成了项目文件夹的清理工作，主要包括重新组织目录和将目录/文件重命名为通用命名标准。许多文件名更改都改变了文件的大小写（例如，

foo.js

->

foo.js

）

当我进行这些更改时，我并没有完全意识到git在区分大小写和不区分大小写的文件系统上如何以不同的方式处理文件名，这导致了许多奇怪的错误。我在研究这个问题时遇到的一件事是

.gitconfig

中的

ignorecase

值

从git配置文档：

内部变量，它支持各种变通方法，使Git能够 在不区分大小写的文件系统上工作得更好，如APFS， HFS+、FAT、NTFS等。例如，如果目录列表找到 “makefile”当Git期望“makefile”时，Git会假定它确实是 相同的文件，并继续将其记为“Makefile”

Git依赖于此变量的正确配置来满足您的需求 操作系统和文件系统。修改此值可能会导致 意外的行为

从这里我可以理解，设置

ignorecase=true

将使它成为这样，如果git检测到相同的文件名，但大小写不同，它将更改git索引中的名称以匹配文件系统上的名称（即，如果Windows有

foo.js

，而git签出/拉取有

foo.js

，则它将假定

foo.js

是正确的，git将使用该大小写）。我关心的是，如果我推到远程，部署服务器接收到更改，会发生什么。然后，它将尝试导入不存在的

Foo.js

，并出错

但是，通过设置

ignorecase=false

，git应该能够检测到文件名中存在差异，并正确地替换文件。这是否正确，我是否应该让我的团队将此值设置为false，因为我们在不同的文件系统中工作

我读过一些帖子，人们说你绝对应该这样做，而有些帖子则恰恰相反

从这里我可以理解，设置ignorecase=true将使它成为这样，如果git检测到相同的文件名但大小写不同，它将更改git索引中的名称以匹配文件系统上的名称（也就是说，如果Windows有

foo.js

，而git签出/拉取有

foo.js

，它将假定

foo.js

是正确的，git将使用该大小写）

不，这是反向的：文档说明，如果索引当前包含一个

Foo.js

，并且工作树出于任何原因有一个

Foo.js

，Git将假定

Foo.js

确实是

Foo.js

，并将

Foo.js

放入下一个提交中，同时

core.ignorecase

设置为

>false

，但是Git完全相信工作树：

Git add.

将删除大写名称（和内容），并使用小写名称

foo.js

根据工作树中的副本在索引中安装新副本

（要查看索引中的内容，请使用

git ls files--stage

，或者省略

--stage

，只获取文件名。请注意，这会转储整个索引内容！添加路径参数以选择特定文件，例如，

git ls files“[Ff]oo.js”

，仅查找这些文件。在类似Unix的shell（如bash）中需要引号，以防止shell在此处解释元字符。shell将删除引号。我不确定在其他特定于Windows的命令行解释器中使用什么。）

通常，您不应更改

core.ignorecase

。如果您希望重命名文件，最简单的方法是使用

git mv

（同时调整索引和工作树）。如果您只想更改大小写，您可以

git mv

两次：

git mv foo.js temporary-name
git mv temporary-name Foo.js

---

现在你有了

Foo.js

，在索引树和工作树中都有一个大写字母。Git的一些版本可能可以在没有中间临时名称的情况下处理这个问题，但是当你使用中间名称时，所有这些都会做正确的事情

“然而，当core.ignorecase设置为false时，Git完全相信工作树：Git add.将删除大写名称（和内容），并使用小写名称foo.js根据工作树中的副本在索引中安装新副本。"但是，这不是我所期望的行为吗？通过这样做，它不会强制索引与工作树匹配，从而使每个人的本地存储库中的大小写都匹配吗？另外，感谢您提供有关使用

git ls files

查看索引中内容的提示。在我做了所有更改后，我意识到使用

git mv

两次是正确的wayWell，假设用户A故意将

foo.js

重命名为

foo.js

（无论出于何种原因）昨天。进一步假设用户B在Windows或MacOS上，今天在他们的工作树中签出了名为

foo.js

的所有内容。他们将

core.ignorecase

设置为false。他们运行

git fetch

以获得新提交（将其重命名为

foo.js

）然后

git merge--ff only

或

git checkout

移动到最新提交，该提交调用文件

Foo.js

（到目前为止还不错，对吧？），但是现在…[继续]现在他们的git试图替换小写的

Foo.js