Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
源代码是开发工作的重要资产。 但是，当多个开发人员同时处理文件更新时，有效管理和改进源文件可能是一项挑战。 可以使用版本控制系统将源代码存储在共享存储库中、隔离并行开发工作、集成代码更改以及恢复以前的文件版本。 版本控制中的一个关键元素是分支，可实现同时开发。 如果以战略方式分支，则可以维护软件多个版本的顺序和一致性。
Team Foundation 提供灵活可靠的版本控制系统。 你可以使用 Team Foundation 版本控制在开发源代码、文档、工作项和其他团队处理的关键信息期间管理多个修订。
团队如何管理代码，同时通过多个项目版本引入多个更改？
使用版本控制系统时，必须考虑如何设置分支结构。 可以通过镜像源代码文件来创建分支。 然后，可以在不影响源的情况下更改分支。 例如，如下图所示的分支结构，MAIN 分支包含已通过集成测试的已完成功能，而 DEVELOPMENT 分支包含正在构造的代码。 当开发分支中的新功能完成并可以通过集成测试时，可以将代码从开发分支提升到 MAIN 分支。 此过程称为反向集成。 相反，如果将代码从 MAIN 分支合并到 DEVELOPMENT 分支，则过程称为转发集成。
有关如何创建和合并代码分支的详细信息，请参阅 CodePlex 网站上的以下页面： Team Foundation Server Branching Guide 2.0。
分支和合并需要以下原则：
每个分支必须具有有关如何将代码集成到此分支的已定义策略。 例如，在上图的分支结构中，可以分配团队成员拥有和管理 MAIN 分支。 此成员负责执行初始分支作，将来自 DEVELOPMENT 分支的更改反向集成到 MAIN 分支，并将更改从 MAIN 分支转发到 DEVELOPMENT 分支。 当 MAIN 分支还集成来自其他分支的更改时，向前集成非常重要。
MAIN 分支必须包含已通过集成测试的代码，以便始终准备好发布。
DEVELOPMENT（或工作）分支在不断演化，因为团队成员会定期签入更改。
标签是特定时间分支中文件的快照。
有关详细信息，请参阅 使用标签拍摄文件快照。
使用 Team Foundation Build，您可以从分支的多种构建类型中进行选择：手动、连续、有条件的、滚动和计划。 建议为 MAIN 分支选择封闭签入生成类型。 这意味着 DEVELOPMENT 分支必须通过 MAIN 分支的所有需求，然后您才能提交反向集成。 DEVELOPMENT 分支应运行连续生成类型，因为团队必须尽早知道新签入何时会影响 DEVELOPMENT 分支。
团队应该如何反向集成和向前集成？
如下图所示，应至少在完成某个用户情景时执行反向集成和正向集成。 尽管每个团队可能以不同的方式定义完整性，但用户情景的完成通常意味着你同时完成功能和相应的单元测试。 只有在单元测试验证开发分支的稳定性后，才能反向集成到 MAIN 分支。
如果有多个工作 (DEVELOPMENT) 分支，则只要有任何分支集成到 MAIN 分支，便应向所有工作分支进行正向集成。 由于 MAIN 分支保持稳定，因此向前集成是安全的。 工作分支中的冲突或失败可能会发生，因为无法保证工作分支稳定。
请务必尽快解决所有冲突。 通过将封闭签入用于 MAIN 分支，可帮助使反向集成更容易，因为质量把关可帮助避免 MAIN 分支中出现冲突或错误。 有关详细信息，请参阅签入到由封闭签入生成过程控制的文件夹。
团队如何管理实现不同用户情景的源？
如下图所示，可以定期将更改签入工作分支以完成用户情景。 可以同时在同一分支中实现多个用户情景。 但是，只有在完成所有正在进行的工作后，才能反向集成到 MAIN 分支。 建议按类似大小对用户情景进行分组，因为不希望大型用户情景阻止许多小情景的集成。 可以将两组用户情景拆分为两个分支。
团队应何时添加分支？
应在以下情况下创建分支：
当必须按与现有分支不同的计划/周期发布代码时。
当代码需要不同的分支策略时。 如果创建具有新策略的新分支，则可以向项目添加战略价值。
当向客户发布功能时，你的团队计划进行不影响计划发布周期的更改。
不应为每个用户情景创建分支，因为它会产生较高的集成成本。 尽管 TFVC 使分支变得简单，但如果有多个分支，则管理分支的开销可能会变得重要。
团队如何从版本控制的角度管理发布？
团队应该能够在任何迭代结束时发布代码。 通过使用 Team Foundation Server，可以标记分支以在特定时间点拍摄代码的快照。 如下图所示，可以标记一个版本的 MAIN 分支。 这样，便可以将分支返回到其此时的状态。
由于必须对发布实施更新，因此为发布创建分支可帮助团队继续独立处理下一个迭代周期，而避免将来发布的冲突。 下图显示一个分支，其中包含更新代码，会在第二个冲刺 (sprint) 结束时进行发布之后反向集成到 MAIN 支中。
为发布创建分支时，应从 MAIN 分支创建该分支，这是最稳定的分支。 如果从工作分支为发布创建分支，则可能会导致集成难题，因为无法保证工作分支的稳定性。