Skip to content

Commit e52bdd3

Browse files
committed
docs: updating CONTRIBUTING.md
Add codestyle guides about golangci-lint. Add git commit message guide and examples.
1 parent b537da3 commit e52bdd3

File tree

1 file changed

+37
-0
lines changed

1 file changed

+37
-0
lines changed

CONTRIBUTING.md

Lines changed: 37 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -20,6 +20,43 @@ We aim to reply to issues within 24 hours.
2020

2121
## Style Guides
2222

23+
### Linters
24+
25+
We use `golangci-lint` ([official website](https://golangci-lint.run/), [GitHub](https://github.com/golangci/golangci-lint)) for linting, which is a Go linters aggregator. It's also integrated with the GitHub Actions workflows.
26+
27+
- The list of linters enabled by default is documented [here](https://golangci-lint.run/usage/linters/).
28+
- It can be [integrated with IDE](https://golangci-lint.run/usage/integrations/)
29+
- You can [run it locally](https://golangci-lint.run/usage/quick-start/).
30+
31+
Besides, we also use the [Go Report Card](https://goreportcard.com/report/github.com/merico-dev/stream). There is a badge like [![Go Report Card](https://goreportcard.com/badge/github.com/merico-dev/stream)](https://goreportcard.com/report/github.com/merico-dev/stream) in the main README.md.
32+
2333
### Git Commit Message
2434

2535
We try our best to follow the [conventional commits](https://www.conventionalcommits.org/en/v1.0.0/#summary) guidelines.
36+
37+
TL;DR: The commit message should be structured as follows:
38+
39+
```
40+
<type>[optional scope]: <description>
41+
[optional body]
42+
[optional footer(s)]
43+
```
44+
45+
where "type" can be:
46+
- `feat`: implements a feature
47+
- `fix`: patches a bug
48+
- `BREAKING CHANGE`: a breaking change. Or append `!` at the end of "feat" or "fix", like `feat!` and `fix!`
49+
- other types are allowed, for example: `build`, `chore`, `ci`, `docs`, `style`, `refactor`, `perf`, `test`
50+
51+
Both "body" and "footer" are optional; BREAKING CHANGE can be addressed both in the title as well as in the footer. Some examples:
52+
53+
- `feat: send an email to the customer when a product is shipped`
54+
- `feat!: send an email to the customer when a product is shipped`
55+
- `feat(api): send an email to the customer when a product is shipped`
56+
- `feat(api)!: send an email to the customer when a product is shipped`
57+
- `BREAKING CHANGE: send an email to the customer when a product is shipped`
58+
- ```
59+
feat!: send an email to the customer when a product is shipped
60+
A detailed description in the body.
61+
BREAKING CHANGE: readdressing the breaking change in the footer.
62+
```

0 commit comments

Comments
 (0)