GitHub 流程和发布

Question

总的来说，我们对 git 比较陌生。我们已经使用了大约 6 个月，并且使用过 GitHub 和 BitBucket。我们尝试通过使用 GitBash 尽可能多地学习，以便深入了解 git 的核心。

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

在我看来，GitFlow 对我们的要求来说过于复杂。我们总共参与了大约 20 个不同的项目，每个项目可能每 2 个月左右发布一次。查看 GitHub Flow 后，这似乎是一个非常直接的选项，可以满足我们的需求 - 但是它似乎确实有一个缺陷，我希望人们对此发表意见。

master 分支中的任何内容都是可部署的。我们部署到 UAT/QA 环境，该版本可能会保留 3-4 周，具体取决于客户和/或我们签署所有内容所需的时间。与此同时，其他人可能需要做一些完全不同的事情。在这个阶段，基于 Github Flow 的流程，如果该用户从 Master 那里获取了一个分支，他们将包括此时实际上仍在 QA 环境中的更改。那么，是不是我误解了 GitHub Flow 的第一点——即 master 分支中的任何东西都是可部署的——如果代码已经通过 QA 等，这可能才正确吗？

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

• 从 Master 取一个分支
• 在分支中提交更改（仅在此阶段返回分支）
• 将分支与名为“Develop”的单独分支合并
• 发布到 QA/UAT
• 当 Release 被批准时，将分支与 Master 合并并部署？

我认为 GitHub Flow 中的第 1 点让我们感到困惑——当发布仍处于 QA 阶段时，我们当然不应该将其推回 Master——这将使 Master 分支可能不稳定，当然不是目前在生产中的分支。

Answer 1

根据我在git-flow备忘单和德里森的原始模型上看到的内容，你有一些错误。

虽然我自己没有使用过该git-flow工作流程，但据我所知，master只有在版本准备好时才会合并，而不是之前。这样，master 始终反映 Prod 中的内容 -develop充当“主”开发分支，从中提取和合并功能分支。因此，成功的git-flow工作流程看起来像这样（假设所有这些分支都事先存在，除非另有说明）：

1. 创建一个功能分支（我们称之为topic）develop
2. 工作topic一段时间
3. 合并topic回develop
4. 多重复几次，直到准备好发布为止
5. 创建一个新分支，QA-releaseno，来自develop
6. 在 上进行 QA/UAT QA-releaseno，根据需要提交错误修复（您也可以根据需要多次合并QA-releaseno回）develop
7. 当您准备好发布时，合并QA-releaseno到master和develop，在 上标记发布master，然后删除QA-releaseno

此外，您似乎所做的是将Chacon 的 GitHub flowgit-flow合并起来。GitHub 流程，至少以最简单的形式，是这样工作的：

1. 衍生出一个新的主题分支（这里称为topic）master
2. 继续工作topic（如果你已经工作了很长时间，master定期合并是个好主意）
3. 进行质量检查topic
4. topic从至发出拉取请求 (PR)master
5. 一旦 PR 被代码审查到每个人都满意的程度，就合并topic回master
6. 立即释放master，或者至少快速释放

此工作流程专为处于快速发布周期（每周多次）的团队和组织而设计。质量检查不是在应用程序级别完成的，而是在单个功能、任务或票证级别完成的。因为发布周期有即时（或至少快速）反馈，master将始终反映生产中的情况。