Git 开发与发布分支最佳实践

Question

我一直在监视从每个 sprint 开始的两个分支 -Release和Master.

Master 分支是开发人员创建新分支（特定于任务）、实施他们的更改并创建合并到 Master 的拉取请求的地方。

Release分支是特定于 sprint 的，它始终可以提交给生产。我们只合并提交到发布分支Master并由QA发布分支验证的分支。

这种方法最适合我们，因为我们Release定期提交并实施和验证特定功能，因此我们确切地知道下一个版本会发生什么。

这个问题是avoid-merging-master-into-development-branch 和git-merging-only-branch-specific-commits的延续

在一行中，我想

“确保只有经过 QA 验证的开发分支才能进入下一个候选版本。”

我曾想过使用我之前讨论中的以下工作流程选项；

git pull --rebase master taskA
//Work on taskA branch, do multiple commits, and also execute this command multiple times whenever required;
At time of Rebasing taskA to Master
git checkout taskA
git rebase -i origin/Master // Remove any commits that are not belongs to taskA.
git checkout origin/master
git merge taskA

这个工作流程将为我的每个分支提供清晰的历史记录，这些历史记录Master将通过 QA 验证。我可以轻松地将经过验证的分支重新设置为Release分支。

我是否朝着正确的方向前进？这个 git-flow 效果最好吗？有没有更好的方法来做我想要实现的目标？

Answer 1

这是你的问题。

我们只将提交给 Master 并由 QA 验证的分支合并到 Release 分支中。

这意味着您必须两次集成功能分支。一次进入Master，再次进入Release。您正在努力解决一个明显的问题：您如何确保集成到 Master 中的所有内容都集成到 Release 中？并且因为功能建立在其他功能之上，所以它们必须以类似的顺序排列。

不要试图解决这个问题。这既困难又凌乱，您必须始终小心。最好有一个更万无一失的过程。让我们回到你既定的目标。

确保只有经过 QA 验证的开发分支才能进入下一个候选版本。

（强调我的）那不是真正的目标，而是实现目标的解决方案。你真正的目标是什么？这个怎么样...

确保只有经过 QA 验证的代码才能进入下一个版本。

看看我在那里做了什么？质量发布不关心代码来自哪里，它关心正在发布的代码的状态。您希望确保 QA 未检查的任何内容都不会进入发布版本。为此，我建议将您的工作流程更改为Gitflow Workflow 的一个版本。它是这样的。

1. 开发人员有任务要做。
2. 开发人员分支master，我们称之为task。
3. 开发人员致力于task.
   1. 开发人员为task.
4. 开发人员在master需要时获取更新。
   1. 他们可以变基或合并，都没有关系。
5. 开发人员完成task。
   1. 开发人员从master.
   2. 开发人员确保他们的单元测试和所有回归测试都通过。
   3. 可选开发人员将 提交task给 QA 进行验收测试。
   4. 开发人员合并到master.
   5. 开发人员删除task.

因为开发人员正在编写他们自己的单元测试，所以此时您知道其中的所有内容master都已经过单元和集成测试。在 5.3 中，一些重要的或多毛的特性已经过验收测试，但通常你此时不会打扰 QA。

这对于master始终保持高质量状态的健康工作流程非常重要。这意味着开发人员必须参与测试过程。没有把它扔给 QA 并希望得到最好的结果，QA 应该把时间花在验收和黑盒测试上，以捕获开发人员不会想到的错误。 Master 永远是你的 Release Candidate。

当您决定准备发布时...

1. 将testing分支匹配到master。
   1. 您可以与 合并master、变基master或删除并重新创建testing分支。它们每个都有轻微的优点和缺点，这些优点和缺点将变得显而易见。
2. QA 获取自上次发布以来添加的所有更改的列表。
   1. 他们可以从问题跟踪器中获取此信息。
   2. 如果testing重新定位，master他们可以git log查看自上次发布以来的合并提交。
3. 让 QA 验收测试更改列表testing。

让我们暂停一下，解释为什么第 3 步很重要。QA 是用户看到之前的最后一行。QA 测试用户实际使用的内容很重要。用户将看到集成的代码库，而不是单独运行的单个功能分支，因此 QA 应将精力集中在集成版本上。

功能可以很好地单独工作，并且在组合时会产生奇怪的错误。一个简单的示例是将项目的编码从 ASCII 更改为 Unicode 的功能。开发人员尽职尽责地将整个系统更改为使用 Unicode，这很棒。与此同时，另一位开发人员正在执行一项任务，其中包括更改一些视图。他们没有考虑字符编码，他们用 ASCII 假设来写他们的观点。开发人员对测试视图很糟糕。单独测试，但功能分支工作正常。结合在一起，QA 可以捕获仍在使用错误字符编码的视图。

继续。

4. QA 发现错误并将其报告给开发人员。
   1. 开发人员补丁testing（直接针对小事情，在分支针对大事情）
   2. 可选的开发人员精心挑选这些修复回到master. 它是可选的，因为稍后会处理它。
5. QA 宣布testing准备发布。
   1. release是git merge --ff-only testing。如果它没有快进，则您有release需要向后移植的修补程序。
   2. release用版本号标记。
   3. release 被推向生产。
6. testing合并回master.

最后一步确保在 QA 过程中发现的任何错误补丁都将合并回master. 这就是为什么我之前说过，你如何重置并不重要testing，master无论如何它都会被合并回。

你有它。确保发布的所有代码都经过 QA 的过程。除了为 QA 开发更改日志外，没有仔细跟踪必要时集成的内容。