注:此规范适用于各个项目仓库本身,故仅适用于具有直接向对应仓库直接进行推送权限的贡献者,对于发起 Pull Request 的形式参与代码贡献的贡献者可忽略此规范。
另注:若您是 deepin 员工且从事 非社区版 版本的开发,则请以公司另外提供的分支管理规范文档为准。
GitHub 下的 linuxdeepin 组织中包含了 Deepin 社区版所涉及的所有开源项目,也包含了非社区版项目的相应仓库或分支。为方便管理和维护,也方便社区可以更好的理解 Deepin 的代码组织方式和利用项目代码,这些项目遵循一定的分支命名规范以便开发协作和管理。以下文档涵盖社区版相关的分支名称规范,用以给 Deepin 开源社区参考。
deepin 社区版为滚动发布制,一般没有维护分支,master
分支即为研发基线分支。
对于开发者,若需要多个提交才能完成一个特性时,由于研发过程使用 GitHub 的 Fork + Pull Request 模式,故也不需要单独创建研发分支。但特殊情况下,若确需使用研发分支,则可使用 develop/*
作为临时的特性研发分支。
当项目发布时,若有维护计划,则使用 release/${系统版本代号}
或 release/${tag}
作为发布分支。
如上可概括为:
master
研发主干,开发分支develop/*
仅特殊情况下允许使用的临时研发分支release/*
版本发布和旧版本维护分支我们会在开发告一段落时,不定期发布软件版本。为了方便管理,我们使用了类似 semver 的版本号格式约定,格式为:
主版本号.功能版本.修复版本
版本号会体现在社区版发布的 git tag 中,也会体现在非社区版的维护分支中。