在多个开发分支（和标签）中同时维护多个补丁/特性分支

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*。

未来，上游将分支0.10等，我们也想在这些分支上维护我们的补丁。

我可以使用很多cherry picking或仅手动应用补丁（我想），但这感觉不对，我认为我没有充分利用git。

- Lars Francke

---

除了在这里挑毛病，我什么都不知道更好的方法。 - Hugo

谢谢。我现在也走了这条路。看起来有点笨重，但似乎可以工作。对于已经存在的分支，我挑选了我的补丁，然后重新进行了基础变换，以便它们按正确的顺序排列。 - Lars Francke

Answer 1

有两种方法可以做到这一点，你已经正确地掌握了它们 - 变基（包括樱桃选取和补丁，在最后得到相同的结果）或合并。

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

策略之间的区别在于对于 git pull，Git 将尝试将远程更改合并到本地分支中（导致您有大量 Git 合并提交，但您的补丁 sha 保持不变），而对于 git pull --rebase，Git 首先获取远程更改，然后再尝试在其上应用本地更改（导致每次拉取后您的补丁 sha 都会发生变化）。我认为变基更合适（如果远程仓库最初是 Git，则这个论点更加有力），因为您始终会停留在项目 + 您的补丁的 HEAD，而不会有不必要的合并提交混乱。

- Titas