Azure DevOps Services |Azure DevOps Server |Azure DevOps Server 2022 |Azure DevOps Server 2020
分支策略是 Git 工作流的重要组成部分，使你能够：
- 将正在进行的工作与主分支中已完成的工作隔离开来
- 在更改进入 main 之前保证生成更改
- 限制可参与特定分支的人员
- 强制实施谁可以创建分支和分支的命名准则
- 为每个代码更改自动包括正确的审阅者
- 使用所需的代码审阅者强制实施最佳做法
下表汇总了可用于自定义分支的策略。 有关所有存储库和分支策略和设置的概述，请参阅 Git 存储库设置和策略。
Policy
默认
说明
关闭
需要对拉取请求的指定数量的审阅者进行审批。
关闭
通过检查拉取请求中的链接工作项来鼓励可追溯性。
关闭
检查是否已解决拉取请求的所有注释。
关闭
通过在完成拉取请求时限制可用的合并类型来控制分支历史记录。
关闭
添加一个或多个策略，通过预先合并和生成拉取请求更改来验证代码。 还可以启用或禁用策略。
关闭
添加一个或多个策略，要求其他服务发布成功状态以完成拉取请求。 还可以启用或禁用策略。
关闭
添加一个或多个策略以指定代码审阅者在拉取请求更改某些代码区域时自动包含。 还可以启用或禁用策略。
采用 Git 分支策略
存储库中有一些关键分支，团队始终依赖于它保持良好的状态，例如 main 分支。
要求拉取请求 在这些分支上进行任何更改。 将更改直接推送到受保护分支的开发人员将拒绝其推送。
通过从以下三个概念构建策略，使分支策略保持简单：
- 对所有新功能和 bug 修复使用功能分支。
- 使用拉取请求将功能分支合并到主分支。
- 保持高质量的 up-to-date 主分支。
扩展这些概念并避免矛盾的策略会导致团队的版本控制工作流保持一致且易于遵循。
在分支中创建工作
Git 分支与其说是保留提交确切历史记录的小型引用，不如说是创建它们很便宜。
将更改提交 到分支不会影响其他分支。 你可以与他人共享分支，而无需将更改合并到主项目中。
可以创建新分支，以隔离功能更改或主分支和其他工作中的 bug 修复。
由于分支是轻量级的，因此可在分支之间快速轻松地切换。 使用分支时，Git 不会创建源的多个副本，它使用提交中存储的历史记录信息在开始处理分支时重新创建分支上的文件。
Git 工作流应创建和使用分支来管理功能和 bug 修复。
Git 工作流的其余部分，例如通过拉取请求共享代码和查看代码。
在分支中隔离工作使通过更改当前分支来更改所处理的内容变得简单。
如何创建 Git 分支？
使用 branch 命令创建分支。
Branch 在 Git 中为新分支创建引用，并返回指向父提交的指针，以便 Git 可以在向分支添加提交时保留更改的历史记录。
使用其他人共享的分支时，Git 会保留上游跟踪关系。 该关系将本地存储库上的分支与远程存储库上的相应分支相关联。
在此屏幕截图中，可以看到从主分支创建的新分支。 分支和提交的工作将继续添加到这两个分支。
Git 始终向当前本地分支添加新提交。 在提交之前，请检查正在处理的分支，以免将更改提交到错误的分支。
使用 checkout 命令在本地分支之间进行交换。 Git 将更改计算机上的文件，以匹配签出分支上的最新提交。
当分支中的工作准备好与团队的其余部分共享时，可以 推送 更改以更新远程分支。
一个常见的错误是进行一些更改，它们 commit 意识到你位于错误的分支上，然后 checkout 切换到正确的分支。
最近的更改将不再位于文件系统上，因为每个分支都有自己的代码版本。
Git 会将文件的状态返回到交换到的分支上的上次提交，而不是你在其中进行更改的上一个分支。
使用分支管理开发
Git 会跟踪你正在处理的分支，并确保在分支中 checkout ，文件与分支上的最新提交相匹配。
分支允许同时在同一本地 Git 存储库中处理多个版本的源代码。
告知 Git 要使用的 checkout分支，Git 负责为该分支设置正确的文件版本。
使用分支隔离工作时，系统上不需要多个存储库。
克隆后一次设置开发环境。 然后，使用 Git 分支在功能工作和 bug 修复之间交换。
分支作指南
了解如何在使用分支时完成常见任务。