Skip to content

Latest commit

 

History

History
124 lines (79 loc) · 5.41 KB

CONTRIBUTING.md

File metadata and controls

124 lines (79 loc) · 5.41 KB

Contributing to ConsoleOS

分支

主干分支

主干分支作为当前功能的稳定版本分支

  • 命名规则 使用 master 作为主干分支
  • 提交合并 不允许 直接向主干分支提交修改,只能通过发起 Pull Request 方式进行提交合并

Release 分支

Release 分支作为每一个 minor 或 major 版本的主干分支

  • 命名规则 使用预定要发布的的版本号作为分支名称,如 1.0.0
  • 提交内容 提交内容可以包含任意的功能性分支
  • 提交合并 不允许 直接向待发布分支提交修改,只能通过发起 Pull Request 方式进行提交合并

Bug 分支

Bug 分支用于修复并解决不符合程序预期的错误或问题,属于功能性分支

  • 命名规则 使用 fix 作为分支前缀,并以语义化的名称阐述该分支需要解决的问题,或者使用 gitlab issue id 作为名称。如 fix/memory-leakfix/83925
  • 提交内容 每个 Bug 分支只包含尝试解决特定的错误或问题和其衍生问题的提交,不允许 在同一个 Bug 分支中尝试修复不同领域的问题
  • 建立关联 在分支的提交信息中关联对应的 gitlab issue
  • 提交合并 可以发起 Pull Request 提交合并到 master 或其他 release 分支,合并之后 立即 删除该分支,不允许 在合并之后继续提交相同的 Bug 分支

Feature 分支

Feature 分支用来增加新的功能或特性,属于功能性分支

  • 命名规则 使用 feat 作为分支前缀,并以语义化的名称阐述该分支提供的功能或特性,或者使用 gitlab issue id 作为名称。如 feat/i18nfeat/83925
  • 提交内容 每个 Feature 分支必须包含对于特定功能或特性及其衍生功能的提交,不允许 在同一个 Feature 分支中尝试增加不同领域的功能或特性
  • 建立关联 在分支的提交信息中关联对应的 gitlab issue
  • 提交合并 可以发起 Pull Request 提交合并到 release 分支,不允许 提交到 master 分支。合并之后 立即 删除该分支,不允许 在合并之后继续提交相同的 Feature 分支

Chore 分支

Chore 分支用来解决与业务逻辑本身无关的问题,如依赖、构建过程或辅助工具的变动

  • 命名规则 使用 chore 作为分支前缀,并以语义化的名称阐述该分支带来的变更内容,或者使用 gitlab issue id 作为名称。如 chore/update-depschore/83925
  • 提交内容 每个 Chore 分支只能包含对于特定内容的提交,不允许 在同一个 Chore 分支中包含针对多个不同领域内容的提交
  • 建立关联 在分支的提交信息中关联对应的 gitlab issue
  • 提交合并 可以发起 Pull Request 提交合并到 masterrelease 分支。合并之后 立即 删除该分支,不允许 在合并之后继续提交相同的 Chore 分支

提交

所有提交需遵从 Angular Commit 规范

Header

Header部分只有一行,包括三个字段:type(必需)、scope(可选)和subject(必需)

{type}({scope}): {subject}

type 用于说明提交内容的类别,只允许使用下面7个标识

  • feat 表示该提交中包含了新的功能或特性
  • fix 表示该提交中包含了对于已知问题的修复
  • refactor 表示该提交中只包含代码重构,对现有的业务逻辑没有副作用
  • style 表示该提交中只包含对于代码格式的变动,对现有的业务逻辑没有副作用
  • chore 表示该提交中只包含依赖、构建过程或辅助工具的变动,对现有的业务逻辑没有副作用
  • docs 表示该提交中只包含对于文档或说明的改动
  • test 表示该提交中只包含对于测试用例的更新

scope 用于说明提交内容的影响范围,目前可选的影响范围包括

  • * 提交的内容可能产生多个关联影响
  • core 提交的内容只影响核心调度层
  • engine 提交的内容只影响构建引擎层
  • plugin 提交的内容只影响某一个插件

其他的 scope 可以在开发过程中逐渐补充

subject 用于简短描述提交的目的

  • 以动词开头,使用第一人称现在时
  • 第一个字母小写
  • 结尾不加标点符号
  • 长度根据 type 和 scope 综合限定,总体字符数量不超过 80 个字符(包含标点和空格)

Body

Body 部分用于详细阐述该次提交的内容,如背景、变更重点和关联信息等

  • 可以根据实际情况选择是否填写 Body 部分
  • 每一行的长度不超过 80 个字符(包含标点和空格)
  • Body 部分与其相邻的部分空 1 行

Footer

不兼容变更

如果当前代码与上一个版本不兼容,必须 在 Footer 部分声明不兼容变更

  • 标题 必须以 BREAKING CHANGE: 作为开头,后面跟随对变动的简要描述,不超过 80 个字符
  • 内容 不兼容变更的详细内容每行缩进 2 个空格,不超过 80 个字符

关闭关联 issue

如果当前提交解决了一个或多个 issue,可以在 Footer 部分声明关闭关联的 issue

  • 关闭一个 issue
Closes #90123
  • 关闭多个 issue
Closes #90123, #83311, #34910

发行版本

严格 遵从 semver 规范

PR 贡献者必须签署 CLA 协议

在提交 PR 以后会出现一个 CLA 协议让提交者签署,未签署 CLA 协议的 PR 不会被 merge。