当您有一个长期存在的功能分支时，有两种标准方法可以使其与主发布分支保持同步，而无需实际将代码放入主发布分支。
定期根据主发布分支重定功能分支的基数，或者将主发布分支中的更改反向合并到功能分支。
变基转换以下内容：
A - - - PRIMARY BRANCH
-1-2-3-FEATURE BRANCH
进入这个：
A - - - PRIMARY BRANCH
-1'-2'-3'-FEATURE BRANCH
其中1'2'3'是原始123的重定基版本。
合并将其转换为
A - - - PRIMARY BRANCH
-1-2-3- X - FEATURE BRANCH
其中X是一个合并提交，它在主分支和原始功能分支中都有父项。
变基解决方案的一个缺点是，拥有功能分支副本的人现在有一组看似无关的更改，因为他们的12和3与变基后的 CL 不同。
变基案例中的更改反映了主分支上"就像您在变基时所做的那样"的更改。 这有一些不错的属性，就好像您可以一次回滚一个更改并查看它们在当前主分支中的行为方式一样。
问题
有没有一种简单的方法使用标准 git 工具同时执行这两项操作，同时保持与原始功能分支的连接，以及一组表示针对当前主功能执行操作的 CL？
A - - - PRIMARY BRANCH
1'-2'-3' -
-1-2-3----------- X - FEATURE BRANCH
在这种情况下，X将与反向合并方案中的X具有相同的内容，但它还声明原始功能分支是父 CL。
由此，我们将获得变基工作流程，但其他有权访问原始功能分支的人不会被放弃——如果他们针对上游 FEATURE 重新合并，git 完全了解发生了什么。
A - - - PRIMARY BRANCH
1'-2'-3' -
-1-2-3----------- X - FEATURE BRANCH
- 3rd party
第三方 CL 有一个清晰的合并路径，可以移动到功能分支的尖端，而不是
在A - - - PRIMARY BRANCH
1'-2'-3' - FEATURE BRANCH
-1-2-3-- OLD FEATURE BRANCH
- 3rd party
传统的变基。
有没有一种简单的方法使用标准 git 工具同时执行这两项操作... ？
是的，您可以完全按照您的建议轻松创建图表：
git fetch
git checkout feature
git branch feature-old-copy # create a copy of feature
git rebase origin/primary
git merge --strategy=ours feature-old-copy
请注意，最终合并应该没有效果;即，除了将旧的提交 ID 集保留在分支中之外，这是一个毫无意义的合并......
但是，恕我直言，我认为您首先错误地确定了选择变基的主要原因。您的陈述：
变基案例中的更改反映了主分支上"就像您在变基时所做的那样"的更改。这有一些不错的属性，就好像您可以一次回滚一个更改并查看它们在当前主分支中的行为方式一样。
合并也是如此。(您可以还原提交，无论它是使用变基重写还是合并，尽管变基确实有一点好处。变基的主要好处是历史记录更干净，没有(通常)不必要的多个合并提交。例如，当我使用变基工作流时，我通常每天多次变基到未来的目标分支。如果我的分支持续 2-3 天，我已经在我的分支上保存了大约 10 个不必要的合并提交。使用您建议的工作流程，您并没有真正获得变基的好处，因此我认为它没有那么有用。
所以，是的，你可以做到，但我质疑这样做的价值。
*在合并下还原单个提交可能需要在合并时发生的返工冲突，而使用变基时，它们已经得到解决，并且更有可能干净地还原。