3

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

初始存储库结构

上游结构非常简单:

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

问题

上游项目增加了提交中的依赖版本,AD这些主要是为了方便,我们确信我们可以在一段时间内保持兼容性版本。

我创建了一个功能分支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通过变基或合并来跟踪和维护我的补丁,这取决于我是否发布。

我们的目标是为两个分支 (trunk0.9) 维护这些补丁,并重新创建一个发布版本0.9(因为它是从 标记的E)。

我不知道如何正确地做到这一点。

  • 我需要一个0.9_compat包含所有提交G但还包含我们的补丁的分支A*D*因此我们可以将它放入我们的持续集成服务器中,看看它是否有效
  • 我需要一个0.9_compat状态为EwithA*D*applied 的标签。
    • 为了使它更复杂,提交E实际上是向后移植D0.9分支上,所以我们的D*补丁也应该在这里应用
    • 这不是正确的合并或变基,因为上游项目在 SVN 中,这是我们正在分叉的 git-svn 镜像
  • 将来上游将分支0.10等,我们也希望在这些分支上维护我们的补丁

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

4

1 回答 1

1

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

  1. 设置您需要修补的所有分支并应用补丁(origin/trunkorigin/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 回答