我的团队目前跨多个文件系统管理一个 git 存储库。我们大多数人使用 Windows，但我们中的一些人使用 Linux。另外，我们将生产代码部署在 Linux 服务器上。这导致了我们代码库中文件名大小写的多个问题（即Foo.js在文件实际为 时导入foo.js）。最近，我完成了对我们项目文件夹的清理工作，其中主要包括重新组织我们的目录并将我们的目录/文件重命名为通用命名标准。许多这些文件名更改正在改变文件的大小写（例如foo.js-> Foo.js）。
当我进行这些更改时，我并不完全了解 git 如何在区分大小写和不区分大小写的文件系统上以不同的方式处理文件名，这导致了很多奇怪的错误。我在研究这个时遇到的一件事ignorecase是.gitconfig.
从 git-config 文档：
内部变量，它支持各种变通方法，以使 Git 在不区分大小写的文件系统上更好地工作，例如 APFS、HFS+、FAT、NTFS 等。例如，如果目录列表在 Git 需要“Makefile”时找到“makefile”，则 Git将假定它确实是同一个文件，并继续将其记住为“Makefile”。
…</p>
Git 依赖于为您的操作系统和文件系统正确配置此变量。修改此值可能会导致意外行为。
据我所知，设置ignorecase = true将使如果git检测到相同的文件名但大小写不同，它将更改git索引中的名称以匹配文件系统上的名称（即，如果Windows有foo.js并且 git checkout/pull 具有Foo.js，它将假定这foo.js是正确的并且 git 将使用该套管）。我担心的是，如果我推送到远程并且我们的部署服务器接受了更改会发生什么。然后它将尝试导入Foo.js不存在的并出错。
但是，通过设置ignorecase = false，那么 git 应该能够检测到文件名存在差异并正确替换文件。这是否正确，我是否应该让我的团队将此值设置为 false，因为我们跨不同的文件系统工作？
我读过人们说你绝对应该这样做的帖子，以及一些完全相反的帖子。