Git Development vs Release分支最佳实践

Question

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

Master分支来自开发人员创建新分支（特定于任务），实现其更改，并创建拉入请求，并将其合并到主服务器中。

Release分支是sprint特定的，仍然可以提交给生产。我们只将提交到Master并由QA验证的分支合并到Release分支中。

这种方法最适合我们，因为我们定期修复Release并且已经实施并验证了特定功能，因此我们确切知道下一版本中会发生什么。

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

在一行中我想

＆＃34;确保只有经QA验证的开发分支才会转到下一个候选发布版。＆＃34;

我曾考虑使用之前讨论中的以下工作流程选项;

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永远是您的候选发布者。

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

1. 将testing分支与master匹配。
   1. 您可以与master合并，master上的rebase或删除并重新创建testing分支。它们各自都有一些优点和缺点，这些优点和缺点将会变得明显。
2. QA获取自上次发布以来已添加的所有更改的列表。
   1. 他们可以从问题跟踪器中获取此信息。
   2. 如果testing重新关闭master，他们可以git log查看自上次发布以来的合并提交。
3. 让QA验收对testing。
测试更改列表

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

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

继续前进。

1. QA发现错误并将其报告给开发人员。
   1. 开发人员修补testing（直接用于小事情，在大型事物的分支中）
   2. 可选开发人员将这些修补程序挑选回master。它是可选的，因为它将在以后处理。
2. QA声明testing准备发布。
   1. release是git merge --ff-only testing。如果它没有快进，则release中的修补程序需要向后移植。
   2. 使用版本号标记release。
   3. release被推向生产。
3. testing合并回master。

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

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