|
| 1 | +# Contributing guidelines |
| 2 | + |
| 3 | +tl;dr: Contributions to this repository follow the same general guidelines as the Angular organization. |
| 4 | + |
| 5 | +As a contributor, here are the guidelines we would like you to follow: |
| 6 | + |
| 7 | +* [Code of Conduct](#coc) |
| 8 | +* [Issues and Bugs](#issue) |
| 9 | +* [Feature Requests](#feature) |
| 10 | +* [Coding Rules](#rules) |
| 11 | +* [Git Workflow (AKA Branching/Merging Strategy)](#commit) |
| 12 | +* [Commit Message Guidelines](#commit) |
| 13 | +* [Signing the CLA](#cla) |
| 14 | + |
| 15 | +## <a name="coc"></a> Code of Conduct |
| 16 | + |
| 17 | +Please read and follow our [Code of Conduct][coc]. |
| 18 | + |
| 19 | +## <a name="issue"></a> Found a Bug? |
| 20 | + |
| 21 | +If you find a bug in the source code, you can help us by |
| 22 | +[submitting an issue](#submit-issue) to our [GitHub Repository][github]. Even better, you can |
| 23 | +[submit a Pull Request](#submit-pr) with a fix. |
| 24 | + |
| 25 | +## <a name="feature"></a> Missing a Feature? |
| 26 | + |
| 27 | +You can _request_ a new feature by [submitting an issue](#submit-issue) to our GitHub |
| 28 | +Repository. If you would like to _implement_ a new feature, please submit an issue with |
| 29 | +a proposal for your work first, to be sure that we can use it. |
| 30 | +Please consider what kind of change it is: |
| 31 | + |
| 32 | +* For a **Major Feature**, first open an issue and outline your proposal so that it can be |
| 33 | + discussed. This will also allow us to better coordinate our efforts, prevent duplication of work, |
| 34 | + and help you to craft the change so that it is successfully accepted into the project. |
| 35 | +* **Small Features** can be crafted and directly [submitted as a Pull Request](#submit-pr). |
| 36 | + |
| 37 | +## <a name="gitflow"></a> Git Workflow (AKA branching/merging strategy) |
| 38 | + |
| 39 | +To take full advantage of [semantic release](https://github.com/semantic-release/semantic-release), we use [Git Flow](http://nvie.com/posts/a-successful-git-branching-model/) as branching strategy. This means that PR must start from and be submitted to `develop` branch. |
| 40 | + |
| 41 | +We do `git rebase` (instead of `git merge`) as merging strategy. |
| 42 | + |
| 43 | + |
| 44 | +## <a name="commit"></a> Commit Message Guidelines |
| 45 | + |
| 46 | +We have very precise rules over how our git commit messages can be formatted. This leads to **more |
| 47 | +readable messages** that are easy to follow when looking through the **project history**. But also, |
| 48 | +we use the git commit messages to **generate the change log**. |
| 49 | + |
| 50 | +### Commit Message Format |
| 51 | + |
| 52 | +Each commit message consists of a **header**, a **body** and a **footer**. The header has a special |
| 53 | +format that includes a **type**, a **scope** and a **subject**: |
| 54 | + |
| 55 | +``` |
| 56 | +<type>(<scope>): <subject> |
| 57 | +<BLANK LINE> |
| 58 | +<body> |
| 59 | +<BLANK LINE> |
| 60 | +<footer> |
| 61 | +``` |
| 62 | + |
| 63 | +The **header** is mandatory and the **scope** of the header is optional. |
| 64 | + |
| 65 | +Any line of the commit message cannot be longer 100 characters! This allows the message to be easier |
| 66 | +to read on GitHub as well as in various git tools. |
| 67 | + |
| 68 | +The footer should contain a [closing reference to an issue](https://help.github.com/articles/closing-issues-via-commit-messages/) if any. |
| 69 | + |
| 70 | +Samples: (even more [samples](https://github.com/manekinekko/angular-search-experience/commits/master)) |
| 71 | + |
| 72 | +``` |
| 73 | +docs(changelog): update changelog to beta.5 |
| 74 | +``` |
| 75 | + |
| 76 | +``` |
| 77 | +fix(release): need to depend on latest rxjs and zone.js |
| 78 | +
|
| 79 | +The version in our package.json gets copied to the one we publish, and users need the latest of these. |
| 80 | +``` |
| 81 | + |
| 82 | +### Revert |
| 83 | + |
| 84 | +If the commit reverts a previous commit, it should begin with `revert:`, followed by the header of the reverted commit. In the body it should say: `This reverts commit <hash>.`, where the hash is the SHA of the commit being reverted. |
| 85 | + |
| 86 | +### Type |
| 87 | + |
| 88 | +Must be one of the following: |
| 89 | + |
| 90 | +* **build**: Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm) |
| 91 | +* **ci**: Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs) |
| 92 | +* **docs**: Documentation only changes |
| 93 | +* **feat**: A new feature |
| 94 | +* **fix**: A bug fix |
| 95 | +* **perf**: A code change that improves performance |
| 96 | +* **refactor**: A code change that neither fixes a bug nor adds a feature |
| 97 | +* **style**: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc) |
| 98 | +* **test**: Adding missing tests or correcting existing tests |
| 99 | + |
| 100 | +### Scope |
| 101 | + |
| 102 | +The scope should be the name of the npm package affected (as perceived by the person reading the changelog generated from commit messages. |
| 103 | + |
| 104 | +### Subject |
| 105 | + |
| 106 | +The subject contains a succinct description of the change: |
| 107 | + |
| 108 | +* use the imperative, present tense: "change" not "changed" nor "changes" |
| 109 | +* don't capitalize the first letter |
| 110 | +* no dot (.) at the end |
| 111 | + |
| 112 | +### Body |
| 113 | + |
| 114 | +Just as in the **subject**, use the imperative, present tense: "change" not "changed" nor "changes". |
| 115 | +The body should include the motivation for the change and contrast this with previous behavior. |
| 116 | + |
| 117 | +### Footer |
| 118 | + |
| 119 | +The footer should contain any information about **Breaking Changes** and is also the place to |
| 120 | +reference GitHub issues that this commit **Closes**. |
| 121 | + |
| 122 | +**Breaking Changes** should start with the word `BREAKING CHANGE:` with a space or two newlines. The rest of the commit message is then used for this. |
| 123 | + |
| 124 | +A detailed explanation can be found in this [document][commit-message-format]. |
| 125 | + |
| 126 | +[coc]: https://github.com/angular/code-of-conduct/blob/master/CODE_OF_CONDUCT.md |
| 127 | +[commit-message-format]: https://docs.google.com/document/d/1QrDFcIiPjSLDn3EL15IJygNPiHORgU1_OOAqWjiDU5Y/edit# |
0 commit comments