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

Question

我一直在监视从每个冲刺开始的两个分支 - Release 和 Master。

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

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

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

这个问题是的延续和

我想在一行中

"Make sure that only development branches which are verified by QA goes to the next Release Candidate."

我考虑过使用之前讨论中的以下工作流选项；

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

这是你的问题。

We only merge branches committed to the Master and verified by the QA into Release branch.

这意味着你必须集成特性分支两次。一次进入 Master 并再次进入 Release。您正在与一个明显的问题作斗争：如何确保集成到 Master 中的所有内容都集成到 Release 中？而且由于功能建立在其他功能之上，因此它们必须采用相似的顺序。

不要试图解决这个问题。它又硬又乱，你总是要小心。最好有一个更简单的过程。让我们回到您设定的目标。

Make sure that only development branches which are verified by QA goes to the next Release Candidate.

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

Make sure that only code which has been verified by QA goes to the next Release.

看到我在那里做了什么吗？高质量的发布不关心代码来自哪里，它关心的是被发布代码的状态。您要确保没有任何未经 QA 检查的内容进入发布。为此，我建议将您的工作流程更改为 Gitflow Workflow 的版本。它是这样的。

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

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

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

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

将 testing 分支匹配到 master。
1. 您可以与 master 合并，在 master 上变基或删除并重新创建 testing 分支。它们各有优点和缺点，这将变得很明显。
QA 获取自上次发布以来添加的所有更改的列表。
1. 他们可以从问题跟踪器中获取。
2. 如果 testing 重新基于 master 他们可以 git log 并查看自上次发布以来的合并提交。
让 QA 验收根据 testing.

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

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

继续前进。

QA 发现错误并将其报告给开发人员。
1. 开发者补丁testing（小的直接打，大的在分支）
2. 可选开发人员将这些修复程序挑选回 master。它是可选的，因为稍后会处理它。
QA 宣布 testing 已准备好发布。
1. release 是 git merge --ff-only testing。如果它不快进，你在 release 中有修补程序需要向后移植。
2. 用版本号标记 release。
3. release 被推送到生产环境。
testing 合并回 master.

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

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

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

Git Development vs Release branch best practices

git

git-merge

git-rebase