我的团队目前在多个文件系统中管理一个git repo。我们大多数人使用Windows，但有些人使用Linux。另外，我们将生产代码部署在Linux服务器上。这导致了我们代码库中文件名大小写的多个问题（即，当文件实际为Foo.js时导入foo.js）。最近，我完成了对项目文件夹的清理工作，主要包括重新组织目录并将目录/文件重命名为通用命名标准。文件名的许多更改都改变了文件的大小写（例如foo.js-> Foo.js）。
当我进行这些更改时，我并没有完全意识到git在区分大小写和不区分大小写的文件系统上对文件名的处理方式不同，这导致了许多奇怪的错误。我在研究此内容时遇到的一件事是ignorecase中的.gitconfig值。
来自git-config文档：
内部变量可启用各种解决方法，以使Git能够在不区分大小写的文件系统（例如APFS）上更好地工作，HFS +，FAT，NTFS等。例如，如果找到目录列表当Git期望“ Makefile”时，“ makefile”会认为它确实是相同的文件，并继续将其记住为“ Makefile”。
...
Git依赖于此变量的正确配置操作和文件系统。修改此值可能会导致意外行为。
据我所知，设置ignorecase = true可以使它，以便如果git检测到相同的文件名但使用不同的大小写，它将更改git索引中的名称以匹配文件系统上的名称（即，如果Windows具有foo.js，而git checkout / pull具有Foo.js，则将假定foo.js是正确的，而git将使用该大小写）。我担心的是，如果我推送到远程并且我们的部署服务器选择了更改，将会发生什么。然后它将尝试导入不存在的Foo.js并错误输出。
但是，通过设置ignorecase = false，则git应该能够检测到文件名存在差异并正确替换文件。这是正确的吗，因为我们在不同的文件系统上工作，我应该让我的团队将此值设置为false吗？
[我读过一些人说你绝对应该这样做的文章，有些文章说的恰恰相反。
据我所知，设置ignorecase = true可以使它，以便如果git检测到相同的文件名但使用不同的大小写，它将更改git索引中的名称以匹配文件系统上的名称（即，如果Windows具有
foo.js，并且git checkout / pull具有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以获得文件名。请注意，这将转储整个索引内容！添加路径参数以选择特定的文件，例如[C0 ]，只查找那些文件。在类似Unix的外壳程序（例如bash）中需要使用引号，以防止外壳程序在此处解释元字符git ls-files "[Ff]oo.js"。该外壳程序将删除引号。在其他Windows-具体的命令行解释器，我不确定。）
[通常，您不应该更改[Ff]。如果要重命名文件，最直接的方法是使用core.ignorecase（同时调整索引和工作树）。如果只想更改大小写，则可以两次git mv：
git mv现在您在索引和工作树中都具有git mv foo.js temporary-name
git mv temporary-name Foo.js
，且其首字母均为大写。某些版本的Git可能无需中间临时名称即可处理此问题，但是当您使用中间名称时，所有版本都会做正确的事情。