git大小写敏感与团队协作问题相关

Windows 上的 Git 默认是大小写不敏感的，这样多平台协作就可能会出现问题。

首先查看 git 大小写敏感的命令

git config --get core.ignorecase

先说一下 git 大小写不敏感吧，也就是 git config --get core.ignorecase 得到为 true 的情况下；

例如我们现在本地有一个文件为 Test 文件夹

Test/
|-MyComponent
|---index.js

我们现在想把 Test 文件夹改为小写 test，如果直接修改文件名，然后我们使用 git status 查看我们要提交的文件变动，会发现如下，我们没有需要提交的文件；git 默认他是没有变动的；

nothing to commit, working tree clean

那么我们想要改动他提到仓库应该怎么去修改呢；
可以使用 git mv 命令修改；但这里需要注意一下，git mv 重命名文件目录时对名字是大小敏感的，对文件名不敏感；

git mv Test test

这样是不会成功的；应该如下操作

git mv Test temp
git mv temp test

做完一切后 push 上去，会发现仓库的文件夹大小写也同步了，很多人说敏感会造成的问题更多，然后推荐我们使用不敏感；

其实不然，虽然你自己这里没问题了，但是如果是团队协作，其他人一开始也和你一样拉到的代码是有 Test 文件夹的，他也是不敏感；他在你修改文件夹后，pull 你的代码，依旧发现还是大写！

那么我们来说说敏感的情况，首先设置大小写敏感的命令如下：

git config --global core.ingorecase false

此时 git config --get core.ignorecase 得到为 false 正常；

还是上面的例子我们现在本地有一个文件为 Test 文件夹

Test/
|-MyComponent
|---index.js

现在我们直接把他改成 test，然后我们使用 git status 查看我们要提交的文件变动，发现显示新添加了 test 文件夹及文件

new file:   test/...

我们发现并不是我们想要的 rename，如果这时候直接提交上去，别人拉完代码，本地会多一个小写的文件夹；

那么下面我们来看正确的操作；
第一种 git mv

git mv Test temp
git mv temp test

然后 add push 直接提交
第二种
先删除在 git 仓库中托管的 Test 文件夹

git rm -r --cached Test

然后修改 Test 为 test；add push 直接提交；
这两种操作，我更加常用第二种，因为，有一种情况是，我既要修改 Test 又要修改 Test 下的文件大小写，那这种情况，如果用 git mv 显然太慢，而且如果 Test 底下还有文件夹，工作效率会很慢，直接使用 git rm -r --cached 删除托管，重新提交托管，一步到位；

那么在我们提交到仓库后，其他同事都会进行 git pull origin master 操作，去拉取代码，然后报了如下错误：

error: The following untracked working tree filed would be overwritten by merge:
  Test/-MyComponent/index.jsx
  ...
  ...

那么这是什么情况呢，首先我们来解释一下 git pull 是什么意思哈；

git pull origin master = git fetch origin master+ git merge origin/master

fetch 是更新远程 master 代码
merge 是合并远程分支 master 代码；

在拉取完成之后，merge 的过程中发现我们有冲突了，所以停止了 merge；

这种情况我们 需要按照冲突提示，去删除这些文件，然后重新，git pull 就没有问题了；

那还有一种情况，就是在某同事修改完文件夹大小写名称后，某一同事拉完代码，然后解决冲突，想要切换其他正在开发的功能分支时，依旧发现类似这种情况；

error: The following untracked working tree filed would be overwritten by checkout:
  Test/-MyComponent/index.jsx
  ...
  ...

这种情况为，你将要切换的哪个分支，和你现在的分支文件冲突，那我们需要强制先切换到对应的分支

git checkout -f 对应分支

然后执行同样的操作 git pull 然后解决文件冲突；

总结

不敏感没有错，很多人觉得敏感问题更多，其实可能是偏向于个体开发，只觉得自己提交了对的代码到仓库，但其实对于其他如果不开大小写敏感的同事来说，你修改的大小写并未同步；

敏感更加保险，你的每一次修改都会被 git 仓库记录，你在协作的同伴，也能感知你的修改，解决冲突是必要的，需要让同事们知道你的操作；