为预生产环境调整 git-flow 模型

Question

由于特定情况，我正在考虑为我当前的工作场所扩展 git-flow 模型。但是我的情况是如此普遍，以至于我很惊讶以前没有人用 git-flow 模型做过这件事，这让我觉得我错过了一个明显的问题。我的问题是：我提议的扩展是否有缺陷？

场景：我有多个开发团队从一个共同的代码库开发，我们通过几个（永久）环境发布版本：首先是系统集成环境 (SIT)，然后是 UAT 环境，然后是预生产，最后生产。这是严格顺序的，尽管任何候选版本都可能在任何环境中失败，因此不会再进一步​​。因此，以后的每个环境都只是先前环境的一个较慢的版本。

我们正在引入 git 进行源代码控制，我们需要一个工作流，而 git-flow 看起来是一个好的开始。

我们问自己如何随时捕捉（即如何知道）每个环境中的内容。 git-flow 模型似乎本质上有两个核心状态：master 和develop。他们有一个“无限的寿命”。其他分支只是"supporting branches"，具有“有限的生命时间”。它们的存在只是为了允许开发和从开发到生产（通过临时发布状态）。 git-flow 模型基于从开发到发布。

但是，这并没有从逻辑上映射到我们的场景，它具有多阶段的发布顺序。当然，我对develop 分支很好。 master 分支显然映射到我们的生产环境。 original git-flow description 这么说 master:

因此，每次将更改合并回 master 时，这是一个新的 生产版本根据定义。我们往往对此非常严格，因此 理论上，我们可以使用 Git 钩子脚本来自动构建和推出 每次在 master 上提交时，我们的软件都会发送到我们的生产服务器。

由于master 是生产的连续记录，我们应该扩展 git-flow 模型 为 SIT、UAT 和 pre-prod 拥有相应的分支似乎是一致的。毕竟，它们是永久环境，具有严格的发布程序。它们只是比生产快一点。

这些额外的永久分支位于develop 和master 之间，就像它们对应的环境一样。

这意味着现在可以轻松跟踪每个环境的版本以及每个环境的状态。每个分支的合并也更容易：SIT 分支需要来自 develop 的合并，UAT 分支需要来自 SIT 分支的合并，pre-prod 分支需要来自 UAT 分支的合并，最后是 master分支（用于生产）需要从 pre-prod 分支合并。后面的每个分支都只是前一个分支的移动速度较慢的版本。

我错过了什么吗？

Answer 1

我认为没有理由根据您的模型调整流程。你说你按顺序工作 SIT -> UAT -> Pre-Prod。完美的。一旦开发稳定（即所有要发布的功能都是功能完成[ed]），然后执行release start 并将其移至您的 SIT 平台进行 QA。发布开始后，可以在 develop 分支上继续开发。 master 在发布完成之前保持静态。

一旦 QA 得到满足，发布分支就会转移到 UAT。 UAT 通过并且代码开始运行，您执行release finish 以合并回主/开发。

master 应始终反映当前实时平台上的内容，而 develop 反映正在积极开发的代码。 release 分支包含开发的静态剪辑，应用了错误修复（没有新功能永远被推送到此分支，或者您没有使用 git-flow）。

根据您的描述，我倾向于说您误解了 git-flow 模型，因为据我所知，它非常适合您描述的场景，在 SIT -> UAT 期间您需要关心的一切-> Pre-Prod 是发布分支，“忘记” master/develop 在这个阶段甚至存在。

对 cme​​ts 的回应

自从我第一次发布这个答案以来，已经有许多 cmets 提出了关于模型在许多不同场景中如何工作的问题。

1. 客户要求改进现有功能

答案：

不要（我不能强调这一点）允许将新功能/增强功能添加到发布分支。这是范围蔓延。新功能就是新作品。它们需要单独计算成本，并且必须单独处理。无论您的客户是您自己的公司还是第三方，他们了解的一件事就是成本。向他们指出，如果他们中断发布，它将[无限期地]延迟发布，否则现有测试将受到影响。像对待master 一样对待发布分支。它是神圣的。只允许对其进行错误修复。

1. 分支寿命

如果您的发布分支持续数月，则您的发布周期太长。我曾在发布周期为平均每 3 周的地方工作过，在其他地方我们每两天发布一次。 3 周应该是足够的时间来进行 QA 和 UAT 发布分支。如果您正在考虑更长的周期，那么我认为该公司并不敏捷并且

1. git-flow 是错误的分支策略（值得怀疑，它适用于 几乎任何场景，只要小心管理）

2. 你真的需要挑战公司为什么他们有这样的 周期长

3. （很可能）- 你不懂 Git-Flow

   1. CI

我在 CI 中非常成功地使用了 Git-Flow。虽然这主要是 Jenkins 和 Bamboo，但它也适用于 Travis CI。

基于提交的 Git Hook 正是任何分支构建的工作方式。我使用过的最佳示例会在提交（或一系列提交）被推送到远程时自动构建，然后挂钩启动并调用 CI 平台。然后 CI 平台会找到相关作业（使用内置模板或使用 3rd 方模块）来触发构建。

我自己的个人设置是在以下情况下触发本地 Jenkins 实例：

• 我创建了一个分支（在针对当前分支的 jenkins 本地安装中创建新作业）
• 我提交（触发当前分支的本地实例构建）
• 本地构建通过，可以自动推送到远程
• 我推送新分支（在远程 CI 中创建目标构建
• 我推送提交（触发远程 CI 目标实例）
• 我删除本地分支（删除本地作业）
• 我删除远程分支（删除远程作业）
• 我提出合并请求（将功能/A 软合并到开发和测试中 - 测试失败，合并自动拒绝）

这需要一些配置，但任何现代 CI 平台都可以。

与其他任何事情一样，使用 Git-Flow 的规则只是指导方针。没有硬性规定。如果你想要一个长期存在的发布分支，那么这就是你的选择但是除非你注意它们，否则你最终会得到一个不同的代码库，这将是地狱般的合并。

Git-Flow 与其他任何源自 *nix 工具的东西一样，只是一种工作方式，并且随之而来的是大量选择。该工具和工作流只不过是 GIT 的一个包装器。您选择如何实施它完全取决于您。