经常面临复杂的分支管理，这里对几种场景的行为做一些验证。

结论总结

• git rebase br_name：等价与新建br_name分支，然后找到当前分支与br_name分支的分叉点。然后把分叉点以后的提交（当前分支）一个一个的cherry-pick过来。
• cherry-pick的提交commit id会变，所以rebase后面拿过来的提交commit id也会变。
• 新版本去rebase旧版本，新的提交commit id都会变，rebase完了覆盖新版本，不会有什么问题。
• 旧版本去rebase新版本，旧的提交commit id都会变，rebase之后，如果其他分支rebase旧分支，因为旧分支的一部分commit id变了，会导致分叉点计算会提前很多，会有大量冲突，很难解决。
• 总结下来
  1. 单个活跃分支+多个较稳定分支是比较合理的，常见，符合直觉，好管理。
  2. 两个活跃分支，要确定两个分支的包含关系：
     • 如果要始终保持同步，那为什么用两个呢？可以删掉一个分支。
     • 如果一个新特性分支，一个bug修复分支，要确定同步方向，应该是新特性分支定期rebase bug修复分支。不要反着来。
  3. 三个或三个以上的活跃分支：分支管理成本会很大，需要花费大量时间处理rebase冲突、回合等问题。尽量避免。

rebase场景一：rebase分支带着cherry-pick，rebase后commit id会变吗？

• 场景：分支四 rebase 分支一
• 结论：
  1. rebase后，先找到分叉点Y。以分支一为基础，把分叉点Y后面，分支四的提交O、C、P分别cherry-pick过来。
  2. 注意C提交，虽然之前是cherry-pick过去了，但是因为commit id变了，rebase的时候也会当做一个新的commit被拿过来。
  3. commit id变了吗？
     • 分之一的所有commit id都没变，因为用的分支一做的基线，只是checkout分支一，所以不会变。
     • 分支四的虽有commit id都变了，因为rebase等于找到分叉点然后自动cherry-pick，所以会变。
• 结果：B4继承了B1，并有自己的提交O、C、P。
  

rebase场景二：验证上面结论

• 场景：分支三 rebase 分支一
• 结论：
  1. 分叉点是A，以分支一为基础，cherry-pick分叉点后分支三的提交。
  2. 解决E、F、L、M的冲突后合入。
  3. E、F、L、M提交的commit id都变了。
• 结果：分支一为基础，上面多了四个提交=分支三。