由于特定的情况，我正在考虑为当前的工作场所扩展git-flow模型。但是我的场景非常普遍，我很惊讶没有人在使用git-flow模型之前做过这件事，这让我觉得我错过了一个明显的问题。我的问题是：我提议的延期是否有缺陷？
场景：我有许多开发团队从公共代码库开发，我们通过几个（永久）环境推出版本：首先是系统集成环境（SIT），然后是UAT环境，然后是预先制作，最后到制作。这是严格顺序的，尽管任何候选版本可能在任何环境中都会失败，因此不再进一步。因此，后来的每个环境都只是以前环境中移动速度较慢的版本。
我们正在为源代码控制引入git，我们需要一个工作流程，git-flow看起来是一个好的开始。
我们问自己如何在任何时候捕获（即如何知道）每个环境中的内容。 git-flow模型似乎基本上有两个核心状态：master和develop。他们有“无限的寿命”。其他分支只有"supporting branches"，其寿命有限。它们的存在只是为了允许开发并从开发到生产（通过临时发布状态）。 git-flow模型基于从开发到发布。
但是，这并没有逻辑映射到我们的场景，其多阶段发布顺序。当然，我对develop分支很好。 master分支显然映射到我们的生产环境。关于master：
因此，每次将更改合并回master时，这都是新的 生产版本按照定义。我们往往对此非常严格，所以 从理论上讲，我们可以使用Git钩子脚本来自动构建和推出 我们的软件每次都有一个提交给我们的生产服务器。
由于master是连续的生产记录，我们应该扩展git-flow模型以便为SIT，UAT和pre-prod提供相应的分支。毕竟，它们是永久性环境，具有严格的释放程序。它们只比生产更快一点。
这些额外的永久性分支位于develop和master之间，就像它们对应的环境一样。
现在，这意味着可以轻松跟踪每个环境的发布以及每个环境的状态。并且每个的合并也更容易：SIT分支需要来自develop的合并，UAT分支需要来自SIT分支的合并，pre-prod分支需要来自UAT分支的合并，最后{ {1}}分支（用于生产）需要来自pre-prod分支的合并。每个后来的分支只是前一个分支的一个移动速度较慢的版本。
我错过了什么吗？
答案 0 :(得分：10)
我没有理由看到根据您的模型调整流量。你说你按顺序工作SIT - ＆gt; UAT - ＆gt;预刺。完善。一旦开发稳定（即所有要发布的功能都是功能完成[ed]），然后执行release start并将其移至您的SIT平台以进行QA。一旦发布开始，就可以在develop分支上继续开发。 master保持静态，直到发布完成。
一旦QA满意，则发布分支将移至UAT。 UAT通过，代码滚动到现场，你执行release finish合并回master / develop。
master应始终反映当前在实时平台上的内容，而develop则反映了正在积极开发的代码。 release分支包含一个静态版本的开发，针对其应用了错误修复（没有新功能永远被推入此分支，或者您没有使用git-flow）。
根据您的描述，我倾向于说您误解了git-flow模型，因为从我所看到的它完全符合您描述的场景，您在SIT期间需要关注的所有内容 - ＆GT; UAT - ＆gt; Pre-Prod是发布分支，＆＃34;忘记＆＃34;掌握/发展甚至存在于现阶段。
对评论的回应
自从我第一次发布这个答案以来，已经有很多评论提出了关于模型如何在许多不同场景中起作用的问题。
答案：
不要（我不能强调这一点）允许将新功能/增强功能添加到发布分支。这是范围蔓延。新功能是新功能。它们需要单独计算，必须单独处理。无论您的客户是您自己的公司还是第三方，他们理解的一件事就是成本。向他们指出，如果他们中断释放，它将[无限期]延迟它或现有的测试将受到影响。像master一样对待发布分支。这是神圣的。只允许修复错误。
如果您的发布分支持续数月，则您的发布周期太长。我已经在发布周期的地方工作，平均每3周一次，以及我们每隔几天发布的其他地方。 3周应该是QA和UAT发布分支的充足时间。如果您正在考虑更长的周期，那么我认为该公司并不敏捷且
git-flow是错误的分支策略（可疑，它适用于 几乎任何情况，只要它经过精心管理）
你真的需要向公司挑战他们为什么会这样做 漫长的周期
（最有可能） - 你不了解Git-Flow
我已经非常成功地使用了Git-Flow。虽然这主要是Jenkins和Bamboo，但它也适用于Travis CI。
基于提交的Git Hook正是任何分支构建的工作原理。一旦提交（或一系列提交）被推送到远程，我使用的最佳示例会自动构建，然后钩子启动并调用CI平台。然后CI平台找到相关作业（使用内置模板或使用第三方模块）来触发构建。
我自己的个人设置是在以下情况下触发本地Jenkins实例：
这需要一些配置，但可以使用任何现代CI平台。
与其他任何事情一样，使用Git-Flow的规则只是指导原则。没有严格的规则。如果您想要一个长期存在的发布分支，那么您的选择但除非您注意它们，否则您将最终得到一个不同的代码库，这将很难合并回来。
Git-Flow，就像* nix工具诞生的任何其他产品一样，只是一种工作方式，它带来了很多选择。该工具和工作流程只不过是GIT的包装器。您如何选择实施它完全取决于您。