3

我们在 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状态为EwithA*和D*applied 的标签。
    • 为了使它更复杂，提交E实际上是向后移植D到0.9分支上，所以我们的D*补丁也应该在这里应用
    • 这不是正确的合并或变基，因为上游项目在 SVN 中，这是我们正在分叉的 git-svn 镜像
  • 将来上游将分支0.10等，我们也希望在这些分支上维护我们的补丁

我可以通过大量采摘或手动应用补丁来做到这一点（我认为），但这感觉不对，我认为我没有充分利用 git。

4

1 回答 1

1

有两种方法可以做到这一点，并且正确地得到了它们 - 变基（包括cherry-pick和patch，最终结果相同）或合并。

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

策略之间的区别在于 for git pull，git 将尝试将远程更改合并到您的本地分支（导致您有很多 git merge 提交，但您的补丁 sha 将保持不变）并且 for git pull --rebasegit 将首先获取远程更改然后才尝试在顶部应用您的本地更改（导致每次拉动后您的补丁 sha 都会发生变化）。我认为 rebase 更合适（如果远程 repo 最初是 git，则此论点更强），因为您将始终留在项目的 HEAD + 您的补丁，而不会出现不必要的合并提交混乱。

于 2012-11-22T03:01:00.803 回答