徐烜 / bsth-ebus-h5_editor · Commits

Commit 025bfddc6d05373c9069a7bc0c6c564d51f0f35d

Authored by 小小鲁班
Committed by GitHub
1 parent 643b36d2

Create CONTRIBUTING.md

Inline Side-by-side
Showing 1 changed file with 114 additions and 0 deletions
CONTRIBUTING.md 0 → 100644
  View file @025bfdd
  1 +# #!zh: 贡献指南
  2 +
  3 +## 原则
  4 +
  5 +- 透明开发: 目前 luban-h5 的所有工作都直接在 [GitHub](https://github.com/ly525/luban-h5) 上进行, 如果你有任何的问题或者建议, 都可以通过 [GitHub issues](https://github.com/ly525/luban-h5/issues) 进行提出和处理, 不提供 QQ 或者微信等直接问题解答(不过可以进行使用讨论);
  6 +- 语义版本控制: luban-h5 遵循 [语义版本控制](https://semver.org/lang/zh-CN/), 每个重大更改都记录在 [changelog](./CHANGELOG.md) 文件中;
  7 +- 分支策略: 采用主分支模型, 即 `master` 分支作为主分支, 当有新功能时, 创建 `feat/xxx` 分支, 当有 `bug` 时, 创建 `bug/xxx` 分支, 当新功能或者 bug 修改完毕, 需要发起 `pull request` , 如果管理人员审核通过, 则合并到`master`分支, 当收集到足够的 `feat/bug` , 发布版本更新;
  8 +- 包管理工具: 推荐使用 `yarn`, 而非 `npm`;
  9 +- 注释: 不写注释的程序员不是好码农, 对函数和复杂逻辑要尽量写注释;
  10 +- 简单原则: 我们希望在增加新功能时, 尽量避免增加新的 `props`, 现在的 `props` 已经够多了, 对外暴露的接口越简单越好;
  11 +- 开发工具: 我们希望开发工具尽量使用 `vscode`, 代码格式化工具使用 `prettier`, 要尽量避免因为格式化工具产生不必要的代码变更, 比如 tab 从 2 个空格转为 4 个空格, 函数前加不加空格等;
  12 +
  13 +## BUG
  14 +
  15 +- 在提 issue 之前, 请确保你去 [搜索](https://github.com/ly525/luban-h5/issues) 过相关问题;
  16 +- 提 issue 时, 请确保能有一个可运行的最小 demo 和 错误堆栈, 以提供复现, 最好最好还能有相关的动图演示;
  17 +- 如果有相关问题的解决方案那就更完美了, 你可以提交一个 [Pull Request](#Pull-Request) 修复 bug;
  18 +
  19 +## 新功能
  20 +
  21 +新功能也是通过 [issue](https://github.com/ly525/luban-h5/issues) 界面提出的, 如果你想提新功能请遵循以下原则:
  22 +
  23 +- 首先去 issue 界面, 创建一个问题, 并且概述建议, 这样才能更好的讨论和接受;
  24 +- 如果能用代码实现自己提的建议就更完美了, 你可以参考 [Pull Request](#Pull-Request) 章节;
  25 +
  26 +## Pull Request
  27 +
  28 +### 完整流程
  29 +
  30 +[动图演示](https://juejin.im/pin/5d9fde09f265da1975255513)
  31 +
  32 +- `fork` 本项目到你的 GitHub;
  33 +- `git clone` 你 `fork` 的项目;
  34 +- 安装依赖 `./luban-h5.sh init`;
  35 +- 从master新建分支并检出新分支 `git checkout -b feat/(your-feature-name)` / `git checkout -b bug/(your-bug-name)`;
  36 +- 进行修改，确保负复杂逻辑和函数有相关的 `注释`, 请自测确保没有问题;
  37 +- `git push` 你的本地代码到 GitHub;
  38 +- 提交 `pull request`;
  39 +- 等待管理员处理。
  40 +- 管理员操作：
  41 + - [在本地checkout pr](https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/checking-out-pull-requests-locally)
  42 + - (可以合并至dev) 进行本地验证
  43 + - review code/merge pr
  44 +
  45 +### 分支说明
  46 +1. master: 主分支，即稳定分支
  47 +2. dev：验证、测试分支
  48 +3. feat/bug: feature/bug-fix分支
  49 +
  50 +### commit 提交规范
  51 +
  52 +目前主流的 Commit message 格式基本上都采用 [Angular](https://github.com/angular/angular) 规范，比较合理和系统化
  53 +
  54 +![image](https://raw.githubusercontent.com/dream2023/images/master/WX20191010-094948.knxlcg0o1tp.png)
  55 +
  56 +#### 格式说明
  57 +
  58 +Commit message 一般包括三部分：`Header`、`Body` 和 `Footer`。`Header` 是必需的，`Body` 和 `Footer` 可以省略。
  59 +
  60 +```
  61 +<type>(<scope>): <subject> // header部分
  62 +// 空行
  63 +<body>
  64 +// 空行
  65 +<footer>
  66 +```
  67 +
  68 +下面详细说明各部分写法规范：
  69 +
  70 +##### Header 部分
  71 +
  72 +只有一行，包括 `type`、`scope` 和 `subject` 三个字段。
  73 +
  74 +```bash
  75 +<type>(<scope>): <subject> # 括号为英文括号，冒号后面一定要有一个空格。
  76 +```
  77 +
  78 +**【type】（必需）**
  79 +
  80 +用于说明 commit 的类别，常见类别如下：
  81 +
  82 +- feat：新增功能
  83 +- fix：修复 bug
  84 +- docs：修订文档，如 Readme, Change Log, Contribute 等
  85 +- refactor：代码重构，未新增任何功能和修复任何 bug
  86 +- style： 仅调整空格、格式缩进等（不改变代码逻辑的变动）
  87 +- test：测试用例的增加/修改
  88 +- chore：非 src 和 test 的修改
  89 +- merge：合并分支或冲突等
  90 +- revert： 回滚到上一个版本
  91 +- build：改变构建流程，新增依赖库、工具等（例如 webpack 修改）
  92 +- ci：自动化流程配置修改
  93 +
  94 +**【scope】（可选）**
  95 +用于说明 commit 的影响范围，可以是页面名，组件名等，可以省略。
  96 +
  97 +**【subject】（可选）**
  98 +本次提交的简要描述，不超过 50 个字符，且结尾不加任何句号（.）。
  99 +
  100 +##### Body 部分
  101 +
  102 +对本次 commit 更详细的描述，可以分成多行，建议 72 个字符以内。需要描述的信息包括:
  103 +
  104 +- 为什么要提交这个变更，要解决什么问题
  105 +- 简要描述如何解决这个问题
  106 +- 是否存在副作用、风险？
  107 +
  108 +##### Footer 部分
  109 +
  110 +- 破坏性变更：需要描述相关信息
  111 +- 关闭指定 Issue 或 bug：输入 Issue 或 bug 信息
  112 +- 其他：可以添加一个链接到 issue 或 bug 的地址或者其它文档
  113 +
  114 +以上便是 commit 规范, 如果觉得上述描述过于复杂, 则将 `git commit` 替换成 `yarn commit`即可有交互式命令行提示。
... ...