场景
首先我们来看一个场景
- 正常情况的我们分支合并之后应该就像这样的
正常分支合并
对于这样的分支合并大家一定没有异议。
- 那么碰到这种情况 怎么处理呢
Reset
当然 reset掉develop最上面的点，然后再行merge B即可
- 那么碰到这种情况 怎么处理呢
Rebase-Onto
方案A
将B-bugfix分支的所有代码保存下来，然后将develop回退回去，然后在正常merge之后再将B-bugfix分支的所有代码吐出来，然后再Commit一个点。
这样的话，能解决问题，但是所有的Commit将会变成一个点，虽然是Can，但不是Best。
方案B
直接将多出来的A分支再次合并到develop上。这样也能保证代码不丢失，但是相比之下 分支便不太规范。
最终方案
文档
Document
意思就是如果你想将topic分支移动到master上，你就可以通过rebase --onto 来实现。
git rebase --onto master next topic
意思就是 在master之上 把从next分支切出的topic分支 移动到master的最顶部
那么想想 对应上述情况怎么办呢。
Rebase-Onto
- 将develop回退到根节点
- 重新merge A和B
- git rebase --onto develop develop B-bugfix
- 可能会有冲突，解决冲突 git rebase --continue
另外场景
另外场景
原理
就拿上面场景为例。git rebase的时候，其实就是先从master分支上切出一个新的topicB作为工作目录，再将之前topicB上打补丁的点全部在新的topicB上全部打上。如果在打补丁的时候出现了冲突，git rebase就会停止，要求先解决冲突，然后在continue的时候就会继续将剩余的补丁点打完。最后新的分支取代了原来的分支。
