处理用于测试和生产的 git 分支答案

【问题标题】：Handle git branching for test and production处理用于测试和生产的 git 分支
【发布时间】：2017-11-12 04:44:42
【问题描述】：

当使用 git (flow) 并拥有一个阶段/测试环境时，客户可以在其中对开发的事物进行审查，处理未经批准的功能以及已批准的功能的最佳方法是什么？

考虑多个开发人员在冲刺或连续工作流程中使用不同功能的场景。这些功能需要由客户审查，并且为了能够在阶段环境中审查这些功能，它们必须合并到开发分支中并进行部署。

假设开发了两个功能，开发团队认为已完成并已推送给开发人员。客户审查它们并批准其中之一。但是现在客户希望将批准的功能发布到生产环境中。 dev 分支现在被无法推送到生产的未经批准的功能代码“污染”。

处理这种情况的最佳方法是什么？当然，实际上它更复杂。是樱桃采摘解决方案还是应该重新考虑分支的整体流程和处理？

【问题讨论】：

如果 dev 分支包含将被提升到生产的所有内容，那么新功能不能被推送到 dev 以供客户审查。客户需要在功能分支仍然存在时对其进行审查，以防止“污染”的开发分支。
但是如果客户没有办法处理特性分支，那么需要审查的东西需要手动逐个特性地放到测试环境中。并且在审核当前功能之前无法审核新功能，这使得整个过程非常缓慢

标签： git git-flow

【解决方案1】：

那个问题（开发分支被“未批准但已集成”的功能分支污染）正是在“How the Creators of Git Do Branching”中描述了Raman Gupta。（此工作流的 GitHub 存储库：rocketraman/gitworkflow）

在您的情况下（gitflow），您需要在将开发合并到发布之前恢复未批准功能的合并提交。

但“gitworkflow”使用临时分支，与 gitflow 相对：

GitFlow 主张拥有两个永恒的分支 —— master 和 develop

两个工作流（gitflow 或 gitworkflow）都使用“功能”或“主题”分支：

主题分支是所有当前工作正在完成的地方 — 每个问题、错误或功能一个分支，并且可以同时有许多主题分支正在开发中。

一个主题最终合并到 gitworkflow 中的分支“next”中。
然而，一个关键的区别是 next 分支永远不会合并到 master （与永恒分支“develop”相反，它意味着在 gitflow 中合并到 master/release）

现在topic 已升级为next，它可以是测试版或验收版本的一部分。所以接下来的每个主题现在都可以进行第二轮稳定，这正是 beta 发布/验收测试环境的目的。

但是，请注意，对于 gitworkflow，我们仍然没有承诺（不是双关语！）将这个 topic 作为我们下一个生产版本的一部分 — 它仍然没有合并到 master。
这在概念上类似于 GitFlow 的 release 分支，但更加灵活和强大，因为 master 与 next 没有任何依赖关系，next 也不会批发合并到 master（不像对应的 GitFlow 分支 develop 和 release).

如果下一个没有合并到 master，你如何将一个功能毕业到生产？

一旦某个主题被判断为足够稳定可以发布，该主题将再次毕业并合并到 master（或者可能是 maint），再次与 --no-ff 合并以保留主题分支的完整历史记录。

为什么这样更好：

请注意，在 gitworkflow 中，不稳定和稳定的开发工作永远不会在同一个分支上混合在一起。

相比之下，使用 GitFlow 我有两种选择：

我可以在自己的分支上单独测试我的主题，或者

我可以合并它来开发测试。

这两种选择都不吸引人。

当与其他正在进行的工作一起部署时，前者不能真正测试主题的稳定性，并且

后者可能会在主题稳定之前提交主题以进行开发。

意思：

简而言之，在 GitFlow 中，始终存在在主题分支上保持开发工作干净和隔离的愿望，以及通过合并主题分支与其他工作来集成主题分支之间存在一种无法解决的矛盾。它们可见且可测试并检查冲突。
Gitworkflow 允许同时实现这两个目标，而不会为了另一个而牺牲一个。

【讨论】：

是的，这看起来像是解决它的方法。会尝试这个并尝试了解它的工作流程，但它肯定解决了 gitflow 工作流程中的问题
@Hyzac 是的：重点是：将您的主题/功能合并到开发/集成分支，然后将相同的主题/功能合并到发布分支。不要尝试将您的集成分支直接合并到发布版本。

【解决方案2】：

我认为这里的正确方法是：

生产 (...)
master（开发分支）
feature123
feature234
feature345
特征[数量]

如果可以，请向客户提供 feature[number].example.com 域。因此，您可以在 master 分支中显示合并之前的所有功能。如果一个特性被拒绝，它绝不能被合并到主控中。如果特征被接受，它必须被合并。

一个很好的选择也是一个“临时”域，在需要时可以在其中部署代码。假设您的客户需要查看 feature42，...只需将 feature42 部署到 customer.example.com 域。

在哪里开发新功能？

feature[number] branch

在哪里展示新功能？

feature[number].example.com

在哪里可以看到下一个 sprint 代码（大师）？

next.example.com

或

master.example.com

在哪里查看生产代码？

www.example.com

【讨论】：