| 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).
|