git 不区分大小写

我在换光标的时候，出现了一个差错，实在是太过于憋屈，不得不写一篇文章来提醒自己。

Git

在折腾一下自定义光标中，我说了一下关于我如何修改网站图标的方法。在当时，我准备好了光标文件，并且上传到了 GitHub，并试图在网站中引入该文件，但是却发现无法引入。一番检查后发现，我错误的将文件命名为 Link 并且上传到了 GitHub，而我在网站中输入的 URL 中的文件名却是 link，这就导致了网址错误，没法指向文件。于是我将 Link 重命名为 link，使用”git add .” 重新提交到 git，结果它直接提示我如下文所示。

1
2
3
4

On branch master
Your branch is up to date with 'origin/master'.

nothing to commit, working tree clean

“没有可以提交的，工作树是干净的。”
可是我有修改文件名耶！
不管怎么改，我就是没办法让 git 识别到我改了名字，最后一气之下直接将文件删除后提交，再把重命名好的文件拉回来再提交，这样子才算是更新了 Github 上的文件。

把这个文件名字处理完后，我又想出了一个办法，用 git mv link.png link.png 来重命名文件，在本地证实 Git 可以识别出这个文件被重命名了，然后我试着复现情况：Github 上有 Link 和其他文件，本地的 Link 文件通过 git mv 指令重命名，并且被 git 识别，同时修改部分文件。提交后，Github 却对于重命名的 link 不予理睬，只是修改了其他文件。

也就是说，哪怕是在本地 Git 上重命名了文件，Github 还是不会把这个文件更新。

我问了一番才知道，Git 可以开关区分大小写功能。具体检查代码为
git config core.ignorecase
如果该命令返回 true，则表示 Git 在文件名上不区分大小写。如果返回 false 或未设置该参数，则表示 Git 在文件名上区分大小写。而我的返回当然是 true，这便是祸端的开始。
这件事之后，我当然希望 Git 区分大小写。不过凡事都有两面性，如果区分大小写好的话，为什么 Git 不会默认开启呢。在此之前，我还是先问了一下 New Bing，它轻飘飘的说了一段话

Git 本身是区分大小写的，但它也可以在不区分大小写的文件系统上运行。在这种情况下，Git 有一个配置选项 core.ignorecase，用于告诉它是否应该忽略文件名的大小写。默认情况下，当 Git 在不区分大小写的文件系统上运行时，此选项将设置为 true。

是否区分大小写取决于您的需求和使用场景。如果您希望能够识别仅更改了文件名大小写的更改，那么您可能希望 Git 能够区分大小写。但是，在不区分大小写的文件系统上强制 Git 区分大小写可能会导致一些问题。例如，如果您仅更改了文件名的大小写，那么 Git 可能会报告虚假冲突或创建重复文件。

总之，如果您在不区分大小写的文件系统上使用 Git，那么最好让 Git 保持默认配置（即不区分大小写）。如果您在区分大小写的文件系统上使用 Git，则可以根据需要配置 Git 来区分或不区分大小写。

正巧的是，windows 就是属于这一类不区分大小写的系统，按照 bing 的话，开了区分大小写的 Git 可能会导致更多的错误。既然如此，多一事不如少一事，我觉得最合适的方法还是从自身开始，减少自己的命名错误。

上图是 windows 不区分大小写的一个例子，当目录存在”Link” 文件的时候，再重命名一个”link” 便会报错。这个特性，我现在才知道。

后知后觉

写完上文我才想起，可以回滚版本来得到一个未提交 Link 的版本，这样就不用迭两个版本号来更新文件了。但是考虑到这个仓库又连带着 npm 自动部署，当我提交文件之后，便会自动开始发布 npm 包，而 npm 包无法被编辑，只可以通过递增版本的方式来进行更改，也就是，哪怕是通过回滚的方式来刷新提交记录，npm 也会上传我这一次错误的提交，不过也无所谓了，反正现在解决了。