- 在github上创建一个仓库
- 在本地两个攵件夹分别clone同一仓库。称之为仓库A仓库B。
- 在仓库B修改同一文件的同一行：test.txt
同样保存修改后尝试提交到远端，发现冲突了导致无法提茭到远端：
既然冲突了，就必须解决冲突解决冲突有两种方式：
方法1：使用rebase合并分支
-
下载所有分支的最新代码
留下想保存的内容，其他刪除掉就OK了。
-
冲突解决完成之后提交修改 继续合并。合并的过程中还有可能产生冲突。解决方法同上
用一个图概括rebase解决冲突的前後变化：
方法2:使用merge合并分支
-
下载所有分支的最新代码
和rebase一样，手动解决冲突
用一个图概括merge解决冲突的前后变化：
在gerrit的界面上使用cherry-pick是在服務端进行操作的，完全不涉及本地分支
将本commit与其父commit之间的差异（patch）应用到另一个分支上。
所以说如果如果patch对应的源文件对应的行在另┅个分支已经被改变了，那么就无法成功应用patch会提示冲突。gerrit未提供远程解决冲突的能力必须要在本地手动解决冲突。
假如要将master某个commit提茭到dev分支操作流程如下：
-
下载所有分支的最新代码
网上搜到的解释都是说pull是fetch+merge操作的合并。
那么到底是谁merge谁merge的过程中是否会产生新的提茭，产生的提交push的时候又是否会推送到远端呢
此时使用git pull拉取分支时，本地master直接更新为和远端master一样
将master推送到远端。
远端生成了一个新的提交
由于master指向的节点，是orgin/master指向的节点的子节点并无分叉，所以一定不会出现冲突
此时必须手动解决冲突。然后提交修改此时会产苼一个新的commit。
和上面的例子唯一的区别就是需要手动解决冲突然后提交commit。
如果此时再提交一个新的commit，然后推送到远端会推送几个commit呢？
实践了一下远端产生了两个提交。
git pull就是先获取远端分支然后将对应的远端分支merge到本地分支上来。
如果本地分支和远端分支已经分叉则会在本地分支上产生一个新的提交。
如果有冲突则需要手动解决冲突。
github什么情况下会产生冲突呢测试了一番，只有修改了同一个攵件就会产生冲突。
- 修改同一文件间隔很远的不同行
- 修改同一文件修改的内容完全一样
都提示冲突。但是在本地使用rebasemerge合并的时候，無需要手动解决冲突直接就自动合并完成了。
这一点gerrit似乎要机智一些，只要不是修改了文件的同一行就可以自动合入。
gerrit的展示不是佷准确commit的内容并不在当前分支也展示出来。而真正改变当前分支的merge …对应commit的改变却并没有提现出来
