并行维护多个开发分支（和标记）的多个补丁/功能分支

Question

我们在git（hub）中分叉了一个项目，并希望在我们的fork中维护一些补丁，同时在它们的发行版（标签）和发布分支中重新创建这些补丁。

初始存储库结构

上游结构非常简单：

origin/trunk A---B---D---F---H---...
                  \
origin/0.9         C---E---G---...
                       |
                   (tag 0.9)

问题

上游项目增加了提交A和D中依赖项的版本，但这些主要是为了方便，我们确信我们可以暂时维护兼容性版本。

我已经创建了一个功能分支trunk_compat，并使用git revert --no-commit为我们需要的提交A和D创建补丁。我已将此分支origin/trunk

mine/trunk_compat              A*---D*
                              / 
origin/trunk A---B---D---F---H-...
                  \
origin/0.9         C---E---G---...
                       |
                   (tag 0.9)

所以现在我很容易跟随origin/trunk并通过变基或合并来维护我的补丁，具体取决于我是否发布此内容。

我们的目标是为两个分支（trunk和0.9）维护这些补丁，并重新创建0.9的发布版本（因为它是标记自E）。

我不知道怎么做到这一点。

• 我需要一个0.9_compat分支，其所有提交最多为G，但也包含我们的补丁A*和D*，因此我们可以将其添加到我们的持续集成服务器中看看它是否有效
• 我需要一个标记0.9_compat，其状态为E且A*和D*已应用。
  • 为了使其更复杂，提交E实际上是D在0.9分支上的后端，因此我们的D*补丁也应该在此处应用
  • 这不是一个合适的合并或rebase，因为上游项目在SVN中，这是git-svn镜像，我们正在分析
• 将来上游将分支0.10等，我们也希望在这些分支上维护我们的补丁

我可以通过樱桃选择或者手动应用补丁来实现这一点（我认为），但这感觉不对，我认为我没有充分利用git。

Answer 1

有两种方法可以做到这一点，你得到了正确的 - rebase（包括cherry-pick和patch，最后结果相同）或者合并。

1. 设置您需要修补的所有分支并应用修补程序（origin/trunk和origin/0.9_compat）。
2. 在分支上应用补丁
3. 区别仅在于维护策略，这些分支是git pull（合并）与git pull --rebase（rebase）。

策略之间的区别在于，对于git pull，git会尝试将远程更改合并到您的本地分支中（导致您有很多git merge提交，但是您的补丁sha将保持不变）并且对于git pull --rebase，git将首先获取远程更改，然后尝试在顶部应用您的本地更改（导致每次拉动后修补程序更改）。我认为rebase更合适（如果远程repo最初是git，这个参数会更强），因为你将永远留在项目的HEAD +你的补丁，没有不必要的合并提交混乱。