Git之坑

最近在使用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目录更新到当前最新引用值。

发表评论

thirty − = twenty four