【发布时间】:2013-04-07 22:06:10
【问题描述】:
我们正在使用 git-flow 来处理修补程序和功能,并带有一个开发分支和主分支(用于生产)。
向混合中添加临时分支的最简单方法是什么,以便我们可以验证从开发到生产的工作,同时仍然保持 git-flow 的有用性?
【问题讨论】:
标签: git branching-and-merging git-flow
我们正在使用 git-flow 来处理修补程序和功能,并带有一个开发分支和主分支(用于生产)。
向混合中添加临时分支的最简单方法是什么,以便我们可以验证从开发到生产的工作,同时仍然保持 git-flow 的有用性?
【问题讨论】:
标签: git branching-and-merging git-flow
我会说 staging 应该基于 git flow release 分支。在 git flow release start 和 git flow release publish 之后,您可以在该分支上开始 QA 工作,包括将其部署到暂存区。当暂存区域中的 QA 工作已证明代码已准备好用于生产时,请在生产中部署并执行git flow release finish。
如果您使用的是 TeamCity,您可以轻松设置服务器以检测新的远程发布分支并自动为其设置构建,see here。
【讨论】:
git flow release finish 时,正常使用 git-flow 会删除分支并在你 git flow release start 时重新创建它
我刚刚开始使用 git flow,但恕我直言,最简单的方法是将 下一个版本 设置为 dev 分支,生产版本 设置为 stage 分支,然后例如:手动与master 分支合并(你的真实生产)。
因此,如果您将版本 1.2.0 发布到 stage,然后在您的版本中发现错误(4 个修补程序,例如:在核心 CMS、功能 1、功能 3 和功能 4 中),那么您可以随时应用补丁,例如您可以结束升级到 1.2.4 版,然后最终将其合并到生产环境中。
更新:这种情况假设您没有回滚机制,因此您总是添加 提交以修复、发布功能或其他任何内容。如果您确实有回滚机制,那么您无需担心生产中的错误。就在您发现错误时,使用回滚来设置以前的工作版本。例如:如果您在版本 1.2.3 中发现错误,请返回版本 1.2.2。修复错误,在dev 上进行测试,然后在stage 上进行测试,并以版本1.2.4 推送到生产环境。所以你的作品将从1.2.2直接跳到1.2.4。
【讨论】: