git中的 Merge 和 Rebase
概念
Rebase 和 merge 都被设计用来将变更从一个分支整合到另一个分支，但是它们的实现方式却不同。下面假如我们有如下提交，merge 会将两个分支的代码合并，而 rebase 会将 feature 分支上所有的变更在 master 分支上重新应用一遍：
- 当你将 feature 分支 rebase 到 master 时，实际上是将 feature 的 base 移动到了 master 分支的终点，所以 rebase 中文叫变基。（想象上图平移了两条线段）
- merge 则是拿 feature 分支中的结果，合并到 master 分支，这个过程中只有 master 分支改变了，feature 分支保持不变
- merge 的时候会产生一个新的 commit
Merge 的优与劣
优点
- 简单易用，易于理解
- 保留原始提交记录和源分支
- 源分支上的提交与其他分支分离，这会方便你浏览并且合并到其他分支
- 保留你的提交历史，保证提交历史在语义上的准确性
缺点
- 提交历史 可能会变得很乱，尤其是很多人同时开发与合并分支时
- 使用 git bisect 调试将变得困难
Rebase 的优与劣
优点
- 代码历史简洁，线性，可读性强
- 相比众多功能分支来说，只有一个分支，管理起来更加方便
- 简洁的 提交记录 让调试和排查更容易
缺点
- feature 分支变成了一些 commit，不利于体现开发时的场景
Rebase 不适合与 pull requests 同时工作，因为你看不出来哪里是别人做的变更。重写了历史记录也不利于团队协作
你在使用 rebase 时也应该更加小心
在处理 冲突 时需要花费更多的精力，使用 rebase 来合并功能分支，同一个冲突可能需要合并多次。
总结
如果有几个开发者同时在 feature 分支上开发，就不推荐使用 rebase，因为 rebase 会掩盖真实的提交场景。相对而言，个人开发更适合使用 rebase。
如果你想保留完整的历史记录，就应该使用 merge。记住，Merge 保留历史记录，而 Rebase 改写历史记录
Rebase 可以用来精简一个复杂的历史记录，通过交互式 rebase，你可以去掉不想要的 commit，合并多个 commit 甚至修改 commit 信息。
需要注意的是，由于 rebase 是将 commit 一个一个应用到目标分支，所以在产生冲突时，需要针对 commit 一个一个去解决，而 merge 是将 commit 的最终结果合并到目标分支，所以冲突只需要解决一次即可。而如果有很多冲突的话，撤销一个 rebase 也将会非常困难。
本文内容仅供个人学习、研究或参考使用，不构成任何形式的决策建议、专业指导或法律依据。未经授权，禁止任何单位或个人以商业售卖、虚假宣传、侵权传播等非学习研究目的使用本文内容。如需分享或转载，请保留原文来源信息，不得篡改、删减内容或侵犯相关权益。感谢您的理解与支持！