温馨提示先行:
永远不要衍合那些已经推送到公共仓库的更新
如果把衍合当成一种在推送之前清理提交历史的手段，而且仅仅衍合那些尚未公开的提交对象，就没问题。如果衍合那些已经公开的提交对象，并且已经有人基于这些提交对象开展了后续开发工作的话，就会出现叫人沮丧的麻烦。
参考链接: Git 分支 - 分支的衍合
操作步骤:
- 初始状态描述: 远端有一个 develop 分支, 从 4c12e0a 节点拉2个本地分支, dev_1 & dev_2, 这2个本地分支为2个功能分支.
- dev_1 分支提交一次代码
- dev_2 分支提交一次代码
- develop 分支提交一次代码
- 此时, dev_1 开发完毕, 需将其合并到 develop (衍合rebase + 合并merge)
注: 此步骤的原理讲解在文末
5.1 rebase
当前分支: dev_1 (粗体表示)
基底分支: develop
操作: 鼠标在 develop 分支上右击, 出现以下弹框, 选中"将当前变更衍合到 develop", 下一步"确认衍合", 若出现冲突则解决冲突. 然后重复上述右击操作, 弹框选择"继续衍合". 衍合完成后, dev_1 分支跑到了 develop 分支的下游, 而且是一根直线哦.
5.2 merge
当前分支: develop (粗体表示)
操作: 鼠标在 dev_1 分支上右击, 出现以下弹框, 选中"合并 dev_1 至 develop", 下一步"确认合并", 进行一次 Fast forward. 合并完成后, develop 分支指向了 dev_1 分支的最新提交.
5.3 删除 dev_1 分支
功能分支合并到主分支后, 就没有存在的意义了, 可以将其删除.
此时, dev_2 也开发完毕, 需将其合并到 develop (衍合rebase + 合并merge)
重复 step 5 的步骤, 此处忽略操作描述.最终效果如下图
Step 5 原理介绍
把在 C3 里产生的变化补丁在 C4 的基础上重新打一遍. 在 Git 里, 这种操作较做衍合(rebase).
它的原理是, 回到2个分支最近的共同祖先, 根据当前分支 (也就是要进行衍合的分支 dev_1) 后续的历次提交对象 (这里只有一个 C3), 生成一系列文件补丁, 然后以基底分支 (也就是 develop) 最后一个提交对象 C4 为新的出发点, 逐个应用之前准备好的补丁文件, 最后会生成一个新的合并提交对象 C3’, 从而改写 dev_1的提交历史, 使他成为 develop 分支的直接下游, 如下图.
现在回到 develop 分支, 进行一次快进合并 (Fast forward). 此时, develop 分支指向了 C3’.
由于当前 develop 分支所在的提交对象是要并入的 dev_1 分支的直接上游, Git 只需把 develop 分支指针直接右移. 换句话说, 如果顺着一个分支走下去可以达到另一个分支的话, 那么 Git 在合并两者时, 只会简单地把指针右移, 因为这种单线的历史分支不存在任何需要解决的分歧, 所以这种合并过程可以称为快进 (Fast forward).
