关于分支和分支策略
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
分支策略是 Git 工作流的重要部分，可实现以下目的：
- 将正在进行的工作与主分支中已完成的工作隔离开来
- 保证更改在到达主分支之前生成
- 限制可以参与特定分支的人员
- 强制规定可以创建分支和分支命名准则的人员
- 对每个代码更改自动包含适当的审阅者
- 与所需的代码审阅者强制实施最佳做法
下表汇总了可定义的策略，可使用这些策略自定义分支。 有关所有存储库以及分支策略和设置的概述，请参阅 Git 存储库设置和策略。
策略
默认值
说明
关
需要拉取请求获得指定数量的审阅者的批准。
关
通过检查拉取请求的链接工作项来提高可跟踪性。
关
检查是否已解决拉取请求的所有注释。
关
通过在拉取请求完成时限制可用的合并类型，可以控制分支历史记录。
关
添加一个或多个策略以通过预合并和生成拉取请求更改来验证代码。 也可启用或禁用策略。
关
添加一个或多个策略以要求其他服务发布成功状态才能完成拉取请求。 也可启用或禁用策略。
关
添加一个或多个策略以指定在拉取请求更改特定代码区域时自动包含的代码审阅者。 也可启用或禁用策略。
采用 Git 分支策略
存储库中有几个关键分支（如 main 分支），团队依赖这些分支始终处于良好状态。
需要拉取请求才能在这些分支上进行任何更改。 对于直接向受保护的分支推送更改的开发人员，他们的推送将被拒绝。
从以下三个概念构建策略，简化分支策略：
- 将功能分支用于所有新功能和 bug 修复。
- 使用拉取请求将功能分支合并到主分支。
- 使主分支保持高质量、最新状态。
扩展这些概念并避免矛盾的策略可为团队生成一致且易于遵循的版本控制工作流。
在分支中创建工作
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 修复之间切换。
分支操作指南
了解如何完成使用分支时的常见任务。
相关文章
反馈
即将发布：在整个 2024 年，我们将逐步淘汰作为内容反馈机制的“GitHub 问题”，并将其取代为新的反馈系统。 有关详细信息，请参阅：https://aka.ms/ContentUserFeedback。
提交和查看相关反馈