9

我非常喜欢 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 类似的工作流程，目前我们使用功能分支进行开发，并使用拉取请求将它们集成到主分支中，进行同行评审，征求反馈等。当功能完成并被其他人批准时，它是合并为大师。每周几次，我们将 master 推送到我们的测试人员和 beta 用户使用的暂存环境。我们尝试每两周向公众发布一次主分支，因此每个被合并的功能分支都必须经过足够好的测试，并且在最后几天不会合并“风险更大的功能分支”，直到发布完成。

这不是一个完美的工作流程，因为当重新开始将“有风险的功能”合并到 master 时，我们不能再使用 master 将修补程序部署到公共。

Github 使用持续交付进行部署，这对我们来说不是一个选项，我们确实需要人们在发布之前测试一个功能。

一个拉取请求只能合并到一个分支中。因此，在 github 上这是一个简单的工作流程，只有一个长期运行的 master 分支。也许我们不应该每两周发布一次，而是在合并到 master 时发布拉取请求？但是这样很难测试，我们可以在合并之前运行我们在功能分支上的单元测试，我们可以将分支部署到 staging 以供 beta 测试人员使用，但这并不总是那么容易，有时你必须这样做手动更改数据库（我们不能自动更改，风险太大，因为我们的 Beta 测试人员暂存服务器使用生产数据库），因此您必须等到管理员完成。更大的问题是，如果你只向 beta 用户发布功能分支，它们没有集成，他们会看到新功能，并且功能可能每天被删除多次。并不是说你不能运行集成测试，或者你在发布之前很晚才运行它们，当一个特性分支刚刚合并到主...

另一方面，如果我们使用 git-flow 中描述的 2 个长期运行的分支，例如 develop 和 master，我们可以解决 hotfix 问题，我们可以使用 pull-requests 合并功能分支来开发，我们可以使用 pull request一个发布分支，用于将最近的更改合并到 master 中，但我们不能合并回更改以使用 pull request 工作流程进行开发。

正如您在 github 流程文章（#6 – 审核后立即部署）中看到的，github 工程师不仅可以部署到生产环境，还可以部署到暂存环境。不仅工程师可以做到这一点，支持和设计师也能做到。但它如何仅与一个集成分支一起工作？如果最后一个拉取请求将在几小时或几分钟内投入生产，则您不需要暂存环境。有时他们似乎将功能分支部署到 staging，这是有道理的，但它们没有集成，所以我上面描述的会发生，你会看到在你的 staging 环境中来来去去的功能，即使它们在部署功能之前合并来自 master 的更改-branch to staging（你认为这是个好主意吗？）。或者有多个暂存环境是否有意义，每个功能分支一个？但是这样你又失去了持续集成的优势。如前所述，我认为您无法在 beta 测试环境中执行此操作。

我在 git flow 和 github flow 这两个工作流中都看到了问题，我更喜欢 github flow，但是如果你没有很好的测试覆盖率并且需要更多人的测试，这似乎很困难。

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

4

1 回答 1

1

您可以让多个分支头沿着一个公共集成分支运行：

 ----A---B---C---D---E---F---G---H---I
              \           \           \
               goodToGo    testing     toBeTested
于 2013-10-29T08:27:44.263 回答