我非常喜欢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工作流程，我们不会't use it for the same reasons, where the most important reasons are, that it does not work well with pull requests and it does not fit well to website development where you don'但是不断改进网站 .
我们正在一个小团队中开发一个大型在线社区，其中包含许多旧的遗留代码（一些代码超过10年），测试覆盖率很差 . 我们使用与github类似的工作流程，目前我们使用功能分支进行开发，并使用拉取请求将它们集成到主分支中，进行同行评审，请求反馈等 . 当功能完成并被其他人批准时，它是合并为主人 . 我们每周几次将主人推送到我们的测试人员以及测试版用户使用的分期环境中 . 我们尝试每两周向公众发布一个主分支，因此每个合并的功能分支都必须进行足够好的测试，并且在过去几天内没有合并“更具风险的功能分支”，直到公开发布为止 .
这不是一个完美的工作流程，因为当再次将“风险特征”合并到大师时，我们不能再使用master将修补程序部署到公共 .
Github使用持续交付进行部署，这对我们来说不是一个选择，我们确实需要人们在我们将其发布给公众之前对其进行测试 .
拉取请求只能合并到一个分支中 . 所以这是github上一个简单的工作流程，只有一个长期运行的分支是master . 也许我们不应该每两周发布一次，但是当它们合并到掌握时发布拉取请求？但是这样很难测试，我们可以在合并之前运行我们在功能分支上的单元测试，并且我们可以将分支部署到beta测试人员的分段，但这并不总是那么容易，有时你不得不做手动更改数据库（我们不能自动执行，因为我们的beta测试人员的临时服务器使用 生产环境 数据库，因此风险太大），因此您必须等到管理员完成此操作 . 更大的问题是，如果您只向beta用户发布功能分支，它们没有集成，他们将看到新功能，并且功能可能每天被删除多次 . 并不是说你不能运行集成测试，或者你在发布之前很晚才运行它们，当一个功能分支刚刚合并到master时......
另一方面，如果我们使用2个长期运行的分支，比如git-flow中描述的develop和master，我们可以解决修补程序问题，我们可以使用pull-requests来合并功能分支来开发，我们可以使用pull请求用于将最近更改合并到master中的发布分支，但我们无法使用pull请求工作流合并回更改以进行开发 .
正如您在github流文章中所看到的（＃6 - 审核后立即部署），github工程师不仅可以部署到 生产环境 环境，还可以部署到临时环境 . 不仅工程师可以做到这一点，还有支持和设计师 . 但它如何只与一个集成分支一起工作？如果最后一次拉取请求在几小时或几分钟内无论如何都要进行 生产环境 ，则不需要暂存环境 . 有时它们似乎将功能分支部署到分段，这是有意义的，但它们没有集成，所以我上面描述的将会发生，你会看到在临时环境中进出的功能，即使它们在部署功能之前合并了master的更改分到分段（你认为这会是一个好主意吗？） . 或者有多个临时环境，每个功能分支一个环境是否有意义？但是这样你再次失去了持续整合的优势 . 如上所述，我认为你不能在beta测试环境中这样做 .
我在工作流程，git流程和github流程中都看到了问题，我更喜欢github流程，但是如果你没有良好的测试覆盖率并且需要人们进行更多测试，那么这似乎很难 .
So, how can I integrate and test feature branches, when they need more testing by people (qa and beta testers)?
1 回答
您可以在一个公共集成分支中运行多个分支头：