杂记[0x01] -- gitblit多人协作冲突解决之道

侃侃而谈

对应程序员而言，Git是比CVS、SVN好用的去中心化的版本控制工具，常用于代码版本管理
对应大众而言，就我从大学到工作接触的人来看，普及率不是很高，学习Git有助于知识管理吧，最经典的例子就是毕业论文不用一稿，二稿，三稿这样去命名，所有的我们直接一个文件搞定那就是毕业论文.doc

前期工作

在这里，我编写了一个真实的用户案例来跟大家分享一下Git版本冲突时，我们该怎么做？

在一个Git用户组gitStudy中，有三位选手，分别是g1,g2,g3三位同志。对项目gitStudy都具有RW 权限，其中，g1分配给了win10下的ataola账户，g2分配给了ubuntu下的root账户，g3分配给了ubuntu下的python账户。

故事由此开始！

产生冲突的情况分类

这里我把产生冲突的点列出来，并用带圈的阿拉伯数字表示，具体的请看楼下这张图。

g1:win10(ataola)	g2:ubuntu(root)	g3:ubuntu(python)	远程
同步	同步	同步	同步
添加了一个g1.txt	同步，添加g2.txt	不同步 ①	同步
同步	不同步 ②	同步	同步
不同步 ④	同步	不同步 ③	同步
同步	不同步 ⑤	同步	同步

首先是一楼的故事，我这边从远程创建了一个仓库叫gitStudy，之后在window和linux主机的不同用户下分别使用了g1,g2,g3三个账户去把gitStudy克隆了下来，此时，三者应该是同步的如一楼所示，没有问题吧。

其次是二楼的故事，ataola用户登录的win10这台电脑上，用户g1添加了g1.txt并附加内容我是 g1.txt之后提交到远程。紧接着二楼的用户root登录ubuntu后，先执行了git pull进行内容同步，然后创建了一个文件g2.txt并添加内容我是g2.txt，之后提交到远程。

这个时候用户python登录的ubuntu系统中，没有进行git pull，他先创建了一个g3.txt文件，并附加内容我是g3.txt，之后他以g3的身份提交到远程。这个时候产生了冲突①，我们来给它一个特写：

看到这里我期望你记住，在进行代码提交之前你不知道你就先pull! 先pull! 先pull。重要的事情说三遍。

那么我们来git pull一把，看看会发生什么？

可以看到它会叫你git merge对不对，我们把楼上两位合并起来来个特写如下：

之后我们进行git push就可以了，同样的我们来一个特写：

下面，我们把时间交给gitblit，请看其为我们发回来的远程最新画面，同样的我们来个特写：

因为是第一次产生冲突，那么我这边顺便讲下git log，通过这个命令我们可以在本地直观地看到对项目gitStudy的操作记录，同样的我们给它也来个特写。

通过观察远程的和本地的这两张特写，童鞋们有什么发现吗？

欧，不小心暴露了我的企业邮箱，行吧，反正这边也不能收发外界的邮件，看到就看到吧，不改了，佛系一点。

第一点，当git产生冲突时，会以最开始的同步点为起始点，拉出两条主线，并在冲突点之上建立一个同步点。

第二点，每一次git commit产生一串10位的哈希，但是你有没有发现，git merge的时候，只要取前面的7位就好了，这个也是很人性化的，谁喜欢打那么长，能区分提交就好了，这个同样适用于其他命令，例如版本回退的，这里不做展开。

好的，到这里我们巧妙地解决了冲突①带来的版本问题，值得纪念，这个时候我们可以给它打个标签用git tag来记录这一时刻，我们同样给它来个特写：

对应的远程也来一张特写，咔：

可以看到我们刚打的，还热乎的标签。

再次是三楼的故事，这里g1先执行了git pull同步远程代码，然后创建了一个文件gao_git.txt并附加内容搞 git，通过git push提交到了远程。

g2也在本地创建了一个文件gao_git.txt并附加内容g2 在搞git，然后进行git push发现提交不上去，产生了冲突②，我们给它来个特写：

g2这位选手你看到楼上那个#了吗？这可是root账户，脾气大着咧，哼哼，哪来的妖孽在此放肆，敢阻挡本座的提交，看本座怎么收拾你。

g2这位选手，使用了强制提交的必杀技，巧妙地终结了楼上那位的提交。

-f: -force, git push origin 分支名 --force 同样的我们给它也来一个特写：

接下来我们把画面交给远程同志，来看一下传回来的最新画面

可以看到，g2同志霸气地提交了add gao_git.txt from g2。

好的，到这里我们巧妙地解决了冲突②带来的版本问题。这种方法在这边只做介绍，在你的个人的项目中你可以这么搞，因为很多时候人家也不高兴看你的提交的，只看结果代码就好，你怎么开心怎么来吧。但是要是团队的项目千万别这么搞，遇到比root还猛的同志，有可能会被暴揍一顿。

这里要隆重表扬下g3这位选手，自从上次v0.1.0事件以后，他印象深刻，记牢了我说过的先git pull，那么就让我们来看看在四楼的g3是如何处理冲突③的。

g3先创建了gao_git.txt文件并添加内容为g3 搞git,然后进行了git pull和git merge,如此伟大的时刻，不该给他来个特写吗？

通过楼上我们可以看到，g3选手先进行了git pull一把，发现系统并没有理他，自动合并失败，开启人工模式。通过ls命令查看了该项目的文件，然后通过cat命令查看了冲突文件的内容。从楼上我们可以清晰地看到，同文件下产生冲突是什么样的表现形式，大致是会有> < = 还有一串has。g3棒棒地完成了冲突的修复，

我们把话筒交给远程，看一下他发回来的最新画面吧！

好的，看到这里我们可以看到g3也解决了冲突。

留下一点时间思考，要是数据量非常大，不是单单的一个文件短短的一句冲突，那么这将是一件非常头大的事，所以由此可见有一个良好的团队队友的重要性。

在四楼，有想法的g1从g3选手的口中得知了g2这位选手干的好事后，露出了微微一笑，哼哼。通过分析g2的行为，他果断地认为g2这位同志(root)官大一级压死人，估计也不懂啥是分支，啥是生产线啥是测试线，就一个劲地强制提交master，行吧，随他去吧，g1选手机智地创建了一个分支g1，然后进行了提交，解决了冲突④,我们给他也来个特写：