使用git（flow）并拥有一个阶段/测试环境，客户正在对所开发的内容进行评估时，处理未经批准的功能的最佳方法是什么？
考虑几个开发人员在sprint或连续工作流中使用不同功能的情况。客户需要审查这些功能，并且要在舞台环境中审核这些功能，必须将这些功能合并到开发分支并进行部署。
如果，比方说，已经开发了两个功能，由开发团队完成并被推送到dev。客户审核并批准其中一个。但现在客户希望将批准的功能发布到生产中。现在，dev分支被未经批准的功能代码“污染”，无法将其推送到生产环境。
处理这种情况的最佳方法是什么？当然，实际上它更复杂。樱桃选择解决方案还是重新考虑分支机构的整个流程和处理？
答案 0 :(得分：2)
该问题（由＆＃34;未经批准但已经集成的＆＃34;功能分支污染的开发分支）完全描述 Raman Gupta 的内容＆＃34; How the Creators of Git Do Branching＆＃34 ;.
（此工作流程的GitHub回购：rocketraman/gitworkflow）
在您的情况下（gitflow），您需要在合并开发版之前还原未经批准的功能的合并提交。
但＆＃34; gitworkflow＆＃34;通过gitflow的反对使用短暂的分支：
GitFlow倡导拥有两个永恒的分支 -
master和develop
两个工作流程（gitflow或gitworkflow）都使用＆＃34;功能＆＃34;或＆＃34;主题＆＃34;分支：
主题分支是所有当前工作正在进行的地方 - 每个问题，错误或功能一个分支，并且可以有许多主题分支同时进行开发。
主题最终合并到分支＆＃34; next＆＃34;在gitworkflow中
但是，一个关键区别是next分支永远不会合并到master（而不是永恒分支＆＃34; develop＆＃34;这意味着要合并到{ gitflow中的{1}} / master
现在
release已经毕业到topic，它可以是测试版或验收版的一部分。因此，接下来的每个主题现在都可以进行第二轮稳定，这正是测试版本/验收测试环境的目的。然而，请注意，使用gitworkflow，我们仍然没有提交（没有双关语！）作为我们下一个版本的生成中的
next- 它仍然没有合并到topic。
这在概念上类似于GitFlow的master分支，但更加灵活和强大，因为release对master没有任何依赖关系，next也没有合并批发到next（与相应的GitFlow分支master和develop）不同。
如果下一步是不合并为主人，你如何将一个功能毕业到制作？
一旦主题被判断为足够稳定以便发布，该主题将再次毕业，并再次与
release合并到master（或者maint），以保留完整的历史记录。主题分支。
为什么这样更好：
请注意，在gitworkflow中，不稳定且稳定的开发工作永远不会在同一分支上混合在一起。
相比之下，使用GitFlow我有两个选择：
- 我可以在自己的分支上单独测试我的主题，或者
- 我可以合并它来开发测试。
这两种选择都没有吸引力。
- 当与其他正在进行的工作一起部署时，前者不提供对主题稳定性的真实测试，并且
- 后者承诺在稳定之前开发主题。
含义：
简而言之，在GitFlow中，在保持开发工作清洁和隔离主题分支的愿望与将主题分支与其他工作集成之间始终存在<强烈无法解决的紧张关系，将它们合并为开发制作它们可见且可测试并检查冲突 Gitworkflow允许实现两个目标，而不会牺牲另一个目标。
答案 1 :(得分：1)
我认为这里的正确方法是：
如果可以，请向客户提供功能[number] .example.com域。因此，您可以在master分支中合并之前显示所有功能。如果某个功能被拒绝，则绝不能在master中合并。如果接受功能，则必须将其合并。
一个好的选择也是一个＆＃34;分期＆＃34;域在何时需要部署代码。假设您的客户需要查看feature42，...只需将feature42部署到customer.example.com域。
feature[number] branch
feature[number].example.com
next.example.com
或
master.example.com
www.example.com