1 | # 代码贡献规范
|
2 |
|
3 | 有任何疑问,欢迎提交 [issue](https://github.com/antvis/g2-brush/issues),
|
4 | 或者直接修改提交 [PR](https://github.com/antvis/g2-brush/pulls)!
|
5 |
|
6 | ## 提交 issue
|
7 |
|
8 | - 请确定 issue 的类型。
|
9 | - 请避免提交重复的 issue,在提交之前搜索现有的 issue。
|
10 | - 在标签(分类参考**标签分类**), 标题 或者内容中体现明确的意图。
|
11 |
|
12 | 随后 AntV 负责人会确认 issue 意图,更新合适的标签,关联 milestone,指派开发者。
|
13 |
|
14 | ## 提交代码
|
15 |
|
16 | ### 提交 Pull Request
|
17 |
|
18 | 如果你有仓库的开发者权限,而且希望贡献代码,那么你可以创建分支修改代码提交 PR,AntV 开发团队会 review 代码合并到主干。
|
19 |
|
20 | ```bash
|
21 | # 先创建开发分支开发,分支名应该有含义,避免使用 update、tmp 之类的
|
22 | $ git checkout -b branch-name
|
23 |
|
24 | # 开发完成后跑下测试是否通过,必要时需要新增或修改测试用例
|
25 | $ npm test
|
26 |
|
27 | # 测试通过后,提交代码,message 见下面的规范
|
28 |
|
29 | $ git add . # git add -u 删除文件
|
30 | $ git commit -m "fix(role): role.use must xxx"
|
31 | $ git push origin branch-name
|
32 | ```
|
33 |
|
34 | 提交后就可以在 [g2-brush](https://github.com/antvis/g2-brush/pulls) 创建 Pull Request 了。
|
35 |
|
36 | 由于谁也无法保证过了多久之后还记得多少,为了后期回溯历史的方便,请在提交 MR 时确保提供了以下信息。
|
37 |
|
38 | 1. 需求点(一般关联 issue 或者注释都算)
|
39 | 2. 升级原因(不同于 issue,可以简要描述下为什么要处理)
|
40 | 3. 框架测试点(可以关联到测试文件,不用详细描述,关键点即可)
|
41 | 4. 关注点(针对用户而言,可以没有,一般是不兼容更新等,需要额外提示)
|
42 |
|
43 | ### 代码风格
|
44 |
|
45 | 你的代码风格必须通过 eslint,你可以运行 `$ npm run lint` 本地测试。
|
46 |
|
47 | ### Commit 提交规范
|
48 |
|
49 | 根据 [angular 规范](https://github.com/angular/angular.js/blob/master/CONTRIBUTING.md#commit-message-format)提交 commit,
|
50 | 这样 history 看起来更加清晰,还可以自动生成 changelog。
|
51 |
|
52 | ```xml
|
53 | <type>(<scope>): <subject>
|
54 | <BLANK LINE>
|
55 | <body>
|
56 | <BLANK LINE>
|
57 | <footer>
|
58 | ```
|
59 |
|
60 | (1)type
|
61 |
|
62 | 提交 commit 的类型,包括以下几种
|
63 |
|
64 | - feat: 新功能
|
65 | - fix: 修复问题
|
66 | - docs: 修改文档
|
67 | - style: 修改代码格式,不影响代码逻辑
|
68 | - refactor: 重构代码,理论上不影响现有功能
|
69 | - perf: 提升性能
|
70 | - test: 增加修改测试用例
|
71 | - chore: 修改工具相关(包括但不限于文档、代码生成等)
|
72 | - deps: 升级依赖
|
73 |
|
74 | (2)scope
|
75 |
|
76 | 修改文件的范围
|
77 |
|
78 | (3)subject
|
79 |
|
80 | 用一句话清楚的描述这次提交做了什么
|
81 |
|
82 | (4)body
|
83 |
|
84 | 补充 subject,适当增加原因、目的等相关因素,也可不写。
|
85 |
|
86 | (5)footer
|
87 |
|
88 | - **当有非兼容修改(Breaking Change)时必须在这里描述清楚**
|
89 | - 关联相关 issue,如 `Closes #1, Closes #2, #3`
|
90 |
|
91 | 示例
|
92 |
|
93 | ```
|
94 | fix($compile): [BREAKING_CHANGE] couple of unit tests for IE9
|
95 |
|
96 | Older IEs serialize html uppercased, but IE9 does not...
|
97 | Would be better to expect case insensitive, unfortunately jasmine does
|
98 | not allow to user regexps for throw expectations.
|
99 |
|
100 | Document change on antvis/g2#12
|
101 |
|
102 | Closes #392
|
103 |
|
104 | BREAKING CHANGE:
|
105 |
|
106 | Breaks foo.bar api, foo.baz should be used instead
|
107 | ```
|
108 |
|
109 | 查看具体[文档](https://docs.google.com/document/d/1QrDFcIiPjSLDn3EL15IJygNPiHORgU1_OOAqWjiDU5Y/edit)
|
110 |
|
111 | ## 发布管理
|
112 |
|
113 | g2-brush 基于 [semver] 语义化版本号进行发布。
|
114 |
|
115 | `master` 分支为当前稳定发布的版本。
|
116 |
|
117 | - 直接从 `master` 切出开发分支
|
118 | - 所有 API 的废弃都需要在当前的稳定版本上 `deprecate` 提示,并保证在当前的稳定版本上一直兼容到新版本的发布。
|
119 |
|
120 | ### 发布策略
|
121 |
|
122 | 每个大版本都有一个发布经理管理(PM),他/她要做的事情
|
123 |
|
124 | #### 准备工作:
|
125 |
|
126 | - 建立 milestone,确认需求关联 milestone,指派和更新 issues。
|
127 |
|
128 | #### 发布前:
|
129 |
|
130 | - 确认当前 Milestone 所有的 issue 都已关闭或可延期,完成性能测试。
|
131 | - 发起一个新的 [Release Proposal MR],按照 [node CHANGELOG] 进行 `History` 的编写,修正文档中与版本相关的内容,commits 可以自动生成。
|
132 | ```bash
|
133 | $ npm run commits
|
134 | ```
|
135 | - 指定下一个大版本的 PM。
|
136 |
|
137 | #### 发布时:
|
138 |
|
139 | - 将老的稳定版本(master)备份到以当前大版本为名字的分支上(例如 `1.x`),并设置 tag 为 {v}.x`( v 为当前版本,例如 `1.x`)。
|
140 | - 发布新的稳定版本到 [npm],并通知上层框架进行更新。
|
141 | - `npm publish` 之前,请先阅读[『我是如何发布一个 npm 包的』]。
|
142 |
|
143 |
|
144 | [semver]: http://semver.org/lang/zh-CN/
|
145 | [Release proposal MR]: https://github.com/nodejs/node/pull/4181
|
146 | [node CHANGELOG]: https://github.com/nodejs/node/blob/master/CHANGELOG.md
|
147 | [npm]: http://npmjs.com/
|
148 | [『我是如何发布一个 npm 包的』]: https://fengmk2.com/blog/2016/how-i-publish-a-npm-package
|