如何使用Git标准工具同时对长期feature branch执行rebase与反向合并操作

如果你持有一个长期迭代的功能分支，在不需要合入主发布分支的前提下，有两种标准方案可以让它和主发布分支保持同步：

• 定期把功能分支基于主发布分支执行rebase操作
• 把主发布分支的改动反向合并到你的功能分支中

rebase操作会把如下提交结构：

A - - - 主分支
 \
  \-1-2-3-功能分支

转换为：

A - - - 主分支
         \
          \-1'-2'-3'-功能分支

其中1'、2'、3'是原始提交1、2、3经过rebase后的新版本。

反向合并操作则会把结构转换为：

A - - - 主分支
 \          \
  \ -1-2-3-  X - 功能分支

其中X是合并提交，它的父节点同时包含主分支和原始功能分支的最新提交。

rebase方案的一个明显缺点是，所有持有功能分支本地副本的开发者都会遇到提交不匹配的问题：他们本地的1、2、3提交和远程rebase后的新提交没有关联，拉取代码时会出现大量看似无关的改动冲突。
但rebase也有不可忽视的优势：所有提交都是基于最新主分支重新生成的，你可以逐个回滚提交，单独验证每个改动在当前主分支上的运行表现。

能不能用标准Git工具同时兼顾两种方案的优势，既保留和原始功能分支的提交关联，又生成一组基于当前最新主分支的提交？

你想要的提交结构应该是这样的：

A - - - 主分支
 \        \ 1'-2'-3' -
  \                   \
   \ -1-2-3----------- X - 功能分支

这个场景下，X的文件内容和反向合并场景的X完全一致，唯一区别是它的父节点同时包含原始功能分支提交、以及rebase生成的新提交链的末端。

这种方式既保留了rebase工作流的优势，也不会影响其他持有原始功能分支副本的开发者：当他们往上游功能分支合并代码时，Git可以完整识别所有提交的关联关系，不会出现重复提交或者无关冲突。

比如有开发者基于原始功能分支的3提交做了二次开发：

A - - - 主分支
 \        \ 1'-2'-3' -
  \                   \
   \ -1-2-3----------- X - 功能分支
           \- 第三方开发者提交

这个第三方提交有清晰的合并路径可以同步到最新的功能分支版本，完全避免了传统rebase场景下的合并混乱问题：

A - - - 主分支
 \        \ 1'-2'-3' - 功能分支
  \                  
   \ -1-2-3-- 旧功能分支副本
           \- 第三方开发者提交

内容的提问来源于stack exchange，提问作者Yakk - Adam Nevraumont