处理git分支以进行测试和生产

Question

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

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

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

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

Answer 1

这个问题（被“未经批准但已经集成”功能分支污染的dev分支） 正是 Raman Gupta在“ Git的创建者如何进行分支 ”中描述的。
（此工作流的GitHub存储库： rocketraman/gitworkflow ）

在您的情况下（gitflow），您需要先还原未批准功能的合并提交，然后再将开发人员合并到发行版中。

但是，“ gitworkflow”使用短暂分支，与gitflow相反：

GitFlow倡导拥有两个永恒的分支机构- master和develop

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

主题分支是当前所有工作的完成地-每个问题，错误或功能一个分支，并且可以有多个主题分支同时进行开发。

最终一个主题合并到gitworkflow中的分支“ next ”中。
但是，一个关键的区别是next分支永远不会合并到master （与永恒的分支“ develop ”相对，后者打算在gitflow中合并到master / release ）

现在，该topic已经逐渐扩展到next ，它可以成为beta或接受发布的一部分。 因此，接下来的每个主题现在都可以进行第二轮稳定化，这正是Beta发布/接受测试环境的目的。

但是，请注意，使用gitworkflow时，我们仍未承诺（无双关语！）将这个topic作为我们下一个正式发布版本的一部分-仍未合并到master 。
这在概念上与GitFlow的release分支相似，但是更加灵活和强大，因为master完全不依赖于next ， next不会完全合并到master （与相应的GitFlow分支的develop和release ） 。

如果下一个未合并为母版，那么如何将特征毕业到生产中？

一旦判断出某个主题足够稳定以至于无法发布，该主题便会再次毕业并合并为master （或可能是maint ），再使用--no-ff来保留该主题分支的完整历史记录。

为什么这样更好：

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

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

1. 我可以在自己的分支上单独测试主题，或者
2. 我可以将其合并以进行测试。

两种选择都没有吸引力。

• 当与其他正在进行的工作一起部署时，前者不能提供对主题稳定性的真实测试，并且
• 后者认为这个话题可能要在稳定之前发展。

含义：

简而言之，在GitFlow中，在保持开发工作清洁和隔离在主题分支上的愿望与通过合并主题分支使其与其他工作进行合并以使其可见并可以测试并检查冲突之间的渴望之间始终存在着无法解决的张力 。
Gitworkflow既可以实现两个目标，又可以不牺牲另一个。

Answer 2

我认为正确的方法是：

• 生产 （...）
• 大师（开发分支）
• feature123
• feature234
• feature345
• 特征[数字]

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

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

在哪里开发新功能？

feature[number] branch

在哪里显示新功能？

feature[number].example.com

在哪里可以看到下一个冲刺代码（主机）？

next.example.com

要么

master.example.com

在哪里可以看到生产代码？

www.example.com