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
@@ -15,35 +15,119 @@ Help us develop and maintain Styleguidist:
15
15
16
16
## Commit message conventions
17
17
18
-
We use [ESLint commit message conventions](https://github.com/conventional-changelog/conventional-changelog/tree/master/packages/conventional-changelog-eslint).
18
+
We use a simplified [Angular commit message conventions](https://github.com/angular/angular/blob/master/CONTRIBUTING.md#commit). This makes automated releases with [semantic-release](https://github.com/semantic-release/semantic-release) possible.
19
19
20
-
Each commit looks like this:
20
+
\*\*The main differences with the Angular convention is that all messages are capitalized. Commit messages are written for humans to read, so we should use text convention for humans, not for machines.
21
+
22
+
Hovewer, we commit messages should follow a ceratain structure, so they semantic-release could generate nice human-readalbe changelogs.
23
+
24
+
**The commit message** consists of a `header`, a `body`, and a `footer`:
21
25
22
26
```
23
-
Tag: Short description (fixes #1234)
27
+
<header>
28
+
<BLANK LINE>
29
+
<body>
30
+
<BLANK LINE>
31
+
<footer>
32
+
```
33
+
34
+
The `header` is mandatory and must conform to the commit message header format described below.
24
35
25
-
Longer description here if necessary
36
+
The `body` optional but higly recommended for most commits, except very simple ones.
37
+
38
+
The `footer` is optional.
39
+
40
+
**The commit message header** looks like this:
41
+
42
+
```
43
+
<type>: <Short summary>
44
+
│ │
45
+
│ └─⫸ Summary in present tense. Capitalized. No period at the end.
The `<type>` and `<Short summary>` fields are mandatory.
51
+
52
+
### Type
53
+
54
+
Must be one of the following:
55
+
56
+
-`chore` — configuration change, dependencies upgrade, and so on.
57
+
-`docs` — changes to documentation only.
58
+
-`feat` — a new feature.
59
+
-`fix` — a bug fix.
60
+
-`refactor` — a code change that neither fixes a bug nor adds a feature.
61
+
-`test` — adding missing tests or correcting existing tests.
62
+
63
+
### Short summary
64
+
65
+
Use the summary field to provide a short description of the change.
66
+
67
+
- use the imperative, present tense: “change” not “changed” nor “changes”;
68
+
- always capitalize the first letter;
69
+
- no dot (.) at the end.
70
+
71
+
### Commit message body
72
+
73
+
As in the summary, use the imperative, present tense: “fix” not “fixed” nor “fixes”, but put a dot (.) at the end of each sentence.
29
74
30
-
-`Fix` — for a bug fix.
31
-
-`Update` — for a backwards-compatible enhancement.
32
-
-`New` — implemented a new feature.
33
-
-`Breaking` — for a backwards—incompatible enhancement or feature.
34
-
-`Docs` — changes to documentation only.
35
-
-`Build` — changes to build process only.
36
-
-`Upgrade` — for a dependency upgrade.
37
-
-`Chore` — for refactoring, adding tests and so on (anything that isn’t user-facing).
75
+
Explain the motivation for the change: why you are making it. You could include a comparison of the previous behavior with the new behavior to illustrate the impact of the change.
38
76
39
-
If the commit doesn’t completely fix the issue, then use (`refs #1234`) instead of (`fixes #1234`).
77
+
### Commit message footer
40
78
41
-
Here are some good commit message summary examples:
79
+
The footer could contain information about breaking changes, and is also the place to reference GitHub issues, and other pull requests that this commit closes or is related to.
42
80
43
81
```
44
-
Build: Update Travis to only test Node 0.10 (refs #734)
45
-
Fix: Semi rule incorrectly flagging extra semicolon (fixes #840)
46
-
Upgrade: Esprima to 1.2, switch to using comment attachment (fixes #730)
Breaking change section should start with the phrase `BREAKING CHANGE:` (with a `:` and a space at the end, you must use ALL CAPS — _sorry but life is full of pain_) followed by a summary of the breaking change, a blank line, and a detailed description of the breaking change that also includes migration instructions.
91
+
92
+
If the commit doesn’t completely fix the issue, then use (`Refs #1234`) instead of (`Fixes #1234`).
93
+
94
+
### Commit messsage example
95
+
96
+
````
97
+
Fix: Fix missing FlowType enum values in prop description
98
+
99
+
In ef4c109b, the file `PropsRenderer.js` (located at
100
+
`src/client/rsg-components/Props/PropsRenderer.js`) was removed. In
101
+
`PropsRenderer.js`, the `renderExtra` method checked whether `getType`
102
+
for the argument to `renderExtra` was present:
103
+
104
+
```es6
105
+
function renderExtra(prop) {
106
+
const type = getType(prop);
107
+
if (!type) {
108
+
return null;
109
+
}
110
+
...
111
+
}
112
+
```
113
+
114
+
However, in ef4c109b, this method was replaced with `renderExtra.tsx`
115
+
and the condition was changed to:
116
+
117
+
```typescript
118
+
export default function renderExtra(prop: PropDescriptorWithFlow): React.ReactNode {
119
+
const type = getType(prop);
120
+
if (!prop.type || !type) {
121
+
return null;
122
+
}
123
+
````
124
+
125
+
Unfortunately, this extra condition has resulted in this method always returning `null` for a Flow typed prop as `prop.type` is always `null` as `prop.type` is never set.
126
+
127
+
This commit reverts the condition to what it was before the migration to TypeScript.
128
+
129
+
Fixes #1234
130
+
47
131
```
48
132
49
133
## Pull requests
@@ -58,17 +142,17 @@ We’re doing automated releases with semantic-release. We’re using [milestone
58
142
59
143
### Patch releases
60
144
61
-
Any commit of a `Fix` or `Update` types merged into the master branch, is published as a _patch_ release as soon as CI passes.
145
+
Any commit of a `fix` type merged into the master branch, is published as a _patch_ release as soon as CI passes.
0 commit comments