git工作流程：如何在没有持续交付的情况下集成和测试功能分支？

Question

我喜欢斯科特·查孔非常多所描述的“GitHub的流动”的工作流程：http://scottchacon.com/2011/08/31/github-flow.html

他介绍为什么github上不使用由文森特了Driessen（http://nvie.com/posts/a-successful-git-branching-model/）中描述的混帐流工作流程，我们不使用它的同样的原因，其中最重要的原因是，它不适合拉取请求，它不适合网站开发，你没有“正式发布的软件产品版本”，但不断改进网站。

我们正在一个小团队中开发一个大型在线社区，其中有很多旧的遗留代码（有些代码已超过10年），测试覆盖率较差。我们正在使用与github相似的工作流，目前我们使用功能分支进行开发，并使用pull请求将它们集成到master分支中，进行同行评审，征求反馈等。当功能完成并获得其他人的批准后，合并成主人。每周我们都会把主人推到一个由我们的测试人员和测试用户使用的临时环境。我们试图每两周向公众发布一次主分支，因此合并后的每个功能分支都必须进行足够的测试，并且在最后几天内不会合并“更具风险的功能分支”，直到完成公开发布为止。

这不是一个完美的工作流程，因为当再次合并“风险功能”给主控人员时，我们无法使用主控人员将修补程序部署到公共场所。 Github使用持续交付进行部署，这不是我们的选择，我们确实需要人们在功能发布之前对其进行测试，然后才能将其发布给公众。

拉取请求只能合并到一个分支中。所以这是一个简单的github工作流程，只有一个长期运行的分支是主分支。也许我们不应该每隔两周发布一次，但是当它们合并为主时发布拉取请求？但这样很难测试，我们可以在合并之前运行我们在特性分支上的单元测试，并且我们可以将分支部署到beta测试者的阶段，但这并不总是那么容易，有时您必须做数据库手动更改（我们无法自动执行，因为我们的beta测试人员的临时服务器使用生产数据库，所以风险太大），因此您必须等待管理员完成此操作。而更大的问题是，如果您只向Beta版用户发布功能分支，则它们不会集成，它们会看到新功能，并且可能每天都会多次删除功能。另一方面，如果我们使用2个长时间运行的分支，比如说，如果我们使用2个长时间运行的分支开发和掌握git-flow中描述的，我们可以解决修补程序问题，我们可以使用pull-requests合并要开发的功能分支，我们可以使用pull请求来发布分支，以便将最近的更改合并到master中，但是我们可以将合并的更改合并回来以使用拉取请求工作流进行开发。如您在github流文章（＃6 - 在审查后立即部署）中看到的，github工程师不仅可以部署到生产环境，还可以部署到临时环境。不仅工程师可以做到这一点，还有支持和设计师。但是，它只与一个整合分支有什么关系？如果最后的拉取请求在几小时或几分钟内即将投入生产，则不需要临时环境。有时他们似乎将功能分支部署到分段中，这是有道理的，但它们并未集成，因此我将在上面介绍的内容中看到，即使在部署功能部件之前它们合并了来自主部件的更改 - 分段分段（你认为这将是一个好主意？）。或者是否有多个临时环境，每个功能分支一个？但这种方式再一次让你失去了持续集成的优势。正如所说的，我认为你不能在beta测试环境中做到这一点。

我发现在这两种工作流程，git流程和github流程中都存在问题，我更喜欢github流程，但如果您没有良好的测试覆盖率并需要人员进行更多测试，似乎很难。

那么，当人们需要更多测试（qa和beta测试人员）时，如何集成和测试功能分支？

Answer 1

你可以沿着一个共同的集成分支跑几支头：

----A---B---C---D---E---F---G---H---I 
       \   \   \ 
       goodToGo testing  toBeTested