最近在使用Git进行多人协作时遇到了一些坑，在些处记录一下。
在使用git的过程中，最频繁使用的应该就是git pull了。在git pull命令时，一般会遇到下面几种情况。
如果是本地完全没有修改，则可以顺利进行git pull，如果有本地提交会与git pull下来的commit进行自动merge（当然自动merge也有可能失败，手动解决一下冲突即可)。
如果本地的修改与被git pull下来的commit中修改有相同的文件，这时git会报错提示，这时只让你先把本地修改commit或stash一下，也不会有太大问题。
最坑的就是是本地有修改，并且与git pull下来的commit并没有修改相同的文件。但是本地的commit(即没有push到远程仓库的提交)与git pull下来的commit自动合并时冲突了，这里git会提醒你要使用git commit -a来提交，但是根据git commit -a的语义，其实他不仅仅是把冲突内容全部合并，还会把本地的其他没有完成的修改一并提交上去。
一般来说，本地的修改大都是不完整的修改，这里如果提交上去，很容易造成其他问题。因此为了保险起见，如果本地有修改一定要先使用git stash将本地修改暂存之后，再执行git pull命令去拉取代码。
上面的坑，最多只会造成不完整的修改被提交，很容易及时发现。
但是另外一个关于submodule的坑，在超过一个人协作的情况下如果不注意是必然会发生的事。
假设有A和B两个人进行协作修改工程P。在P中引用了submodule S。
最初P-A(A的本地仓库)与P-B(B的本地仓库)中对submodule S的引用都是commit 1(SHA-1:xxxxxxxxxxx)。
这里S仓库有一个bug被修复了，P-A将自己的本地仓库中S的引用更新至commit 2(SHA-1:xxxxxxxxxxxxx)。然后提交并push到远程仓库。
这之后，B对P-B仓库成功执行了git pull命令。理论上P-B的仓库此时对S仓库的引用已经变更为commit 2了。但是由于S在P-B目录中的最新commit依然为commit 1。
在这之后，其实P-B中的S仓库并没有任何变动，依然为commit1，并且除了使用git status可以主动查看外，git 在合并之后并没有任何主动提交。这时P-B在完成某项修改之后，直接使用git commit -a就会重新将对S仓库的引用变更为commit 1。并且git 不会有任何提示。
如果要解决这个问题，必须要每次git pull之后，立即执行git submodule update –init来将仓库中的S目录更新到当前最新引用值。