代码整合：merge 和 rebase 一个是合并，一个叫“变基”
通过图片来看什么是变基：

两个分支合并的提交历史。 通过变基。变成线性的提交历史。 （上图例子）

变基的原理：临时保存一个分支的提交差异。 然后调整当前分支，最后再逐个应用差异。 参考： https://git-scm.com/book/zh/v2/Git-%E5%88%86%E6%94%AF-%E5%8F%98%E5%9F%BA

变基的应用场景： 像别人维护的项目贡献代码时

1. 自己首先在自己本地进行各种分支操作开发。
2. 开发完毕，变基到origin/master 然后提交。

否则你的 ease 分支将会是很多分支合并的结果。包含了很多枝节。通过变基，则你只会推送上去一个线性的记录。管理者也方便进行查看应用你的修改。

（限于篇幅，还是考虑省掉了这个例子） git rebase –onto master server client 选中 在 client 分支上的修改，并且不在 server 做处的修改（c3） 基于master 变基。 注意这里的关键是 选中的修改 是 server 和 client 的差异。 参考：https://git-scm.com/book/zh/v2/Git-%E5%88%86%E6%94%AF-%E5%8F%98%E5%9F%BA

案例 ：两个分支都修改了同一行代码。 然后进行变基操作。

....
冲突（内容）：合并冲突于 f1.py
error: 无法合并变更。
打补丁失败于 0001 f1 444
失败的补丁文件副本位于：.git/rebase-apply/patch

当您解决了此问题后，执行 "git rebase --continue"。 注意之前先 git add .
如果您想跳过此补丁，则执行 "git rebase --skip"。
要恢复原分支并停止变基，执行 "git rebase --abort"。

变基应用领域，通常是为了给比人贡献代码的时候，整理代码用的。

原则：

变基的仓库只此一份,如果这个仓库有其他副本。比如有和其他人分享代码。那么不要进行变基操作。总的原则是，只对尚未推送或分享给别人的本地修改执行变基操作清理历史，从不对已推送至别处的提交执行变基操作，这样，你才能享受到两种方式带来的便利。(多人协作时将会造成混乱) 除非所有人都：git pull –rebase 如果已经有问题，这是缓解之道。但不能彻底解决问题。（不建议！）