我非常喜欢Scott Chacon描述的“github flow”工作流:http://scottchacon.com/2011/08/31/github-flow.html
他描述了github为什么不使用Vincent Driessen(http://nvie.com/posts/a-successful-git-branching-model/)描述的git flow工作流的原因，并且出于相同的原因，我们不使用它，最重要的原因是，它不能很好地处理请求请求，并且确实可以如果您没有“软件产品的正式发布版本”，但仍在不断完善网站，那么它就不太适合网站开发。
我们正在以一个小团队开发一个大型的在线社区，其中包含许多旧的旧代码(某些代码已经使用了10年以上)，并且测试覆盖率很差。我们使用的工作流程与github类似，目前我们使用功能分支进行开发，并使用 pull 请求将其集成到master分支中，进行同行评审，征求反馈等。 merge 为主人。每周几次，我们将母版推送到测试人员以及Beta用户使用的过渡环境。我们尝试每两周向公众发布master分支，因此必须对每个 merge 的功能分支进行足够好的测试，并且在最近的几天之内不会 merge “更具风险的功能分支”，直到向公众发布为止。
那不是一个完美的工作流程，因为当再次将“风险功能”与master merge 时，我们再也无法使用master来将修补程序发布给公众。
Github使用连续交付进行部署，这对我们来说不是一个选择，我们确实需要人们测试一个功能，然后才能将其发布给公众。
pull 请求只能 merge 到一个分支中。因此，这是github上一个简单的工作流程，只有一个长期运行的分支是master。也许我们不应该每两周发布一次，而应在 merge 到主服务器时发布 pull 请求？但是那样很难测试，我们可以在 merge 功能分支之前运行我们在功能分支上拥有的单元测试，并且可以将分支部署到用于beta测试人员的舞台上，但这并不总是那么容易，有时您必须这样做手动更改数据库(我们无法自动进行更改，因为我们用于Beta测试人员的登台服务器使用生产数据库，所以这样做的风险太大)，因此您必须等到管理员完成此操作。更大的问题是，如果仅向Beta用户发布功能分支，则它们没有集成，他们将看到新功能，并且一天可能会多次删除这些功能。并不是说您不能运行集成测试，或者在功能分支刚刚 merge 到master时才在发布之前运行它们。
另一方面，如果我们按照git-flow中的描述使用2个长期运行的分支(如develop和master)，则可以解决此修补程序问题，可以使用pull-requests merge 要开发的功能分支，可以使用pull request用于发布分支，用于将最新更改 merge 到主版本中，但是我们不能 merge 回更改以使用请求请求工作流程进行开发。
如您在github flow文章中看到的那样(第6条–复习后立即部署)，github工程师不仅可以部署到生产环境，还可以部署到暂存环境。不仅工程师可以做到这一点，支持人员和设计师也可以做到这一点。但是，它如何仅与一个集成分支一起工作？如果最后一个 pull 请求要在几个小时或几分钟内投入生产，则不需要暂存环境。有时他们似乎将功能分支部署到登台，这是有道理的，但是它们并未集成，因此，如上所述，即使在部署功能之前它们 merge 了来自主服务器的更改，您也会看到在登台环境中来来往往的功能。 -分期升级(您认为这是个好主意吗？)。还是有多个过渡环境，每个功能分支都有一个过渡环境，这有意义吗？但是，通过这种方式，您又失去了持续集成的优势。如前所述，我认为您无法在Beta测试环境中做到这一点。
我在git流和github流这两个工作流中都看到了问题，我更喜欢github流，但是如果您没有很好的测试覆盖面并且需要人们进行更多的测试，这似乎很困难。
因此，当功能分支需要人们(质量保证和Beta测试人员)进行更多测试时，我该如何集成和测试功能分支？
最佳答案
您可以在一个常见的集成分支上运行多个分支头:
----A---B---C---D---E---F---G---H---I
\ \ \
goodToGo testing toBeTested
关于git工作流程: how to integrate and test feature branches without continuous delivery?，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/17393160/