我是版本管理工具 白痴
之前项目一直在SVN上，自己对SVN的理解，其实差不多就是小乌龟直接只用svn checkout 、commit，顶多在合并主干的时候需要merge下，解决完冲突提交，没有关心过其他的操作命令。后来项目逐渐切换到git上，自己除了git 比svn多了一步本地提交之外，其他的，其实还是小乌龟使用者，也没有关心过其他的操作。
git cherry-pick
cherry-pick的作用是，将某次或者某几次的提交,在另一个分支上进行重演
例如,我们有个稳定版本的分支，叫v2.0，另外还有个开发版本的分支v3.0，我们不能直接把两个分支合并，这样会导致稳定版本混乱，但是又想增加一个v3.0中的功能到v2.0中，这里就可以使用cherry-pick了.
$ git checkout v2.0分支
$ git cherry-pick 38361a55 # 这个 38361a55 号码，位于v3.0分支中：
也可以 按照提交记录，提交多个记录
$ git checkout v2.0分支
$ git cherry-pick 38361a55 38361a5aaa 38361a57adfd 38361abbb
如果遇到了冲突，那么可以在手动解决完冲突后，自己使用git cherry-pick --continue继续，也可以放弃git cherry-pick --aboart，这时候的放弃操作不会对之前的分支造成任何影响
git rebase or git merge
含义：git merge b or git rebase b 将b这个分支合并到当前分支
原理：
远端分支 origin 在c2commit时创建mywork分支如图所示
但是与此同时，有些人也在"origin"分支上做了一些修改并且做了提交了. 这就意味着origin和mywork这两个分支各自"前进"了，它们之间"分叉"了。
在这里，你可以用"pull"命令把"origin"分支上的修改拉下来并且和你的修改合并； 结果看起来就像一个新的"合并的提交"(merge commit)。
但是，如果你想让"mywork"分支历史看起来像没有经过任何合并一样，你也许可以用 git rebase:
$ git checkout mywork
$ git rebase origin
当'mywork'分支更新之后，它会指向这些新创建的提交(commit),而那些老的提交会被丢弃。 如果运行垃圾收集命令(pruning garbage collection), 这些被丢弃的提交就会删除. （请查看 git gc)
在rebase的过程中，也许会出现冲突(conflict). 在这种情况，Git会停止rebase并会让你去解决 冲突；在解决完冲突后，用"git-add"命令去更新这些内容的索引(index), 然后，你无需执行 git-commit,只要执行:
$ git rebase --continue
这样git会继续应用(apply)余下的补丁。
在任何时候，你可以用--abort参数来终止rebase的行动，并且mywork 分支会回到rebase开始前的状态。
$ git rebase --abort
当我们使用Git log来参看commit时，其commit的顺序也有所不同。
假设C3提交于9:00AM,C5提交于10:00AM,C4提交于11:00AM，C6提交于12:00AM,
对于使用git merge来合并所看到的commit的顺序（从新到旧）是：C7 ,C6,C4,C5,C3,C2,C1
对于使用git rebase来合并所看到的commit的顺序（从新到旧）是：C7 ,C6‘,C5',C4,C3,C2,C1
因为C6'提交只是C6提交的克隆，C5'提交只是C5提交的克隆，
从用户的角度看使用git rebase来合并后所看到的commit的顺序（从新到旧）是：C7 ,C6,C5,C4,C3,C2,C1
现在我们可以看一下用合并(merge)和用rebase所产生的区别：
首先，他们的操作是基于分支的。
merge会造成多一次的commit提交记录，并且提交记录是按照各个提交时间排列的。
rebase不会造成多一次的committ提交记录，并且b分支的所有commit顶到最顶端。
merge操作只需要解决一次冲突，但对这个分支的纯洁性是有毁灭性的，如果merge发现冲突过多，回滚起来麻烦。
rebase操作则可能基于某个文件解决多次冲突，如果发现冲突过多，如上图记录，6次冲突（还好），随时可以abort 恢复原来的状态
假设，我们团队有三个分支：
- master:线上环境分支
- dev分支：长线开发分支，同事1在该线上开发
- dev1分支：同事2开发分支
如果master分支更新（发版，bug解决），则对于dev1和dev分支的同事，可以使用rebase master，这样保持了和master的最新代码，且让本分支提交的commit都在master分支更新commit值之上，保证了该开发分支代码提交的逻辑的一致性。
开发后期，dev的同事和dev1的同事都完成提测，并需要合并master，怎么做呢？
- dev1 rebase master,保证获取到master最新代码，然后切换到master,merge dev1，形成多一次提交记录，记录dev1的合并;
- dev同事此时 rebase master，将dev1同事合并master后的代码提交记录都置于本分支提交之下，解决完冲突后提交，切换master, merge dev，形成多一次的提交记录，记录dev的提交。
此时，两个开发的需求都合并到了master，同时也保持了master提交记录上分为两大块，dev1的提交合并记录，之上是dev的提交合并记录
简书 git cherry-pick 使用指南
[Git Community Book 中文版] rebase
Git中分支merge和rebase的适用场景及区别
知乎：在开发过程中使用git rebase还是git merge，优缺点分别是什么？
