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

Git

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

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也会上传我这一次错误的提交，不过也无所谓了，反正现在解决了。