GitHub工作流和发布管理

Question

GitHub工作流和发布管理

6

我们对于Git相对较为新。我们使用Git已经大约6个月了，并且使用过GitHub和BitBucket。我们尝试通过使用GitBash学习尽可能多的内容，以便更深入地了解git。

现在我们正处于考虑分支策略的阶段，因此我一直在进行一些研究。

在我看来，对于我们的要求而言，GitFlow过于复杂。总共我们大约会涉及20个不同的项目，并且每个项目只有每2个月左右发布一次版本。经过研究后，GitHub Flow似乎是一个非常简单直接的选项，可以满足我们的需求，但是它似乎存在一个缺陷，我想听取其他人的意见。

在主分支中的任何东西都是可部署的。我们会将其部署到UAT/QA环境中，在那里该版本可能会保持3-4周，具体取决于客户和/或我们签署所有文件所需的时间。同时，其他人可能需要处理完全不同的任务。根据GitHub Flow的流程，如果此时用户从Master分支派生出一个分支，则该用户将包括那些实际上仍然在QA环境中的更改。那么，我是否误解了GitHub Flow的第一点——即主分支中的任何东西都是可部署的——或许只有在代码经过QA等流程之后，这一点才是正确的？

如果那样的话，流程实际上会更像：

从Master派生一个分支
在该分支中提交更改（仅在该分支中）
将该分支与名为“Develop”的单独分支合并
发布到QA/UAT
获得批准后，将该分支与Master合并并部署？

我认为GitHub Flow中的第1点特别困惑我们——当版本仍处于QA阶段时，我们肯定不应该将更改推回Master分支——这可能会使Master分支变得不稳定，并且肯定不是当前产品环境中正在使用的内容。

- dotdev

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Sebastian Lenartowicz · Accepted Answer

根据我在git-flow cheat sheet和Driessen's original model上看到的内容，您有一些错误。

虽然我自己没有使用过git-flow工作流，但从我所了解的情况来看，只有当发布准备就绪时才会将master合并，而不是之前。这样，master始终反映出生产环境中的内容-develop是“主”开发分支，从中拉取和合并特性分支。因此，成功的git-flow工作流如下（假设所有这些分支事先存在，除非另有说明）：

从develop创建一个特性分支（我们将其称为topic）
在topic上工作一段时间
将topic合并回develop
重复以上步骤几次，直到准备好发布
从develop创建一个名为QA-releaseno的新分支
在QA-releaseno上进行QA/UAT测试，必要时提交bug修复（您也可以将QA-releaseno合并回develop多次）
当您准备好发布时，将QA-releaseno合并到master和develop中，标记一个master版本，并删除QA-releaseno

此外，您似乎将git-flow和Chacon的GitHub流程混淆了。 GitHub流程，至少在其最简单的形式中，是这样工作的：

从master中分离出一个新的主题分支（这里称为topic）
在topic上工作（如果您长时间地在其上工作，定期将master合并回去是个好主意）
对topic进行QA
从topic到master发布拉取请求（PR）
一旦PR已经被每个人都满意地代码审查，就将topic合并回master
立即发布master，或者至少相当快地发布

这个工作流程适用于快速发布周期的团队和组织（每周多次）。QA不是在应用程序级别进行，而是在单个功能、任务或工单的级别进行。由于发布周期具有即时（或至少快速）反馈，master将始终反映生产环境中的内容。