在标准分公司计划检修分公司(Servicing Branch in Standard Branch

我有一个关于规格分支计划很简单的问题。

我明白分支，FI和RI，等我不太明白是如何使用维修分公司的做法。

我的理解是，当谈到时间来释放，我汊主- > R1.SP1（假设这是我的第一个版本，例如），然后立即跳转到R1.SP1 R1。 然后设置R1为只读。 这我完全理解并喜欢。

这就是我不明白：如何以及何时R1.SP1，R1.SP2，R1.SP3获得创建？

难道我RI SP1回到主，然后跳转到主SP2 / 3 / N随着时间的推移？

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

例如，如果客户报告中R1的错误，我在哪里校验码出从使这一变化，我在哪里签入/提交所更改/固定回？ 难道我检查到SP1分支？ （由于R1分支只读）。 然后呢？

我想我问哪里是我的持续发展发生创造R1未来SP和如何做这些获得创建并准备向自己的版本/部署？

一个很简单的一步一步的情况下的例子是最有帮助的/赞赏。

请，如果我的问题是不明确的，让我知道，我会尽我所能来修改。

Answer 1:

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.

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.

文章来源: Servicing Branch in Standard Branch Plan