我有两个分支:旧版本的 main 和最新版本的 dev。我需要跨这些分支有效地管理修补程序。具体来说,我需要:
确保应用于 main 的修补程序也合并到 dev 中的最佳方法是什么?
此外,虽然现在我在两个分支中都有相同的代码库,但由于合并请求的提交历史记录不同,我应该如何处理 dev 分支落后于 main 的情况?同步这些分支的最佳实践是什么?
我希望能够将修补程序合并到开发和主版本中。 如果有更好的方法,请推荐。
从分支策略的描述来看,您并没有真正使用 Git Flow,因为您似乎没有使用
release
分支,并且不清楚您如何从 dev
分支获取功能进入main
。但既然您标记了git-flow
,其中的相同概念将对您有所帮助:
dev
(类似于 Git Flow 中的 develop
),并使其足够稳定,以便 dev
上的所有内容都可以部署到生产中。为了做到这一点,您需要在某个时候停止新功能的开发(代码冻结),只专注于错误修复。创建 Git Flow 的主要原因之一是为了避免代码冻结,这是通过从 release
切下 dev
分支来解决的,然后您可以在 release
上进行错误修复,同时新的开发同时在dev
。dev
;如果您创建了代码,则为 release
)。然后将该稳定分支合并到 main
中。 (Git Flow 建议使用 --no-ff
进行此合并,以便历史记录的第一个父级向您准确显示每次部署到生产的内容。)将 release
或 dev
合并到 main
后,将 main
合并回 dev
。hotfix
时,在部署后将 hotfix
合并到 main
,然后将 main
合并到 release
(如果它处于待处理状态),或者 dev
(如果您没有待处理的 release
) 。 具体针对您的场景:如果您只有 dev
和 main
,则将修补程序合并到 main
后,将 main
合并回 dev
。外卖:
release
分支,main
永远不应该领先于 release
,除非在 main
合并到 release
之前合并到修补程序后大约一分钟左右。release
分支,main
永远不应该领先于 dev
,除非在 main
合并到 dev
之前合并到修补程序后大约一分钟左右。