|
| 1 | +# Contributing |
1 | 2 |
|
2 | | -## Contributing |
| 3 | +This repository accepts contributions through pull requests to `master`. |
| 4 | +`dev` can be used as a temporary integration branch, but changes should be merged in small, reviewable batches. |
3 | 5 |
|
4 | | -If you want to contribute to a project and make it better, your help is very welcome. Contributing is also a great way to learn more about social coding on Github, new technologies and and their ecosystems and how to make constructive, helpful bug reports, feature requests and the noblest of all contributions: a good, clean pull request. |
| 6 | +## Prerequisites |
5 | 7 |
|
6 | | -### How to make a clean pull request |
| 8 | +- JDK 8+ |
| 9 | +- Maven 3.6+ |
| 10 | +- MySQL/PostgreSQL only when running database integration tests |
7 | 11 |
|
8 | | -Look for a project's contribution instructions. If there are any, follow them. |
| 12 | +## Build and Test |
9 | 13 |
|
10 | | -- Create a personal fork of the project on Github. |
11 | | -- Clone the fork on your local machine. Your remote repo on Github is called `origin`. |
12 | | -- Add the original repository as a remote called `upstream`. |
13 | | -- If you created your fork a while ago be sure to pull upstream changes into your local repository. |
14 | | -- Create a new branch to work on! Branch from `develop` if it exists, else from `master`. |
15 | | -- Implement/fix your feature, comment your code, . |
16 | | -- Follow the code style of the project, including indentation. |
17 | | -- Write or adapt tests as needed. |
18 | | -- Add or change the documentation as needed. |
19 | | -- Create a new branch if necessary. |
20 | | -- Push your branch to your fork on Github, the remote `origin`. |
21 | | -- From your fork open a pull request in the correct branch. Target the project's `develop` branch if there is one, else go for `master`! |
22 | | -- Wait for approval. |
23 | | -- Once the pull request is approved and merged you can pull the changes from `upstream` to your local repo and delete |
24 | | -your extra branch(es). |
| 14 | +Run at repository root: |
25 | 15 |
|
26 | | -And last but not least: Always write your commit messages in the present tense. Your commit message should describe what the commit, when applied, does to the code – not what you did to the code. |
| 16 | +```bash |
| 17 | +mvn -q -DskipTests=false test |
| 18 | +``` |
| 19 | + |
| 20 | +Module-level examples: |
| 21 | + |
| 22 | +```bash |
| 23 | +mvn -pl core -am test |
| 24 | +mvn -pl extension/storage/storage-custom -am test |
| 25 | +mvn -pl extension/storage/storage-mysql -am test |
| 26 | +``` |
| 27 | + |
| 28 | +Reference: `docs/07-dev/build-and-test.md` |
| 29 | + |
| 30 | +## Pull Request Requirements |
| 31 | + |
| 32 | +- Keep each PR focused on one theme. |
| 33 | +- Use the PR template completely, including risk and rollback notes. |
| 34 | +- Add or update tests for behavior changes. |
| 35 | +- Update docs for user-visible changes. |
| 36 | +- Update `CHANGELOG.md` and `CHANGELOG-zh.md` for release-relevant changes. |
| 37 | + |
| 38 | +For database-related changes: |
| 39 | + |
| 40 | +- Update both MySQL and PostgreSQL DDL. |
| 41 | +- Update MyBatis SQL maps. |
| 42 | +- Provide migration notes. |
| 43 | + |
| 44 | +## Recommended Merge Strategy for Large Branches |
| 45 | + |
| 46 | +If a branch is too large to review in one PR, split into these categories: |
| 47 | + |
| 48 | +1. Mechanical changes (format/move/rename). |
| 49 | +2. Build/dependency changes. |
| 50 | +3. Feature additions. |
| 51 | +4. Compatibility or semantic behavior changes. |
| 52 | + |
| 53 | +Each category should be merged only after CI passes. |
| 54 | + |
| 55 | +## Commit Message |
| 56 | + |
| 57 | +Use present tense and clearly describe the behavior change, not just the action taken. |
0 commit comments