我们在git(hub)上fork了一个项目,希望在我们的分支中维护一些补丁,并同时在它们的发布(标签)和发布分支中重新创建这些补丁。
现在,我可以很容易地遵循
我们的目标是为这两个分支(
但我不知道如何正确地做到这一点。
我需要一个
我需要一个标签
未来,上游将分支
我可以使用很多cherry picking或仅手动应用补丁(我想),但这感觉不对,我认为我没有充分利用git。
初始仓库结构
上游结构非常简单:
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。