我已经在本地和全局配置级别进行了core.ignorecase=false的操作，但是当我执行git checkout MASTER（不是主操作）时，却看到了如下所示的奇怪行为。我也做了git branch -v，但是没有显示了MASTER。
git checkout master
Switched to branch 'master'
git branch
* master
git checkout MASTER
Switched to branch 'MASTER'
git branch
master
我们可以看到master上现在没有（*）。
我知道Mac OS X文件系统不区分大小写，但是
a）即使我们的操作系统对此进行了控制，core.ignorecase=false的显着意义还剩下什么呢？
b）如果git假设MASTER和master相同，为什么master分支上没有（*）？ [编辑：即使您将core.ignorecase = true设置，我们仍然会看到这个]
执行rev-parse，都指向相同的SHA1。
答案 0 :(得分：4)
通过设置core.ignorecase=false，您已配置错误，如果您希望Git表现合理，则应将其设置为正确的值true。摘自git-config手册：
内部变量，它使各种变通办法可以使Git在不区分大小写的文件系统（例如APFS，HFS +，FAT，NTFS等）上更好地工作。例如，如果目录列表在Git期望“ Makefile”时找到“ makefile” ”，Git将假定它确实是同一文件，并继续将其记住为“ Makefile”。
...
Git依赖于此变量对操作系统和文件系统的正确配置。修改此值可能会导致意外行为。
在macOS上，正确的值为true，除非您已专门将磁盘或分区格式化为区分大小写。因此，除非Git选择的值不正确，否则永远不要更改此值。例如，如果将存储库从不区分大小写的卷复制到区分大小写的卷，则该值将是不正确的，因为Git在使用git clone或git init创建存储库后不会探测该值。 / p>
我不确定将这个变量设置为false会达到什么目的，但是实际上唯一发生的是Git无法正常工作。
请注意，根据我的测试，如果您指定了大小写错误的分支，则Git在不区分大小写的文件系统上将无法获得正确的分支名称。如果愿意，可以在Git中将其称为bug，但是从经验上讲，在不区分大小写的文件系统上实现良好的行为可能很困难。
答案 1 :(得分：0)
这是预期的。您的OS /文件系统不区分大小写，并且将返回名称中包含替代大小写的文件。这是为粗心的人提供的单向活板门。
请注意，在更改为大小写不正确的分支*时，缺少任何列出的分支的MASTER-您的操作系统从分支master返回了详细信息（相同的文件名），并且检查出来。现在，Git在其可用分支列表中找不到MASTER。
适用于Windows的Git上存在类似的问题，并且经常出现。解决起来不容易（对人类进行编码）。