Git:在临时环境中使用 nvie 的 gitflow 概念

Dr.*_*lch 5 git version-control branching-and-merging

我们使用nvie 的 gitflow作为 git 分支策略的模式,并或多或少地遵循它。

主要区别在于临时环境,我必须将其集成到现有策略中。

一开始是相当简单的。暂存只不过是一个简单的分支,我们可以与新的发布分支合并。将其推送到 origin/stageserver 并在暂存期间执行我们想要执行的操作。到目前为止,一切都很好。

但是,假设我们在暂存中发现了一些我们想要纠正的内容(小错误修复,甚至可能是新集成功能中的错误?)。对我来说,目前尚不清楚处理此案的好策略是什么。

我目前的想法围绕以下策略:

  • 从 origin/staging 创建分支 staging_fix
  • 纠正错误
  • 重新运行暂存过程+测试
  • 将 staging_fix 分支与release分支合并
  • 从原点拉出发布分支
  • 根据 nvie 继续使用 gitflow,因此为生产等准备发布分支...

你认为这是个好主意吗?这将导致对登台分支的直接更改,这对我来说似乎是一条捷径,因为我必须直接修改登台环境 - 这是你不会对生产环境做的事情,而且我希望登台也能如此尽可能地投入生产。

或者,可以直接更正发布分支,并一次又一次地将其推送到暂存阶段,直到解决所有错误。至少现在我们有了一条进行改变的单行道。

您更喜欢哪种方式?您会在这里建议一种不同的策略吗?

Von*_*onC 2

这似乎是一个很好的策略,因为:

  • 它将暂存(及其关联的合并工作流程)隔离在存储库(在暂存服务器上)中
  • 它允许从临时服务器中提取您需要重新集成并合并回您自己的开发存储库的内容。

如果在暂存存储库中完成的修复(而不是在存储库中完成的修复并推送到暂存)花费太多时间,并且合并回变得过于复杂(因为代码修改存在很大差距),这只会变得很麻烦。