GitHub流程和发布

一般而言，我们对git还是相对较新的。我们已经使用了大约6个月，并使用了GitHub和BitBucket。我们试图通过使用GitBash来学习尽可能多的知识，这样我们就可以了解git的核心。

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

我认为，对于我们的要求，GitFlow过于复杂。我们总共可能从事20个不同的项目，并且每个项目可能仅每2个月左右发布一次。看完GitHub Flow之后，这似乎是一个可以满足我们需求的非常简单的选择-但是它似乎确实存在一个缺陷，我希望人们对此发表意见。

master分支中的任何内容都是可部署的。我们部署到UAT/QA环境中，该版本可能会保留3-4周，具体取决于客户和/或我们将所有内容签名的时间。同时，其他人可能需要从事完全不同的工作。在此阶段，根据Github Flow的流程，如果该用户从Master分支，他们将包括实际上在此时间点仍在QA环境中的更改。那么，是否是我误解了GitHub Flow的第一点-即master分支中的任何内容都是可部署的-难道只有在代码已经通过QA等验证的情况下才如此吗？

如果是这样，流程实际上看起来更像吗？:

从

大师那里分支

提交分支更改(此阶段仅返回分支)

merge 具有单独分支的分支，称为“Develop”

发布到质量检查/UAT

批准发布后，将分支与Master merge 并部署？

我认为特别是GitHub Flow上的Point 1使我们感到困惑-我们肯定不应该在发布仍在质量检查中时再回到Master上，这会使Master分支变得不稳定，而且肯定不是生产环境中的东西。

最佳答案

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

虽然我自己没有使用过git-flow工作流程，但据我所知，master仅在发布准备就绪时才 merge ，而不是之前。这样，master总是反射(reflect)出Prod中的内容-develop是充当“主要”开发分支的功能，从该分支中​​提取并 merge 功能分支。因此，成功的git-flow工作流程如下所示(假设所有这些分支都预先存在，除非另有说明):

从topic创建一个功能分支(我们称为develop)

在topic上工作一段时间

将topic merge 回develop

再执行几次，直到准备发布

从QA-releaseno新建一个分支develop

对QA-releaseno进行QA/UAT，根据需要提交错误修正(您也可以根据需要将QA-releaseno merge 回develop任意多次)

准备发布时，请将QA-releaseno merge 到master和develop中，在master上标记发布，然后删除QA-releaseno

此外，您似乎已经完成了将git-flow和Chacon's GitHub flow混合的操作。至少以最简单的形式，GitHub流的工作方式如下:

从topic衍生出一个新的主题分支(此处称为master)

处理topic(如果您已经使用了很长时间，则定期将master merge 回去是一个好主意)

对topic进行质量检查

发出从topic到master的 pull 请求(PR)

一旦对PR进行了代码审核，使每个人都满意，则将topic merge 回master

立即释放master，或至少迅速释放

此工作流程专为处于快速发布周期(每周多次)的团队和组织而设计。质量检查不是在应用程序级别进行，而是在单个功能，任务或故障单的级别进行。由于发布周期具有即时(或至少快速)的反馈，因此master将始终反射(reflect)生产中的内容。

关于GitHub流程和发布，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/40848283/