其他分支¶
在前面的章节中，我们提到了 master 分支的使用（代表当前活跃的开发）和 稳定分支（发布符合稳定分支策略的回移植）。在特定条件下，可以设置其他类型的分支，本章将详细介绍它们。
特性分支¶
一些复杂的功能或重要的重构可能需要很长时间才能开发到可以合并到 master 分支的程度。将这些功能作为一系列补丁集维护会非常痛苦。为了处理这些特殊情况，项目可以创建特性分支，以便在一个临时的 git 分支中进行大型功能的迭代。
创建分支¶
特性分支应该不常使用，因为它们绕过了常规的 CI 测试，并且通常在工作需要合并回 master 时会导致额外的痛苦和努力。
可以使用与创建稳定分支相同的机制来请求新的特性分支。向 releases 仓库提交一个补丁，定义一个新的 feature/feature-name 分支。将 location 值设置为要创建特性分支的仓库和提交哈希
---
branches:
- name: feature/example-feature-work
location:
openstack/oslo.config: 02a86d2eefeda5144ea8c39657aed24b8b0c9a39
有关更多详细信息，请参阅 openstack/releases README.rst 文件。
命名分支¶
特性分支的命名使用“feature/”前缀。该前缀之后的内容由项目决定，但通常应描述将在该分支上开发的功能。
维护团队¶
与稳定分支不同，特性分支不由单独的团队管理。它们由项目的核心评审团队直接管理，就像 master 分支一样。
Bug 分支¶
遵循独立或中间发布模型的项目，特别是库项目，可能会发现它们需要在周期中间发布错误修复。通常，即使存在新功能，也应该从项目的 master 分支进行此操作。稳定分支的修复也受支持（请参阅 稳定分支）。但是，有时需要将修复程序发布到 master 测试环境中，而无需发布项目的当前 master 分支，因为存在尚未准备好发布的其他破坏性更改。对于这些情况，可以使用“bug/”前缀从之前的发布标签创建分支，并从该分支发布修复程序。
创建分支¶
Bug 分支应该极少使用，因为它们代表了一种偏离正常开发流程的版本发布机制。新的 bug 分支将由发布团队在项目团队的要求下创建，并在评估分支的必要性之后。只有当项目的 master 分支上存在无法发布的破坏性更改时，才应创建分支。
命名分支¶
来自 bug 分支的发布必须仅包含修复程序，不包含任何功能，因此可以赋予 SemVer 补丁版本，仅递增版本号的第三部分。该分支必须从之前的发布点创建，并且该发布的版本号的前两个部分将用作分支名称。创建分支后，只能从该分支创建该库的 major/minor 版本的补丁发布，并且 master 分支的下一个发布必须至少递增库的 minor 版本。
示例分支名称
1.12.0 -> bug/1.12
2.4.1 -> bug/2.4
合适的提交¶
只有关键修复程序，例如 gate 阻塞或安全问题，才能包含在 bug 分支中。对 bug 分支的所有补丁都必须被视为回移植，并在 bug 分支之前合并到 master 分支。
维护团队¶
与稳定分支不同，bug 分支不由单独的团队管理。它们由项目的核心评审团队与发布管理团队合作管理。
Driverfixes 分支¶
一些项目包含外部设备或其他供应商支持的插件的驱动程序。已经发现，对于这些项目来说，一旦稳定分支达到 Phase II 或更高阶段，驱动程序的修复程序将不再被接受。这导致许多供应商维护自己的稳定树，一些修复程序包含在一个供应商的仓库中，而其他修复程序包含在另一个供应商的仓库中。
为了提供一个通用的地方，供发行版在正常稳定策略允许之后拉取驱动程序修复程序，这些项目可以创建一个 driverfixes 分支。
警告
明确地，不期望任何 driverfixes 分支都保持在可部署状态。它们仅用作驱动程序修复程序的中央收集点，并且不会使用安全或其他关键更新进行更新，这些更新将发送到正常的 stable/* 分支
创建分支¶
driverfixes 分支通常在稳定版本过渡到 Phase II 支持时创建。项目团队何时以及是否创建 driverfixes 分支由他们自行决定。该分支本身是从它所支持的 stable/* 分支的当前头部创建的。
命名分支¶
driverfixes 分支应以它们分支的发布版本和它们所针对的代码命名。例如，对于 Ocata 版本的驱动程序修复程序，该分支应命名为 driverfixes/ocata，对于 Pike，driverfixes/pike，依此类推。
合适的提交¶
只能包含驱动程序代码的修复程序。不允许对任何非驱动程序代码进行更改。对 bug 分支的所有补丁都必须被视为回移植，并在 bug 分支之前合并到 master 分支。
对于引入的任何更改，Pep8 和单元测试应继续通过。
维护团队¶
与稳定分支不同，driverfixes 分支不由单独的团队管理。它们由项目的核心评审团队管理。
