| 1 | # Contribution guide
|
| 2 |
|
| 3 | ## Developing commitizen
|
| 4 |
|
| 5 | You consider contributing changes to commitizen – thank you!
|
| 6 | Please consider these guidelines when filing a pull request:
|
| 7 |
|
| 8 | * Commits follow the [Angular commit convention](https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#-git-commit-guidelines)
|
| 9 | * JavaScript is written using ES2015 features
|
| 10 | * 2 spaces indentation
|
| 11 | * Features and bug fixes should be covered by test cases
|
| 12 |
|
| 13 | ## Creating releases
|
| 14 |
|
| 15 | commitizen uses [semantic-release](https://github.com/semantic-release/semantic-release)
|
| 16 | to release new versions automatically.
|
| 17 |
|
| 18 | * Commits of type `fix` will trigger bugfix releases, think `0.0.1`
|
| 19 | * Commits of type `feat` will trigger feature releases, think `0.1.0`
|
| 20 | * Commits with `BREAKING CHANGE` in body or footer will trigger breaking releases, think `1.0.0`
|
| 21 |
|
| 22 | All other commit types will trigger no new release.
|
| 23 |
|
| 24 | ## Gotchas
|
| 25 |
|
| 26 | ### Atom removes lines with just spaces, breaking tests
|
| 27 |
|
| 28 | When using Atom, if you edit some of our tests, atom will remove the whitespace on some lines. Unfortunately we wanted this whitespace to
|
| 29 | able to test multiline commits and their difference across operating
|
| 30 | systems. Atom has decided to keep the stripping of whitespace as a
|
| 31 | default. Although we understand this decision, it has the unfortunate
|
| 32 | side effect of editing parts of the file that you might not have
|
| 33 | intended. We think this should be left up to more configurable tools
|
| 34 | like eslint.
|
| 35 |
|
| 36 | For now, in order to work around this, you can take the steps outlined
|
| 37 | [here](https://github.com/atom/whitespace/issues/10#issuecomment-85183781) to temporarily disable automatic whitespace removal in Atom.
|