在OSX下，为了避免这个问题并避免在不区分大小写的文件系统上开发时出现其他问题，可以使用Disk Utility创建区分大小写虚拟驱动器/磁盘映像。

运行磁盘实用程序，创建新的磁盘映像，并使用以下设置（或根据需要进行更改，但要区分大小写）：

确保告诉git它现在在区分大小写的FS上：

git config core.ignorecase false

Git有一个配置设置，告诉它是否需要区分大小写的文件系统：core.ignorecase。要让Git保持大小写稳定，只需将此设置设置为false。（如果您已经推送了文件，请务必小心，然后在给出其他答案后，应首先移动它们）。

git config core.ignorecase false

注意，在不区分大小写的文件系统上，将此选项设置为false通常是一个坏主意。这样做会导致奇怪的错误。例如，以仅更改字母大小写的方式重命名文件将导致git报告虚假冲突或创建重复文件（来自Mark Amery的评论）。

文档

从git-config文档中：

核心.ignorecase如果为true，则此选项启用各种变通方法，使git能够更好地处理不区分大小写的文件系统，如FAT。例如，如果一个目录列表在git期望makefile时找到了makefile，git将假设它实际上是同一个文件，并继续将其记为makefile。默认值为false，但gitclone（1）或gitinit（1）将在创建存储库时探测并将core.ignorecase设置为true（如果合适）。

不区分大小写的文件系统

据我所知，最流行的两种具有不区分大小写文件系统的操作系统是

窗户操作系统X

我在MacOS上多次遇到过这个问题。Git区分大小写，但Mac只保留大小写。

有人提交了一个文件：Foobar.java，几天后决定将其重命名为Foobar.java。当你拉最新的代码时，它失败了。以下未跟踪的工作树文件将被签出覆盖。。。

我所看到的解决这一问题的唯一可靠方法是：

git rm Foobar.java用一条不能错过gitcommit-m'TEMP Commit！！'的消息提交它拉这将弹出一个冲突，迫使您合并冲突-因为您的更改删除了它，但另一个更改重命名了它（因此出现了问题）接受您的更改，即“删除”git rebase—继续现在放下你的解决方法gitrebase-i HEAD~2，放下TEMP COMMIT！！确认文件现在名为FooBar.java

因此，GitHub如何处理这种区分大小写的部署问题有很多解决方案。

在我的例子中，我已经将文件名的大小写约定从大写改为小写。

我相信git可以跟踪更改，但这个命令git-config-core.ignorecase false指示git如何在幕后操作

在我的例子中，我运行了命令，git突然有很多文件要跟踪，标记为未跟踪。

然后我点击gitadd，然后git提交并再次在netlify上运行我的构建。

然后可以跟踪现在显示的所有错误，例如找不到模块：无法解析“”/Components/ProductRightSide位于/opt/build/rebo/Components/products中，并已修复，以便git能够成功跟踪和实施更改。

这是一个很好的解决方法，也可以避免沮丧，但相信我，这肯定会奏效的。

PS：解决问题后，您可能需要运行命令git-config-core.ignorecase true还原git如何区分大小写。

此外，请注意git-config-core.ignorecase-false与其他文件扩展名存在问题，因此您可能需要注意，如果您知道自己在做什么并且确信这一点，请执行此操作。

这是netlify上的一条线索，可能会有所帮助

在OSX下，为了避免这个问题并避免在不区分大小写的文件系统上开发时出现其他问题，可以使用Disk Utility创建区分大小写虚拟驱动器/磁盘映像。

运行磁盘实用程序，创建新的磁盘映像，并使用以下设置（或根据需要进行更改，但要区分大小写）：

确保告诉git它现在在区分大小写的FS上：

git config core.ignorecase false

我们可以使用gitmv命令。例如，如果我们将文件abcDEF.js重命名为abcDEF.js，那么我们可以从终端运行以下命令

git mv -f .\abcDEF.js  .\abcdef.js