Git Branch Naming Conventions

注：此规范适用于各个项目仓库本身，故仅适用于具有直接向对应仓库直接进行推送权限的贡献者，对于发起 Pull Request 的形式参与代码贡献的贡献者可忽略此规范。

另注：若您是 Deepin 员工且从事 非社区版 版本的开发，则请以公司另外提供的分支管理规范文档为准。

Git 分支命名规范

GitHub 下的 linuxdeepin 组织中包含了 Deepin 社区版所涉及的所有开源项目，也包含了非社区版项目的相应仓库或分支。为方便管理和维护，也方便社区可以更好的理解 Deepin 的代码组织方式和利用项目代码，这些项目遵循一定的分支命名规范以便开发协作和管理。以下文档涵盖社区版相关的分支名称规范，用以给 Deepin 开源社区参考。

分支概览

社区版相关分支

Deepin 社区版为滚动发布制，没有维护分支，故 Deepin 社区版所涉及的分支共两种，即：

• 基线分支：master
• 开发分支：dev/community/<特性名称简写>

对于开发者，若需要多个提交才能完成一个特性时，可使用开发分支，其余情况可考虑使用 Fork 后发起 Pull Request 到 master 分支的形式贡献代码。

对于不匹配上述格式的分支即与社区版无关的分支。

非社区版相关分支

非社区版项目和社区版项目的基线一致，均为 master。非社区版实际需求随产品线而定，使用其产品线名称对应的开发分支，且可能存在维护分支。

• 基线分支：master
• 开发分支：dev/<产品线名>/<特性名称简写>
• 维护分支：maintain/<版本号> 与 maintain/<版本号>_<产品线名>

出于非社区版项目特殊性，此处不再覆盖关于产品线相关的详细描述介绍，仅描述大致名称规范以便开源社区了解分支的大体规范。

版本号约定

我们会在开发告一段落时，不定期发布软件版本。为了方便管理，我们使用了类似 semver 的版本号格式约定，格式为：

主版本号.功能版本.修复版本

版本号会体现在社区版发布的 git tag 中，也会体现在非社区版的维护分支中。