标准分支计划中的服务分支

Question

关于标准分支计划，我有一个非常简单的问题。

我理解分支，FI和RI等。我不太明白如何在实践中使用Servicing分支。

我的理解是，到了发布的时候，我分支主要 - ＆gt; R1.SP1（假设这是我的第一个版本，例如）然后立即将R1.SP1分支到R1。然后将R1设置为只读。这完全是我理解和喜欢的。

以下是我不理解的内容：如何以及何时创建R1.SP1，R1.SP2，R1.SP3？

我是否将RI SP1恢复为主，然后随着时间的推移将主分支转换为SP2 / 3 / n？

换句话说，这些未来的SP如何填充自己的发布/部署的变化？

例如，如果客户报告R1中的错误，我在哪里检查代码以进行此更改以及在何处检入/提交已更改/修复的代码？我是否登记SP1分支机构？ （因为R1分支是只读的）。那又怎样？

我想我在问我的持续发展在哪里为R1创建未来的SP以及如何为他们自己的发布/部署创建和准备这些SP？

一个非常简单的一步一步的场景示例将是最有帮助/最受欢迎的。

如果我的问题不明确，请告诉我，我会尽力修改。

Answer 1

不是TFS专家，但我读到的是：

  

  
1. 开发人员只需根据更改所针对的发布工具签入一次（即，修补程序进入产品HOTFIX分支）。
  
2. 不需要毫无根据的合并。通过基于您的发布工具创建分层结构，创建一个返回MAIN的自然合并路径。
  
3. 降低回归风险。通过在MAIN->SP->和HOTFIX分支之间创建父/子分支关系，更改自然会合并到将来的版本中（即Hotfixes合并到SP分支到{MAIN分支的路上1}}）降低未来版本中的bug回归风险。
        

从MAIN创建发布分支后，您不应将（FI）合并到发布分支中。   更改应合并 - 单向 - 从RELEASE到MAIN   此外，更改应始终通过中间分支合并（即RELEASE - ＆gt; HOTFIX - ＆gt; SERVICEPACK - ＆gt; MAIN），以确保错误修复在后续保持一致版本

我认为上一节明确提到了一旦版本投入生产后合并的工作流程应该如何进行 它应该回到主要部分，直到合并到足以创建一组新的船舶（从服务，你选择一个版本来启动你的新SPx，到Hoyfix.spx，到release.spx）

---

OP user1448758在评论文章Where do I fix a production defect?中指出：

  

Release分支是hotfix或servicing分支的子代，而不是单独的分支结构。 这允许您为并行支持的每个次要或主要版本提供多个活动版本集（由Service Pack，Hotfix，Release分支组成）< / strong>即可。
  此修补程序将应用于发现错误的特定版本，然后合并（RI）到Main，并可能合并到vNext开发分支。

     

由于开发分支机构在vNext发布后正在处理vCurrent工作，我建议您不要修复vCurrent中vNext（发布后）中发现的缺陷发展部门   发布Sprint 1后，您应该在 Sprint 1 方面修复release中的缺陷（发布后），并修复Sprint中的错误（预发布） 2 development侧（vNext）。

Release是hotfix 的孩子。 在您创建发布时，hotfix和发布的内容相同。
Release已设为只读，Hotfix可用于针对已发布的内容进行缺陷修复。

  

反转结构的问题是，如果不经过hotfix就无法将Main移至Release，这样做意味着您不再拥有该版本的副本已发布的代码。