b6a95a8cb3
* Dropped unused codekit config * Integrated dynamic and static bindata for public * Ignore public bindata * Add a general generate make task * Integrated flexible public assets into web command * Updated vendoring, added all missiong govendor deps * Made the linter happy with the bindata and dynamic code * Moved public bindata definition to modules directory * Ignoring the new bindata path now * Updated to the new public modules import path * Updated public bindata command and drop the new prefix
65 lines
2.3 KiB
Markdown
65 lines
2.3 KiB
Markdown
# How to contribute
|
|
|
|
This document outlines some of the conventions on development workflow, commit message formatting, contact points and other
|
|
resources to make it easier to get your contribution accepted.
|
|
|
|
## Getting started
|
|
|
|
- Fork the repository on GitHub.
|
|
- Read the README.md for build instructions.
|
|
- Play with the project, submit bugs, submit patches!
|
|
|
|
## Contribution flow
|
|
|
|
This is a rough outline of what a contributor's workflow looks like:
|
|
|
|
- Create a topic branch from where you want to base your work. This is usually master.
|
|
- Make commits of logical units and add test case if the change fixes a bug or adds new functionality.
|
|
- Run tests and make sure all the tests are passed.
|
|
- Make sure your commit messages are in the proper format (see below).
|
|
- Push your changes to a topic branch in your fork of the repository.
|
|
- Submit a pull request to pingcap/tidb.
|
|
- Your PR must receive LGTMs from two maintainers found in the [MAINTAINERS](./docs/MAINTAINERS.md) file.
|
|
|
|
Thanks for your contributions!
|
|
|
|
### Code style
|
|
|
|
The coding style suggested by the Golang community is used in TiDB. See the [style doc](https://github.com/golang/go/wiki/CodeReviewComments) for details.
|
|
|
|
Please follow this style to make TiDB easy to review, maintain and develop.
|
|
|
|
### Format of the Commit Message
|
|
|
|
We follow a rough convention for commit messages that is designed to answer two
|
|
questions: what changed and why. The subject line should feature the what and
|
|
the body of the commit should describe the why.
|
|
|
|
```
|
|
store/localstore: add comment for variable declaration.
|
|
|
|
Improve documentation.
|
|
```
|
|
|
|
The format can be described more formally as follows:
|
|
|
|
```
|
|
<subsystem>: <what changed>
|
|
<BLANK LINE>
|
|
<why this change was made>
|
|
<BLANK LINE>
|
|
<footer>(optional)
|
|
```
|
|
|
|
The first line is the subject and should be no longer than 70 characters, the
|
|
second line is always blank, and other lines should be wrapped at 80 characters.
|
|
This allows the message to be easier to read on GitHub as well as in various
|
|
git tools.
|
|
|
|
If the change affects more than one subsystem, you can use comma to separate them like `util/codec,util/types:`.
|
|
|
|
If the change affects many subsystems, you can use ```*``` instead, like ```*:```.
|
|
|
|
For the why part, if no specific reason for the change,
|
|
you can use one of some generic reasons like "Improve documentation.",
|
|
"Improve performance.", "Improve robustness.", "Improve test coverage."
|