写在前面：
现在还只是杂乱的记录，部分内容在公司，需要时间手工搬运出来…
普通合入引发的冲突
方法1(推荐)：使用rebase
- git fetch
下载所有分支的最新的远端分支（看一下如何下载某个特定分支） - git rebase origin/master
以origin/master分支为基线，合入master分支的修改。
手动解决冲突 - git add -A;git rebase --continue
冲突解决完成之后，提交修改 - git push origin master:refs/for/master
推送到远端服务器
方法2:使用merge
- git fetch
下载所有分支的最新的远端分支（看一下如何下载某个特定分支） - git checkout origin/master
直接切到远端的master分支 - git merge master
将master分支的修改合入
手动解决冲突 - git add -A;git commit
提交修改 - git push origin HEAD:refs/for/master
推送到远端服务器
cherry-pick
cherry-pick是在服务端进行操作的，完全不涉及本地分支。
cherry-pick的原理可以简单理解为：
将两个提commit之间的差异（patch）应用到另一个分支上。那么，如果如果patch对应的源文件对应的行在另一个分支已经被改变了，那么就无法成功应用patch，会提示冲突。必须要在本地手动解决冲突。
假如要将master某个commit提交到dev分支，操作流程如下：
- git fetch
下载所有分支的最新的远端分支（看一下如何下载某个特定分支） - git checkout -B dev origin/dev
直接用远端的dev分支覆盖本地的dev分支 - git checkout dev
切换到dev分支 - git cheery-pick commitId
手动解决冲突 - git add -A;git commit
提交修改 - git puhs origin dev:refs/for/dev
git pull
网上搜到的解释都是说pull是fetch+merge操作的合并。
那么到底是谁merge谁，merge的过程中是否会产生新的提交，产生的提交push的时候又是否会推送到远端呢？
实践一下：
1. origin/master比master多一个节点
此时使用git pull拉取分支时，本地master直接更新为和远端master一样。
2. orgin/master 和master分叉以后，各自多了一个节点,并且无冲突
然后进行pull操作，会发现在本地的master分支上形成了一个新的提交，对应的message为：Merge branch ‘master’ of https://github.com/copbint/blogs
origin/master并未发生改变。
图示：
将master推送到远端。
远端生成了一个新的提交。
由于master指向的节点，是orgin/master指向的节点的子节点，并无分叉，所以一定不会出现冲突。
再执行git pull将远端最新代码取下来，master和origin/master都指向了最新的提交。即D‘
3. orgin/master 和master分叉以后，各自多了一个节点,有冲突
执行，git pull报冲突：
此时必须手动解决冲突。然后提交修改。此时会产生一个新的commit。
和上面的例子唯一的区别就是需要手动解决冲突，然后提交commit。
如果此时，再提交一个新的commit，然后推送到远端。会推送几个commit呢？
实践了一下，远端产生了两个提交。
4. 总结
git pull就是先获取远端分支，然后将对应的远端分支merge到本地分支上来。
如果本地分支和远端分支已经分叉，则会在本地分支上产生一个新的提交。
如果有冲突，则需要手动解决冲突。
临时记录
在某个不用的服务上创建两个test分支，用完之后可以删除掉。
test_MASTER_test
test_DEV_test
gerrit的展示不是很准确，commit的内容并不在当前分支也展示出来。而真正改变当前分支的merge …对应commit的改变却并没有提现出来。