一、rebase
应用场景：合并分支,让日志显示更加人性化，方便回滚
一般我们合并分支，会使用merge命令,merge命令的原理如下，会在提交的分支后面再增加一个合并分支：
而如果我们使用rebase命令，会把公共分支放在当前分支之前。
rebase相对于merge的好处是日志更加清晰了，便于回滚。而坏处在于更容易引起冲突。
接下来我们做一个栗子，来说明一下情况。 我们新建一个分支master3，然后新建一个"readme.md"文件，写入一行内容，并且提交到资源库。
git checkout -b master3
echo readme > readme.md
git commit -am "init data"
使用更新日志如下：
接下来我们创建两个分支，分别取名 "merge-test"和"rebase-test"
git branch merge-test
git branch rebase-test
在master3分支新增三个提交"11","22","33"，日志信息与修改的信息相同。
echo '11' >> readme.md
git commit -am "11"
echo '22' >> readme.md
git commit -am "22"
echo '33' >> readme.md
git commit -am "33"
master3分支的日志如下:
readme.md文件内容如下:
现在我们切换到merge-test分支，和master3上做类似的操作，新增三个提交"aa","bb","cc", 日志信息与修改的信息相同。 然后合并到 rebase-test 分支。
git checkout merge-test
echo 'aa' >> readme.md
git commit -am "aa"
echo 'bb' >> readme.md
git commit -am "bb"
echo 'cc' >> readme.md
git commit -am "cc"
git checkout rebase-test
git merge/rebase merge-test
merge-test和rebase-test分支日志如下：
readme.md文件内容如下:
ps:当被合并分支（rebase-test）未做修改，则rebase和merge分支产生的日志一样。
现在准备工作已经做好了，现在我们分别用merge和rebase的方式把master3分支合并到merge-test和rebase-test中。
merge的栗子
先看merge合并, 会产生冲突。
git checkout merge-test
git merge master3
我们解决一下冲突，并查看一下日志：
git commit -am "merge"
git log --oneline --graph
我们发现这个日志文件分叉了，现在我们试着回滚到 "bb", 看会发生什么。
git reset --hard a01f4c27b2
git log --oneline --graph
日志文件如下：
readme.md文件如下：
我们发现之前从master3分支合并的代码没有了，需要再合并一次。如果合并的分支越多，情况很复杂，可能就比较难找到到底需要回滚到哪个分支了
rebase的栗子
现在我们来研究一下"rebase"。一样切换到rebase-test分支, 使用rebase 合并 master3分支。
git checkout rebase-test
git rebase master3
有冲突,我们发现是“aa”的提交与 master3上的提交相互比较
我们选择接受全部，并且把"aa" 放在 "11" 之前， 调整成如下样子：
然后我们解决一下冲突。
git add .
git rebase --continue
然后因为我们修改完的代码和 "bb"、"cc"比较都有冲突，按照上面的方式继续解决冲突，然后提交并继续git rebase --continue。最终解决好了之后，我们查看一下日志：
我们发现日志并没有分叉。现在我们试着回退到 "bb"
git reset --hard 10755375f1
我们发现master3分支上的内容依然保留着。
小结
1、rebase 和 merge 都可以用来合并分支
2.1）当被合并分支没有修改时，rebase和merge效果一样
2.2）如果两个分支都有修改，使用merge会在被合并分支后面增加一次提交， 冲突也只需要解决1次，但日志分叉，不对回滚不友好。
2.3）如果两个分支都有修改，使用rebase在把合并分支与被合并分支的提交逐个合并， 冲突有可能需要解决多次，但日志无分叉，对回滚友好。
2、rebase 和 merge如何区分使用
2.1） 上游分支往下游分支更新代码时使用 "rebase" (master 往 dev合并时)
2.2） 下游往上游更新代码时使用 "merge" （dev 往 master 合并时）
3、使用git pull 默认使用merge方式，如果需要使用 rebase 方式，使用命令 " git pull --rebase"
二、cherry-pick
此命令英译过来是挑樱桃的意思，就是在一些樱桃里面，挑选出好的樱桃。在git中，就是把A分支中一些需要的提交挑选出来合并到B分支上面。
我们先来用一个栗子，来看一下这个命令是怎么用的。
1、基本用法
我们还是用上一个节提到的master3分支，先新建两个分支 cp-master 和 cp-dev, 然后修改cp-dev，再把cp-dev中的某些修改合并到cp-master上。
git branch cp-master
git checkout -b cp-dev
然后新增三个次提交
1） 最后一行新增 “xyz”
2） 把 "xyz" 改成 "xyzo"
3） 第二行新增 "789"
echo xyz >> readme.md
git add .
git commit -m "xyz"
vi readme.md
## edit start ##
readme
11
22
33
xyzo
## edit end ##
git commit -am "xyz to xyzo"
## edit start ##
readme
789
11
22
33
xaz
## edit end ##
git commit -am "789"
最终的日志为如下
最终的文件内容如下：
接下来我们切换到 "cp-master"分支。
1）把第三次提交（789）更新到cp-master上
git checkout cp-master
git cherry-pick 6538e91943
git log --oneline --graph
2）把第二次提交更新到cp-master上
git cherry-pick 22140132aa
我们发现有冲突
解决一下冲突
git add .
git cherry-pick --continue
git log --oneline --graph
最后的文件如下：
我们对比发现两个分支的最后的文件基本相同，但是提交历史完全不一样。
2、Cherry pick 支持一次转移多个提交。
git cherry-pick <HashA> <HashB>
上面的命令将 A 和 B 两个提交应用到当前分支。这会在当前分支生成两个对应的新提交。
如果想要转移一系列的连续提交，可以使用下面的简便语法。
git cherry-pick A..B
上面的命令可以转移从 A 到 B 的所有提交。它们必须按照正确的顺序放置：提交 A 必须早于提交 B，否则命令将失败，但不会报错。
注意，使用上面的命令，提交 A 将不会包含在 Cherry pick 中。如果要包含提交 A，可以使用下面的语法。
git cherry-pick A^..B
3、代码冲突的解决
如果操作过程中发生代码冲突，Cherry pick 会停下来，让用户决定如何继续操作。
1）、--continue
用户解决代码冲突后，第一步将修改的文件重新加入暂存区（git add .），第二步使用下面的命令，让 Cherry pick 过程继续执行。
git cherry-pick --continue
2）、--abort
发生代码冲突后，放弃合并，回到操作前的样子。
git cherry-pick --abort
3）、--quit
发生代码冲突后，退出 Cherry pick，但是不回到操作前的样子。
git cherry-pick --quit
使用场景
cherry pick 最主要的使用场景大概有：
1、serverB开发的需求feature1，后来临时决定要把feature1单独上serverA，就可以用cherry pick把feature1的提交单独摘出来，合并到serverA
2、如果有切错分支的情况，比如上游分支原来是master，不小心切了dev分支，现在要更新到master上面，那只能用cherry-pick把需要提交找出来更新上去。
