git merge一般只适用于为了保留将所有历史，而将分支的整个特性集合并到另一个分支中。除此以外的其他use case最好使用rebase的几种方式来实现：
- 经典的
- 三点的
- 交互的 interactive
- 筛选方式 cherry-pick
Git 用户最重要的技能莫过于维护一个简洁，清晰的提交历史。为了实现这一目标，需要用到以下工具：
git commit --amend
git merge (--no-ff)
git rebase
主要使用：git rebase -i 和 git rebase -p
git cherry-pick (配合rebase使用)
什么情况下适用于merge
执行merge操作，主要是为了将我们当前的branch提交居前。你需要问一个问题：“这个待merge的其他分支为什么存在或者建立的？”
- 本地/临时的分支
如果这个分支只是为了master提交更简洁而单独拉出来的分支
1）假设现在master分支有新的commit，那这个临时分支为了保持更新，需要执行rebase使得提交在最新的master之上。假设
2）假设master分支没有产生新的commit，那么执行merge ff足以。 - 重要的分支
重要的分支一般是团队认定的分支，敏捷开发中一般依据的Sprint/Story/Feature来定义。而在bug追溯系统中一般用issue来定义。
如果此时master分支自从branch out这个新分支时，并未有新的提交，那么直接请使用merge而不是rebase，并且使用 --no-ff（该分支中间的commits在master不可见，从而保持master简洁）
什么情况下适用于rebase
顾名思义，rebase=改变branch的base。
- 当准备push到远程分支时，如果已经有别的成员push了新的提交，系统会拒绝你的push请求。此时如果执行pull --> merge，将会导致提交历史不够简洁。这种情况就适合rebase来实现。
- 还有一种情况，当有一个新的idea，从而建立一个新分支，但是过了很久以后，才有时间继续进行。这时候，master分支已经有了长足进步，可能fix了一些bug，也可能有其他的改进，如果你想让你的idea基于最新的成果，那么rebase也是不二之选。
- 最后一种非常常用的，不过目的时为了让历史commit更加简洁，在开发过程中，可能会在分支中commit非常频繁，比如为了修改一个bug，可能会commit多次，这将会导致提交的历史不够简洁，因此在把上述push到远程分支的时候，就可以使用rebase来合并多次commit为1次。
git rebase -i HEAD~x #x代表合并之前的几个commit
使用规则建议
- 合并一个本地临时分支
为了不把本地的提交历史呈现在master分支，需要在ff合并之前rebase - 合并一个本地重要分支
如果要让从头到尾的所有commit呈现，则执行merge - 在将本地工作push之前，先把本地历史处理简洁
- 当push操作因为分支有新提交而导致冲突时，首先rebase基于远程更新后的分支
网友评论