关于分支和分支策略
Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018
分支策略是 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 修复之间交换。
分支操作指南
了解如何在处理分支时完成常见任务。