请问如何处理git分支以进行测试和生产

Question

当使用git（流程）并在阶段/测试环境中客户对所开发的内容进行评论时，处理未批准的功能和已批准的功能的最佳方法是什么？

考虑以下情形：多个开发人员在sprint或连续工作流中使用不同的功能。客户需要审查这些功能，并且要使其能够在舞台环境中进行审查，必须将这些功能合并到dev分支中并进行部署。

假设是否已经开发了两个功能，并由开发团队认为已经完成，并已推送给开发人员。客户对其进行审核并批准其中一个。但是现在客户希望将批准的功能发布到生产中。现在，开发部门被未经批准的功能代码“污染”，该功能代码无法推送到生产环境。

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

Answer 1

这个问题（由“非批准，但已经集成”功能分支污染Dev分支）是究竟什么形容拉曼古普塔在“ 如何Git来完成分支的创建者 ”。（GitHub库的工作流程：rocketraman/gitworkflow）在您的情况下（gitflow），您需要先还原未批准功能的合并提交，然后再将开发人员合并到发行版中。但是，“ gitworkflow”使用短暂分支，与gitflow相反：GitFlow倡导拥有两个永恒的分支-  master和develop这两个工作流（gitflow或gitworkflow）都使用“功能”或“主题”分支：主题分支是当前所有工作的完成地-每个问题，错误或功能一个分支，并且可以有多个主题分支同时进行开发。主题最终合并到nextgitworkflow 的分支“ ”中。但是，一个关键的区别是该next分支永远不会合并到该分支master（与永久分支“ develop” 相反，后者打算在gitflow中合并到master/ release）现在，该topic课程已升级为next，可以成为测试版或接受版本的一部分。因此，接下来的每个主题现在都可以进行第二轮稳定化，这正是Beta发布/接受测试环境的目的。但是，请注意，使用gitworkflow时，我们仍未承诺（没有双关语！）将其topic作为下一个正式生产版本的一部分-仍未合并到master。这在概念上与GitFlow的release分支相似，但是更加灵活和强大，因为master它不依赖于next任何东西，也next永远不会被大量合并到其中master（不同于相应的GitFlow分支develop和release）。如果下一个未合并为母版，那么如何将特征毕业到生产中？一旦判断出某个主题足以稳定以释放该主题，该主题就会再次毕业并合并到master（或也许maint），--no-ff以保留该主题分支的完整历史记录。为什么这样更好：请注意，在gitworkflow中，不稳定和稳定的开发工作永远不会在同一分支上混合在一起。相比之下，使用GitFlow，我有两种选择：我可以在自己的分支上单独测试主题，或者我可以将其合并以进行测试。两种选择都没有吸引力。当与其他正在进行的工作一起部署时，前者不能提供对主题稳定性的真实测试，并且后者认为这个话题可能要在稳定之前发展。含义：简而言之，在GitFlow中，在保持开发工作清洁和隔离在主题分支上的愿望与通过合并主题分支使其与其他工作进行合并以使其可见并可以测试并检查冲突之间的渴望之间始终存在着无法解决的张力。Gitworkflow既可以实现两个目标，又可以不牺牲另一个。