短期分支rebase, 长期在外分支先merge --squash 到新分支, 在rebase, 完美解决rebase解决冲突繁琐的问题
大家好，我是比特桃。Git 作为现在最流行的版本管理工具，想必大家在开发过程中都会使用。由于 Git 中很多操作默认是采用 Merge 进行的，并且相对也不容易出错，所以很多人都会使用 Merge 来进行合并代码。但Rebase 作为 Git 中主要命令之一，我们还是有必要了解一下，在适合的场景中进行使用。
Rebase 中文翻译过来：变基，我觉得这个翻译挺生硬的，导致很多人没有彻底理解变基的含义。我个人把 Rebase 意为 认爸爸，比如可以 Rebase 到马爸爸分支上，成为他的合理继承人。
上图为一次 Rebase 的情况，可以看到最终效果仿佛 Feature 分支没有存在过，新提交的 Commit 像真的在主分支上提交一样。而如果我们用 Merge 就会产生一个合并节点：
可能只看到一次合并所产生的 Commit 节点并没有什么，但实际项目中大概率会变成这样：
简直是乱的一批，仿佛看到了多年前其他人写的一堆代码，啥啥啥，这都是啥！反过来看看采用 Rebase 开发的真实项目，没有对比就没有伤害：
这也是为什么尤雨溪也比较推荐使用 rebase的原因：
其实很多人不用 Rebase ，一方面是不了解实际项目协同中怎么用。另一方面是用了，但问题很多，所以就误认为不好用从而再也不用。这里分享一下，我最近在做项目时所采用 Rebase 方面的协同流程（为了好说明，适当的进行了简化）：
首先，我们想从 master 分支上开发新的功能或者修复 bug ，需要 checkout出来一个分支。比如在
A节点中 checkout dev 分支，为了让场景更复杂，在 git checkout dev 分支后。master 上继续有人提交了B、C，形成如下Git 结构：