【转摘】TFS上分支和标签的用法

在使用版本控制系统时，您必须考虑如何设置分支结构。可以通过镜像源代码文件来创建一个分支。然后，可以在不影响源的情况下更改该分支。例如，如下图的分支结构所示，MAIN 分支包含已通过集成测试的已完成功能，而 DEVELOPMENT 分支包含团队正在构建的代码。当 DEVELOPMENT 分支中的新功能完成并可通过集成测试时，您可以将代码从 DEVELOPMENT 分支提升到 MAIN 分支中。此过程称为“反向集成”。反之，如果您将代码从 MAIN 分支合并到 DEVELOPMENT 分支中，则此过程称为“正向集成”。

有关如何创建和合并代码分支的更多信息，请参见 CodePlex 网站上的以下页面：Team Foundation Server Branching Guide 2.0（Team Foundation Server 分支指南 2.0）。

分支和合并需要遵循下列原则：

1. 每个分支都必须具有一个定义的策略，此策略与如何将代码集成到相应分支中有关。例如，在上图的分支结构中，可以指定一个团队成员来拥有和管理 MAIN 分支。该成员负责执行初始分支操作、将更改从 DEVELOPMENT 分支反向集成到 MAIN 分支，以及将更改从 MAIN 分支正向集成到 DEVELOPMENT 分支。当 MAIN 分支也从其他分支集成更改时，正向集成非常重要。

2. MAIN 分支必须包含已通过集成测试的代码，以便始终准备进行发布。

3. 由于团队成员会定期签入更改，因此 DEVELOPMENT（或工作）分支将不断演变。

4. 标签是分支中的文件在某个特定时间的快照。

   有关更多信息，请参见使用标签获取文件快照。

利用 Team Foundation Build，可以从分支的几种生成类型中进行选择：手动、连续、封闭、滚动和计划。建议 MAIN 分支具有封闭签入生成类型。这意味着，DEVELOPMENT 分支必须先通过 MAIN 分支的所有要求，然后您才能提交反向集成。DEVELOPMENT 分支应运行连续生成类型，因为团队必须尽快了解影响 DEVELOPMENT 分支的新签入的发生时间。

如下图所示，反向集成和正向集成应至少在用户情景完成时进行。虽然每个团队对于完成的定义可能不同，但完成用户情景通常意味着完成了功能和对应的单元测试。只能在单元测试验证 DEVELOPMENT 分支的稳定性后反向集成到 MAIN 分支中。

如果您具有多个工作（即 DEVELOPMENT）分支，则当任意分支集成到 MAIN 分支时应立刻正向集成到所有工作分支。因为 MAIN 分支保持稳定，所以正向集成是安全的。工作分支中可能会发生某些冲突或失败，这是因为无法保障工作分支是稳定的。

应尽快解决所有冲突，这非常重要。通过对 MAIN 分支使用封闭签入，可以使反向集成变得简单得多，因为质量要求可帮助避免 MAIN 分支中发生冲突或错误。有关更多信息，请参见签入到由封闭签入生成过程控制的文件夹。

如下图所示，可以定期将更改签入工作分支以完成用户情景。可以在同一分支中同时实现多个用户情景，但仅当所有进行中的工作都已完成时才能反向集成到 MAIN 分支。建议您按照类似大小对用户情景进行分组，因为您不希望大用户情景阻止多个小用户情景的集成。可以将两组用户情景拆分为两个分支。

以下情况下应创建分支：

• 在必须按与现有分支不同的时间表/周期发布代码时。

• 在代码需要不同的分支策略时。如果创建具有新策略的新分支，则可以为项目增添策略价值。

• 在向客户发布功能且团队打算进行不影响计划的发布周期的更改时。

不应对每个用户情景创建分支，因为这会产生较高的集成成本。虽然通过  可方便地进行分支，但在分支很多时，管理分支的开销可能会很大。

团队应能在任意冲刺 (sprint) 末尾发布代码。通过使用 Team Foundation Server，可以标记一个分支以在某个特定时间点为代码拍摄快照。如下图所示，可以为发布标记 MAIN 分支。这样，您可以将分支返回到此时间点时的状态。

因为必须在发布时实现更新，所以为发布创建分支可帮助团队继续独立处理下一个冲刺 (sprint)，而不会与将来的发布产生冲突。下图显示了一个分支，该分支包含更新代码，随后在第二个冲刺 (sprint) 末尾进行发布后，该分支反向集成到 MAIN 分支。

在为发布创建分支时，应从 MAIN 分支（该分支最稳定）创建分支。如果您从工作分支对发布进行分支，则会导致集成问题，因为无法保证工作分支的稳定性。

http://msdn.microsoft.com/zh-cn/library/ee782536.aspx

http://msdn.microsoft.com/zh-cn/magazine/gg598921.aspx