前文介绍了分支的概念,创建,合并,删除;但是并没有说分支在实际工作中怎么用,以及实际工作中会发生哪些常见的问题和问题怎么解决。
Case one:
假设老王和小芳是demo项目组的一员,两者开发的程序都需要提交到仓库;假设老王正在开发分支copy,小芳也正在开发分支copy。假设老王先行推送他的copy分支到远程仓库,小芳再推送她写的copy分支到远程仓库时,会发生推送冲突。
实操一下,让读者弄的明明白白,清清楚楚。在本地创建两个目录xiaoFang和laoWang,用来模仿小芳和老王这两个人,然后将远程仓库分别克隆到这两个目录里。其图示如下:
分别修改仓库目录中的内容,修改小芳仓库目录下的readme.md文件,添加如下内容:I’m xiaoFang;修改老王目录下的readme.md文件,添加如下内容:I’m laoWang。然后将两个仓库分别推送到远程仓库,执行命令以及执行结果如下:
上述第二个图片中,可以看出提交失败了,原因很简单,就是小芳和老王推送太频繁且内容有冲突。根据图片中的提示,可知需要用到一个命令:git pull。该命令表示将远程仓库最近一次关于当前head指向的分支提交抓取出来。
在小芳的dos窗口执行git pull命令,其执行结果如下:
提示自动合并失败;修复冲突,然后提交结果;修复冲突的方法和上一章说的修复方法一样,修复之后再提交就是了。
同时,我还有话要说,这是git pull成功的情况下,若是不成功呢?不成功不要紧,git系统会有帮助提示的。一般提示内容如下:
There is no tracking information for the current branch.
git pull <remote> <branch>
If you wish to set tracking information for this branch you can do so with:
git branch --set-upstream-to=littleName/<branch> branchName
git branch --set-upstream-to=littleName/<branch> branchName表示将远程仓库中的<branch>分支和本地branchName关联,关联之后再git pull就没有问题了。
不知道读者有没有发现,git pull提示的冲突信息很简单,而且对本地仓库修复冲突也很难下手。所以说,一般工作的时候,先用git pull查看一下git push是否有冲突。若是没冲突,就git push就OK了;如果有冲突呢?我提供一个方法,git clone下这个仓库,然后在本地看着两个仓库修改就是了。但是,这个也有一个麻烦,那就是你得下载一个仓库副本,若是遇到仓库文件内容太多怎么办?其实这个问题很多人都想到了,git官方也提供了一个sparsecheckout模式,用于克隆部分文件。此模式不在本教程内,我就不多说了,读者可以点此链接去自行查看用法:sparsecheckout模式
Case two:
假设有这样一种情况,你在开发某个项目的某个模块时,突然另外一个模块需要你去处理一下bug,所以此时你需要转到另一个模块所对应的分支去操作。是,看起来转换分支就行了,但问题是你当前分支的工作还没有完成,一但你切换分支,当前的工作就付之东流了。
此时,有的读者可能会说,你这个傻叉啊!你可以将当前工作提交了,然后再去操作另外一个分支。是,俺是傻叉!但思考另外一个问题,创建那么多的commitID好吗?提交后,你再转去另一个分支工作,等你工作完后,又从仓库中把刚才提交的分支提取出来,但问题来了,你还能记得当初你对工作的修改吗?如果你记得,pass;如果你记不住,我给你个好办法。你可以用git stash命令将当前的工作状态存储起来,然后不用提交,直接转到另外一个分支工作去。
有存储工作状态,就有提取工作状态的方法,等你再转回来准备工作时,可以用git stash list查看存储的所有状态。同样,你也可以用git stash apply命令和git stash pop命令将存储的状态恢复出来。这两个命令的区别在于,git stash apply命令只是单纯的恢复,而不删除存储记录,也就是说你在用git stash list方法后,还能找到这个存储状态;若要删除存储的状态,可以用git stash drop命令。git stash pop命令不仅恢复存储状态,也会删除恢复的状态。
还有很多种情况,这得等读者在慢慢的开发道路上遇到了才能解决。本章讲了两个常见的情况,并给除了解决方法。下章讲git中相当实用的一个工具,标签。
欲知后事如何,且听下回分解。
有钱的赏个钱场,没钱的赏个人场。良某人谢过了。