我们在 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
withA*
和D*
applied 的标签。- 为了使它更复杂,提交
E
实际上是向后移植D
到0.9
分支上,所以我们的D*
补丁也应该在这里应用 - 这不是正确的合并或变基,因为上游项目在 SVN 中,这是我们正在分叉的 git-svn 镜像
- 为了使它更复杂,提交
- 将来上游将分支
0.10
等,我们也希望在这些分支上维护我们的补丁
我可以通过大量采摘或手动应用补丁来做到这一点(我认为),但这感觉不对,我认为我没有充分利用 git。