2

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

我了解分支，FI和RI等。我不太了解的是如何在实践中使用Servicing分支。

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

这是我不明白的：如何以及何时创建 R1.SP1、R1.SP2、R1.SP3？

随着时间的推移，我是否将 RI SP1 返回到 main，然后将 main 分支到 SP2/3/n？

换句话说，这些未来的 SP 如何为自己的发布/部署进行更改？

例如，如果客户报告 R1 中的错误，我应该从哪里签出代码以进行此更改，以及在哪里签入/提交更改/修复的代码？我要签到 SP1 分支吗？（因为 R1 分支是只读的）。然后呢？ 

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

一个非常简单的分步场景示例将是最有帮助/赞赏的。

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

4

1 回答 1

2

Not a TFS specialist, but what I read is:

  1. Developers only need to check in once based on which release vehicle the change is for (i.e. Hotfixes go into the product HOTFIX branch).
  2. No need for baseless merges. Create a natural merge path back to MAIN by creating a hierarchal branch structure based on your release vehicles.
  3. Reduce risk of regressions. By creating a parent/child branch relationship between MAIN->SP-> and HOTFIX branches changes are naturally merged into future release (i.e. Hotfixes merge into the SP branch on their way to MAIN) reducing risk of bug regressions in future releases.

After the release branches are created changes from MAIN you should not merge (FI) into the release branches.
Changes should merge – one way – from RELEASE to MAIN.
Also, changes should always merge through intermediate branches (i.e. RELEASE -> HOTFIX -> SERVICEPACK -> MAIN) to ensure that bug fixes remain consistent in subsequent releases.

Advanced branch Plan

I think that last section explicitly mentions how the workflow of merges should go once a version has been released into production.
It should go back to main until enough has been consolidated in order to create a new set of ship vehicles (from servicing, where you choose a version to start your new SPx, to Hoyfix.spx, to release.spx)

The OP user1448758 points out in the comment the article Where do I fix a production defect? which mentions:

The Release branch is a child of the hotfix or servicing branch, rather than in a separate branching structure. This allows you to have multiple active release sets (consisting of Service Pack, Hotfix, Release branches) for each of the minor or major releases you need to support in parallel.
The hotfix would be applied to the specific release the bug is found in, and then merged (RI) to Main and possibly into vNext development branches.

Since the development branches are working on vNext work after vCurrent is released, I discourage you from fixing defects found in vCurrent (post-release) in the vNext development branch.
After you release Sprint 1, you should fix defects (post-release) in Sprint 1 on the release side, and fix bugs (pre-release) in Sprint 2 on the development side (vNext).

Release is a child of hotfix. At the time you create the release, the contents of hotfix and release are the same.
Release is made read-only and Hotfix is available for making defect fixes against what was released.

The problem with inverting the structure, is you cannot move a hotfix to Main without going through Release, and doing so means you no longer have a copy of the code as released.

于 2012-09-15T22:02:19.590 回答