带你理解 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 来合并功能分支，同一个冲突可能须要合并屡次。

总结

1. 若是有几个开发者同时在 feature 分支上开发，就不推荐使用 rebase，由于 rebase 会掩盖真实的提交场景。相对而言，我的开发更适合使用 rebase。
2. 若是你想保留完整的历史记录，就应该使用 merge。记住，Merge 保留历史记录，而 Rebase 改写历史记录

Rebase 能够用来精简一个复杂的历史记录，经过交互式 rebase，你能够去掉不想要的 commit，合并多个 commit 甚至修改 commit 信息。

须要注意的是，因为 rebase 是将 commit 一个一个应用到目标分支，因此在产生冲突时，须要针对 commit 一个一个去解决，而 merge 是将 commit 的最终结果合并到目标分支，因此冲突只须要解决一次便可。而若是有不少冲突的话，撤销一个 rebase 也将会很是困难。

参考文章

• 原文连接
• git-rebase vs merge
• git rebase vs git merge