1 | # Contributing to Git Server
|
2 |
|
3 | This project is an Open Development/Inner Source project and welcomes contributions from everyone who finds it useful or lacking.
|
4 |
|
5 | ## Code Of Conduct
|
6 |
|
7 | This project adheres to the Adobe [code of conduct](CODE_OF_CONDUCT.md). By participating, you are expected to uphold this code. Please report unacceptable behavior to cstaub at adobe dot com.
|
8 |
|
9 | ## Contributor License Agreement
|
10 |
|
11 | All third-party contributions to this project must be accompanied by a signed contributor license. This gives Adobe permission to redistribute your contributions as part of the project. [Sign our CLA](http://opensource.adobe.com/cla.html)! You only need to submit an Adobe CLA one time, so if you have submitted one previously, you are good to go!
|
12 |
|
13 | ## Things to Keep in Mind
|
14 |
|
15 | This project uses a **commit then review** process, which means that for approved maintainers, changes can be merged immediately, but will be reviewed by others.
|
16 |
|
17 | For other contributors, a maintainer of the project has to approve the pull request.
|
18 |
|
19 | # Before You Contribute
|
20 |
|
21 | * Check that there is an existing issue in GitHub issues
|
22 | * Check if there are other pull requests that might overlap or conflict with your intended contribution
|
23 |
|
24 | # How to Contribute
|
25 |
|
26 | 1. Fork the repository
|
27 | 2. Make some changes on a branch on your fork
|
28 | 3. Create a pull request from your branch
|
29 |
|
30 | In your pull request, outline:
|
31 |
|
32 | * What the changes intend
|
33 | * How they change the existing code
|
34 | * If (and what) they breaks
|
35 | * Start the pull request with the GitHub issue ID, e.g. #123
|
36 |
|
37 | Lastly, please follow the [pull request template](PULL_REQUEST_TEMPLATE.md) when submitting a pull request!
|
38 |
|
39 | Each commit message that is not part of a pull request:
|
40 |
|
41 | * Should contain the issue ID like `#123`
|
42 | * Can contain the tag `[trivial]` for trivial changes that don't relate to an issue
|
43 |
|
44 |
|
45 |
|
46 | ## Coding Styleguides
|
47 |
|
48 | This project uses the [airbnb](https://www.npmjs.com/package/eslint-config-airbnb-base) eslint rules.
|
49 |
|
50 |
|
51 | ## Commit message format
|
52 |
|
53 | We use [semantic-release](https://github.com/semantic-release/semantic-release) for release management and require that all commits are properly formatted using the [Angular Commit Message Conventions](https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#-git-commit-guidelines)
|
54 |
|
55 | In order to help you craft a good commit message, we added [commitizen](https://www.npmjs.com/package/commitizen) as dev dependency, so you can just run
|
56 |
|
57 | ```
|
58 | $ npm run commit
|
59 | ```
|
60 |
|
61 |
|
62 | # How Contributions get Reviewed
|
63 |
|
64 | One of the maintainers will look at the pull request within one week.
|
65 | Feedback on the pull request will be given in writing, in GitHub.
|
66 |
|
67 | # Release Management
|
68 |
|
69 | Releasing is done using [semantic-release](https://github.com/semantic-release/semantic-release), and every (relevant) commit to the `master` branch gets released automatically. The release will update the version number and add the recent changes to the [CHANGELOG.md](./CHANGELOG.md). It will also create a [release](https://github.com/adobe/helix-cli/releases) in github and finally publish the package to the [Adobe organization on npmjs.org](https://www.npmjs.com/org/adobe).
|