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

Question

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

Master分支是开发人员创建新分支(特定于任务)、实现更改并创建合并到Master中的拉请求的地方。

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

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

这个问题是避免将master合并到开发分支的延续和git合并只提交特定于分支的

在一行中，我想

"确保只有经过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的清晰历史记录，CCD_8将由QA验证。我可以很容易地将已验证的分支重新设置为Release分支。

我的方向对吗？这个git流最有效吗？有没有更好的方法来实现我想要实现的目标？

Answer 1

这是您的问题。

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

这意味着您必须集成功能分支两次。一次进入Master，一次进入Release。您正在努力解决一个显而易见的问题：如何确保集成到Master中的所有内容都集成到Release中？由于功能建立在其他功能的基础上，所以它们必须按照类似的顺序。

不要试图解决这个问题。这又难又乱，你必须时刻小心。最好有一个更简单的过程。让我们回到你的既定目标上来。

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

(强调矿)这不是真正的目标，而是实现目标的解决方案。你真正的目标是什么？这个怎么样。。。

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

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

1. 开发人员有一项任务要做
2. 开发人员从master分支，我们称之为task
3. 开发人员在task上工作。
   1. 开发人员为task编写自己的单元测试
4. 开发人员在需要时从master获得更新。
   1. 它们可以重新建立基础，也可以合并，这无关紧要
5. 开发者完成task。
   1. Developer对master进行最后更新
   2. 开发人员确保他们的单元测试和所有回归测试都通过
   3. 可选开发人员将task提交给QA进行验收测试
   4. Developer合并到master中
   5. 开发人员删除task

因为开发人员正在编写自己的单元测试，所以在这一点上，您知道master中的所有内容都经过了单元和集成测试。在5.3中已经对一些重要或棘手的特性进行了验收测试，但一般来说，在这一点上您不会打扰QA。

CCD_ 21始终保持在高质量的状态对于健康的工作流程非常重要。这意味着开发人员必须参与测试过程。不能把它抛给QA，抱着最好的希望，QA应该把时间花在验收和黑盒测试上，以捕捉开发人员不会想到的错误Master始终是您的发布候选。

当你决定准备发布时。。。

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. CCD_ 38投入生产
6. 39被合并回到CCD_ 40中

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

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