19

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

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

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

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

但是，这并没有在逻辑上映射到我们的场景，它具有多阶段的发布顺序。当然，我对develop分支很好。该master分支显然确实映射到我们的生产环境。原始的git-flow 描述是这样说的master：

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

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

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

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

我错过了什么吗？

4

1 回答 1

15

我没有理由根据您的模型调整流程。你说你按顺序工作 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 在这个阶段甚至存在。

对评论的回应

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

  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 的一个包装器。您选择如何实施它完全取决于您。

于 2013-07-03T00:35:21.607 回答