|  | 
|  | 1 | +# Contributing to dTree | 
|  | 2 | + | 
|  | 3 | +## Commiting | 
|  | 4 | +Please follow these guidelines. | 
|  | 5 | + | 
|  | 6 | +### Versioning | 
|  | 7 | +dTree uses SemVer 2.0.0. That is the versioning is <MAJOR>.<MINOR>.<PATCH>. | 
|  | 8 | + | 
|  | 9 | +### Commit Message Format | 
|  | 10 | +Each commit message consists of a **header**, a **body** and a **footer**.  The header has a special | 
|  | 11 | +format that includes a **type**, a **scope** and a **subject**: | 
|  | 12 | + | 
|  | 13 | +``` | 
|  | 14 | +<type>(<scope>): <subject> | 
|  | 15 | +<BLANK LINE> | 
|  | 16 | +<body> | 
|  | 17 | +<BLANK LINE> | 
|  | 18 | +<footer> | 
|  | 19 | +``` | 
|  | 20 | + | 
|  | 21 | +The **header** is mandatory and the **scope** of the header is optional. | 
|  | 22 | + | 
|  | 23 | +Any line of the commit message cannot be longer 100 characters! This allows the message to be easier | 
|  | 24 | +to read on GitHub as well as in various git tools. | 
|  | 25 | + | 
|  | 26 | +### Revert | 
|  | 27 | +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. | 
|  | 28 | + | 
|  | 29 | +### Type | 
|  | 30 | +Must be one of the following: | 
|  | 31 | + | 
|  | 32 | +* **feat**: A new feature | 
|  | 33 | +* **fix**: A bug fix | 
|  | 34 | +* **docs**: Documentation only changes | 
|  | 35 | +* **style**: Changes that do not affect the meaning of the code (white-space, formatting, missing | 
|  | 36 | +  semi-colons, etc) | 
|  | 37 | +* **refactor**: A code change that neither fixes a bug nor adds a feature | 
|  | 38 | +* **perf**: A code change that improves performance | 
|  | 39 | +* **test**: Adding missing tests | 
|  | 40 | +* **chore**: Changes to the build process or auxiliary tools and libraries such as documentation | 
|  | 41 | +  generation | 
|  | 42 | + | 
|  | 43 | +### Scope | 
|  | 44 | +The scope could be anything specifying place of the commit change. For example `$location`, | 
|  | 45 | +`$browser`, `$compile`, `$rootScope`, `ngHref`, `ngClick`, `ngView`, etc... | 
|  | 46 | + | 
|  | 47 | +### Subject | 
|  | 48 | +The subject contains succinct description of the change: | 
|  | 49 | + | 
|  | 50 | +* use the imperative, present tense: "change" not "changed" nor "changes" | 
|  | 51 | +* don't capitalize first letter | 
|  | 52 | +* no dot (.) at the end | 
|  | 53 | + | 
|  | 54 | +### Body | 
|  | 55 | +Just as in the **subject**, use the imperative, present tense: "change" not "changed" nor "changes". | 
|  | 56 | +The body should include the motivation for the change and contrast this with previous behavior. | 
|  | 57 | + | 
|  | 58 | +### Footer | 
|  | 59 | +The footer should contain any information about **Breaking Changes** and is also the place to | 
|  | 60 | +reference GitHub issues that this commit **Closes**. | 
|  | 61 | + | 
|  | 62 | +**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. | 
|  | 63 | + | 
|  | 64 | +## Recognitions | 
|  | 65 | +These guidelines are forked from Angular. | 
0 commit comments