分支切割机 git rebase onto

场景

首先我们来看一个场景

1. 正常情况的我们分支合并之后应该就像这样的

正常分支合并

对于这样的分支合并大家一定没有异议。

2. 那么碰到这种情况 怎么处理呢

Reset

当然 reset掉develop最上面的点，然后再行merge B即可

3. 那么碰到这种情况 怎么处理呢

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

1. 将develop回退到根节点
2. 重新merge A和B
3. git rebase --onto develop develop B-bugfix
4. 可能会有冲突，解决冲突 git rebase --continue

另外场景

另外场景

原理

就拿上面场景为例。git rebase的时候，其实就是先从master分支上切出一个新的topicB作为工作目录，再将之前topicB上打补丁的点全部在新的topicB上全部打上。如果在打补丁的时候出现了冲突，git rebase就会停止，要求先解决冲突，然后在continue的时候就会继续将剩余的补丁点打完。最后新的分支取代了原来的分支。

参考

https://git-scm.com/docs/git-rebase