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

我从每个冲刺开始就一直在监控两个分支 -Release and Master.

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

Release分支是特定于冲刺的，始终可提交给生产。我们只合并致力于以下的分支Master并经核实QA进入发布分支。

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

这个问题是继续避免将主分支合并到开发分支中 https://stackoverflow.com/questions/29335603/avoid-merging-master-into-development-branch and git 合并仅分支特定提交 https://stackoverflow.com/questions/28742412/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 branch.

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

这是你的问题。

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

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

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

确保仅通过 QA 验证的开发分支转到下一个候选版本。

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

确保唯一经过 QA 验证的代码进入下一个版本。

看看我在那里做了什么？质量发布不关心代码来自哪里，它关心正在发布的代码的状态。您需要确保发布时不包含任何未经 QA 检查的内容。为此，我建议将您的工作流程更改为Gitflow 工作流程 https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow。事情是这样的。

1. 开发人员有任务要做。
2. 开发商分行master，我们称之为task.
3. Developer works on task.
   1. 开发人员编写自己的单元测试task.
4. Developer gets updates from master when they need them.
   1. 他们可以变基或者可以合并，这并不重要。
5. Developer finishes task.
   1. 开发人员进行了最终更新master.
   2. 开发人员确保他们的单元测试和所有回归测试都通过。
   3. Optional开发商提交task到 QA 进行验收测试。
   4. 开发商并入master.
   5. 开发者删除task.

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

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

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

1. Match the testing branch to master.
   1. 你可以合并master, 重新建立基础master或删除并重新创建testing分支。它们各自都有一些显而易见的优点和缺点。
2. QA gets a list of all changes which have been added since the last release.
   1. 他们可以从问题跟踪器中获取此信息。
   2. If testing已重新设定基础master他们能git log并查看自上次版本以来的合并提交。
3. 让 QA 验收测试变更列表testing.

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

功能在单独使用时可以很好地工作，但当它们组合在一起时就会出现奇怪的错误。一个简单的示例是将项目的编码从 ASCII 更改为 Unicode 的功能。开发人员尽职尽责地将整个系统更改为使用 Unicode，这非常棒。与此同时，另一位开发人员正在处理一项任务，其中包括更改一些视图。他们没有考虑字符编码，他们用 ASCII 假设来写下他们的观点。开发人员对于测试视图感到非常恐惧。单独测试，但功能分支工作正常。结合在一起，QA 可以捕捉到仍然使用错误字符编码的视图。

继续。

4. QA finds bugs and reports them back to the developers.
   1. 开发者补丁testing（小事直接做，大事放在分支）
   2. Optional开发人员精心挑选这些修复程序master。它是可选的，因为稍后会处理它。
5. QA declares testing ready for release.
   1. release is git merge --ff-only testing。如果它没有快进，则您有修补程序release需要向后移植。
   2. Tag release带有版本号。
   3. release被推向生产。
6. testing被合并回master.

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

你有它。确保所有发布的代码都经过质量检查的流程。除了为质量检查开发变更日志之外，没有在必要时仔细跟踪集成的内容。