You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: CONTRIBUTING.md
+91-78Lines changed: 91 additions & 78 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -3,15 +3,16 @@
3
3
We would love for you to contribute to NG-ZORRO and help make it even better than it is
4
4
today! As a contributor, here are the guidelines we would like you to follow:
5
5
6
-
-[Code of Conduct](#coc)
7
-
-[Question or Problem?](#question)
8
-
-[Issues and Bugs](#issue)
9
-
-[Feature Requests](#feature)
10
-
-[Submission Guidelines](#submit)
11
-
-[Coding Rules](#rules)
12
-
-[Commit Message Guidelines](#commit)
6
+
-[Code of Conduct](#coc)
7
+
-[Question or Problem?](#question)
8
+
-[Issues and Bugs](#issue)
9
+
-[Feature Requests](#feature)
10
+
-[Submission Guidelines](#submit)
11
+
-[Coding Rules](#rules)
12
+
-[Commit Message Guidelines](#commit)
13
13
14
14
## <aname="coc"></a> Code of Conduct
15
+
15
16
Help us keep NG-ZORRO open and inclusive. Please read and follow our [Code of Conduct](https://github.com/NG-ZORRO/ng-zorro-antd/blob/master/CODE_OF_CONDUCT.md).
16
17
17
18
## <aname="question"></a> Got a Question or Problem?
@@ -29,20 +30,22 @@ To save your and our time, we will systematically close all issues that are requ
29
30
If you would like to chat about the question in real-time, you can reach out via [](https://discord.com/channels/748677963142135818/764322550712893451).
30
31
31
32
## <aname="issue"></a> Found a Bug?
33
+
32
34
If you find a bug in the source code, you can help us by
33
35
[submitting an issue](#submit-issue) to our [GitHub Repository](https://github.com/NG-ZORRO/ng-zorro-antd). Even better, you can
34
36
[submit a Pull Request](#submit-pr) with a fix.
35
37
36
38
## <aname="feature"></a> Missing a Feature?
37
-
You can *request* a new feature by [submitting an issue](#submit-issue) to our GitHub
38
-
Repository. If you would like to *implement* a new feature, please submit an issue with
39
-
a for your work first, to be sure that we can use it.
39
+
40
+
You can _request_ a new feature by [submitting an issue](#submit-issue) to our GitHub
41
+
Repository. If you would like to _implement_ a new feature, please submit an issue with
42
+
a for your work first, to be sure that we can use it.
40
43
Please consider what kind of change it is:
41
44
42
-
* For a **Major Feature**, first open an issue and outline your proposal so that it can be
43
-
discussed. This will also allow us to better coordinate our efforts, prevent duplication of work,
44
-
and help you to craft the change so that it is successfully accepted into the project.
45
-
***Small Features** can be crafted and directly [submitted as a Pull Request](#submit-pr).
45
+
- For a **Major Feature**, first open an issue and outline your proposal so that it can be
46
+
discussed. This will also allow us to better coordinate our efforts, prevent duplication of work,
47
+
and help you to craft the change so that it is successfully accepted into the project.
48
+
-**Small Features** can be crafted and directly [submitted as a Pull Request](#submit-pr).
46
49
47
50
## <aname="submit"></a> Submission Guidelines
48
51
@@ -64,41 +67,42 @@ Unfortunately we are not able to investigate / fix bugs without a minimal reprod
64
67
65
68
You can file new issues by filling out our [new issue form](https://github.com/NG-ZORRO/ng-zorro-antd/issues/new).
66
69
67
-
68
70
### <aname="submit-pr"></a> Submitting a Pull Request (PR)
71
+
69
72
Before you submit your Pull Request (PR) consider the following guidelines:
70
73
71
-
* Search [GitHub](https://github.com/NG-ZORRO/ng-zorro-antd/pulls) for an open or closed PR
74
+
- Search [GitHub](https://github.com/NG-ZORRO/ng-zorro-antd/pulls) for an open or closed PR
72
75
that relates to your submission. You don't want to duplicate effort.
73
-
* Make your changes in a new git branch:
76
+
- Make your changes in a new git branch:
74
77
75
-
```shell
76
-
git checkout -b my-fix-branch master
77
-
```
78
+
```shell
79
+
git checkout -b my-fix-branch master
80
+
```
78
81
79
-
* Create your patch, **including appropriate test cases**.
80
-
* Follow our [Coding Rules](#rules).
81
-
* Run the full test suite, and ensure that all tests pass.
82
-
* Commit your changes using a descriptive commit message that follows our
82
+
- Create your patch, **including appropriate test cases**.
83
+
- Follow our [Coding Rules](#rules).
84
+
- Run the full test suite, and ensure that all tests pass.
85
+
- Commit your changes using a descriptive commit message that follows our
83
86
[commit message conventions](#commit). Adherence to these conventions
84
87
is necessary because release notes are automatically generated from these messages.
85
88
86
-
```shell
87
-
git commit -a
88
-
```
89
+
```shell
90
+
git commit -a
91
+
```
92
+
89
93
Note: the optional commit `-a` command line option will automatically "add" and "rm" edited files.
90
94
91
-
* Push your branch to GitHub:
95
+
- Push your branch to GitHub:
92
96
93
-
```shell
94
-
git push origin my-fix-branch
95
-
```
97
+
```shell
98
+
git push origin my-fix-branch
99
+
```
96
100
97
-
* In GitHub, send a pull request to `ng-zorro-antd:master`.
98
-
* If we suggest changes then:
99
-
* Make the required updates.
100
-
* Re-run the NG-ZORRO test suites to ensure tests are still passing.
101
-
* Rebase your branch and force push to your GitHub repository (this will update your Pull Request):
101
+
- In GitHub, send a pull request to `ng-zorro-antd:master`.
102
+
- If we suggest changes then:
103
+
- Make the required updates.
104
+
- Re-run the NG-ZORRO test suites to ensure tests are still passing.
105
+
- Rebase your branch and force push to your GitHub repository (this will update your Pull Request):
102
106
103
107
```shell
104
108
git rebase master -i
@@ -112,44 +116,46 @@ That's it! Thank you for your contribution!
112
116
After your pull request is merged, you can safely delete your branch and pull the changes
113
117
from the main (upstream) repository:
114
118
115
-
* Delete the remote branch on GitHub either through the GitHub web UI or your local shell as follows:
119
+
- Delete the remote branch on GitHub either through the GitHub web UI or your local shell as follows:
116
120
117
-
```shell
118
-
git push origin --delete my-fix-branch
119
-
```
121
+
```shell
122
+
git push origin --delete my-fix-branch
123
+
```
120
124
121
-
* Check out the master branch:
125
+
- Check out the master branch:
122
126
123
-
```shell
124
-
git checkout master -f
125
-
```
127
+
```shell
128
+
git checkout master -f
129
+
```
126
130
127
-
* Delete the local branch:
131
+
- Delete the local branch:
128
132
129
-
```shell
130
-
git branch -D my-fix-branch
131
-
```
133
+
```shell
134
+
git branch -D my-fix-branch
135
+
```
132
136
133
-
* Update your master with the latest upstream version:
137
+
- Update your master with the latest upstream version:
134
138
135
-
```shell
136
-
git pull --ff upstream master
137
-
```
139
+
```shell
140
+
git pull --ff upstream master
141
+
```
138
142
139
143
## <a name="rules"></a> Coding Rules
144
+
140
145
To ensure consistency throughout the source code, keep these rules in mind as you are working:
141
146
142
-
* All features or bug fixes **must be tested** by one or more specs (unit-tests).
143
-
* All public API methods **must be documented**.
147
+
- All features or bug fixes **must be tested** by one or more specs (unit-tests).
We have very precise rules over how our git commit messages can be formatted. This leads to **more
148
-
readable messages** that are easy to follow when looking through the **project history**. But also,
152
+
We have very precise rules over how our git commit messages can be formatted. This leads to **more
153
+
readable messages** that are easy to follow when looking through the **project history**. But also,
149
154
we use the git commit messages to **generate the NG-ZORRO change log**.
150
155
151
156
### Commit Message Format
152
-
Each commit message consists of a **header**, a **body** and a **footer**. The header has a special
157
+
158
+
Each commit message consists of a **header**, a **body** and a **footer**. The header has a special
153
159
format that includes a **type**, a **scope** and a **subject**:
154
160
155
161
```txt
@@ -172,57 +178,64 @@ Samples: (even more [samples](https://github.com/NG-ZORRO/ng-zorro-antd/commits/
172
178
```txt
173
179
docs(changelog): update change log to beta.5
174
180
```
181
+
175
182
```txt
176
183
fix(release): need to depend on latest rxjs and zone.js
177
184
178
185
The version in our package.json gets copied to the one we publish, and users need the latest of these.
179
186
```
180
187
181
188
### Revert
189
+
182
190
If the commit reverts a previous commit, it should begin with `revert: `, followed by the header of the reverted commit. In the body it should say: `This reverts commit <hash>.`, where the hash is the SHA of the commit being reverted.
183
191
184
192
### Type
193
+
185
194
Must be one of the following:
186
195
187
-
* **build**: Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)
188
-
* **ci**: Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs)
189
-
* **docs**: Documentation only changes
190
-
* **feat**: A new feature
191
-
* **fix**: A bug fix
192
-
* **perf**: A code change that improves performance
193
-
* **refactor**: A code change that neither fixes a bug nor adds a feature
194
-
* **style**: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
195
-
* **test**: Adding missing tests or correcting existing tests
196
+
- **build**: Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)
197
+
- **ci**: Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs)
198
+
- **docs**: Documentation only changes
199
+
- **feat**: A new feature
200
+
- **fix**: A bug fix
201
+
- **perf**: A code change that improves performance
202
+
- **refactor**: A code change that neither fixes a bug nor adds a feature
203
+
- **style**: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
204
+
- **test**: Adding missing tests or correcting existing tests
196
205
197
206
### Scope
198
-
The scope should be the name of the module affected (folder name or other meaningful words), and should prefix with *module:* (as perceived by person reading changelog generated from commit messages.
207
+
208
+
The scope should be the name of the module affected (folder name or other meaningful words), and should prefix with _module:_ (as perceived by person reading changelog generated from commit messages.
199
209
200
210
The following are some examples:
201
211
202
-
* **module:alert**
203
-
* **module:badge**
204
-
* **module:breadcrumb**
205
-
* **module:OTHER_COMPONENT_NAME**
212
+
- **module:alert**
213
+
- **module:badge**
214
+
- **module:breadcrumb**
215
+
- **module:OTHER_COMPONENT_NAME**
206
216
207
217
There are currently a few exceptions to the "use module name" rule:
208
218
209
-
* **packaging**: used for changes that change the npm package layout, e.g. public path changes, package.json changes, d.ts file/format changes, changes to bundles, etc.
210
-
* **changelog**: used for updating the release notes in CHANGELOG.md
211
-
* **showcase**: used for docs-app (ng.ant.design) related changes within the /showcase directory of the repo
212
-
* none/empty string: useful for `style`, `test` and `refactor` changes that are done across all packages (e.g. `style: add missing semicolons`)
219
+
- **packaging**: used for changes that change the npm package layout, e.g. public path changes, package.json changes, d.ts file/format changes, changes to bundles, etc.
220
+
- **changelog**: used for updating the release notes in CHANGELOG.md
221
+
- **showcase**: used for docs-app (ng.ant.design) related changes within the /showcase directory of the repo
222
+
- none/empty string: useful for `style`, `test` and `refactor` changes that are done across all packages (e.g. `style: add missing semicolons`)
213
223
214
224
### Subject
225
+
215
226
The subject contains succinct description of the change:
216
227
217
-
* use the imperative, present tense: "change" not "changed" nor "changes"
218
-
* don't capitalize first letter
219
-
* no dot (.) at the end
228
+
- use the imperative, present tense: "change" not "changed" nor "changes"
229
+
- don't capitalize first letter
230
+
- no dot (.) at the end
220
231
221
232
### Body
233
+
222
234
Just as in the **subject**, use the imperative, present tense: "change" not "changed" nor "changes".
223
235
The body should include the motivation for the change and contrast this with previous behavior.
224
236
225
237
### Footer
238
+
226
239
The footer should contain any information about **Breaking Changes** and is also the place to
227
240
reference GitHub issues that this commit **Closes**.
0 commit comments