--- title: Git 不区分大小写 date: 2023-07-23 modified: 2023-07-26 url: https://yuuu.org/post/git-case-insensitive categories: ["踩坑"] tags: ["踩坑"] --- 我在换光标的时候，出现了一个差错，实在是太过于憋屈，不得不写一篇文章来提醒自己。 ## Git 在[折腾一下自定义光标](https://yuuu.org/post/8804.html)中，我说了一下关于我如何修改网站图标的方法。在当时，我准备好了光标文件，并且上传到了 GitHub，并试图在网站中引入该文件，但是却发现无法引入。 一番检查后发现，我错误地将文件命名为 Link 并且上传到了 GitHub，而我在网站中输入的 URL 中的文件名却是 link，这就导致了网址错误，没法指向文件。于是我将 Link 重命名为 link，使用"git add ."重新提交到 git，结果它直接提示我如下文所示。 ```bash 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 可以开关区分大小写功能。具体检查代码为 ```bash 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 可能会导致更多的错误。既然如此，多一事不如少一事，我觉得最合适的方法还是从自身开始，减少自己的命名错误。 ![1](https://cdn.yuuu.org/post-img/5/1.gif) 上图是 windows 不区分大小写的一个例子，当目录存在"Link"文件的时候，再重命名一个"link"便会报错。这个特性，我现在才知道。 ## 后知后觉 写完上文我才想起，可以回滚版本来得到一个未提交 Link 的版本，这样就不用迭两个版本号来更新文件了。但是考虑到这个仓库又连带着 npm 自动部署，当我提交文件之后，便会自动开始发布 npm 包，而 npm 包无法被编辑，只可以通过递增版本的方式来进行更改，也就是，哪怕是通过回滚的方式来刷新提交记录，npm 也会上传我这一次错误的提交，不过也无所谓了，反正现在解决了。