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

Question

我一直在监控两个分支，从每个冲刺开始 - Release 和 Master。 Master 分支是开发人员创建新分支（任务特定）、实现更改并创建拉取请求的地方，这些请求会合并到主分支中。 Release 分支是特定于冲刺的，始终可以提交到生产环境。我们只将提交到 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重新定位的，并由QAs进行验证。我可以轻松地将经过验证的分支重新定位回Release分支。

我走的方向正确吗？这个git-flow最好的工作方式是什么？有没有更好的方法来实现我想要达到的目标？

- Paresh Masani

---

你在个别任务方面的工作（例如你的命令序列示例）与确保只有经过测试的代码进入发布版本的目标有何关联并不明显，因此我不确定你在问什么。 - Magnus Bäck

作为最后一步，我建议使用 git merge --no-ff taskA。这样属于 taskA 开发的提交范围仍然在视觉上靠近。如果您需要查找由 taskA 引入的错误，这将非常有帮助。 - nils

为了实现我的目标，我必须确保个人开发分支的清晰分离，以便只合并经过验证的分支到发布版。如果我不这样做，那么我将遇到 http://stackoverflow.com/questions/28742412/git-merging-only-branch-specific-commits 问题。@MagnusBäck - Paresh Masani

@nils 谢谢你的建议。 - Paresh Masani

但任务分支不会直接合并到发布版本，而是要先合并到主分支，对吗？而发布分支是从主分支切出来的？你的另一个问题描述了当你从任务（功能）分支合并到发布分支时出现的问题，这确实是一个有问题的工作流程。 - Magnus Bäck

是的，那么你能否建议一些方法来实现我的目标：“确保只有经过QA验证的开发分支才能进入下一个发布候选版。”？我不想从QA验证单个分支，然后合并到主分支，因为这太烦人了，当开发分支合并到主分支时，测试人员必须再次测试东西！ - Paresh Masani

Answer 1

这是你的问题。

  

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

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

不要试图解决此问题。这很困难且混乱，您总是必须小心。最好拥有一个更加防护的过程。让我们回到您提出的目标。

  

确保仅验证了QA的开发分支进入下一个发布候选版。

(重点在我)那真的不是目标，而是实现目标的解决方案。您的真正目标是什么？这个怎么样...

  

确保仅经过QA验证的代码进入下一个发布版。

看到我做了什么吗？优质版本不关心代码来自哪里，只关心发行的代码状态。您希望确保未经QA检查的内容不会进入发布。为此，我建议将您的工作流更改为Gitflow Workflow的版本。它是这样的。

  
1. 开发人员有一个任务要完成。
  
2. 开发人员从主分支分支，称之为task。
  
3. 开发人员在task上工作。     
         
   1. 开发人员为task编写自己的单元测试。
       
     
  
4. 开发人员需要更新master时获取更新。     
         
   1. 他们可以变基或合并，无所谓。
       
     
  
5. 开发人员完成了task。     
         
   1. 开发人员从master进行最终更新。
         
   2. 开发人员确保其单元测试和所有回归测试都通过。
         
   3. 可选开发人员向QA提交task进行验收测试。
         
   4. 开发人员合并到master。
         
   5. 开发人员删除task。
       
     

因为开发人员正在编写自己的单元测试，所以此时您知道master中的所有内容都已通过单元和集成测试。在5.3中进行了重要或棘手功能的验收测试，但通常您不会在这个阶段使用QA。

保持master分支的高质量状态对于一个健康的工作流非常重要，这意味着开发人员必须参与测试过程。不能把它扔给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. release被推送到生产环境。
6. testing被合并回master。

最后一步确保在QA过程中发现的任何补丁都将合并回master。这就是我之前说的重置testing的方法并不重要的原因，因为它最终都会合并回master。

以上是确保所有发布的代码都经过QA流程的一个过程。除了为QA开发变更日志之外，没有对必要的集成进行仔细跟踪。

- Schwern

---

感谢@Schwern抽出时间。我会重新思考我们的流程。 - Paresh Masani