UNPKG

generator-ngfs

Version:

Yeoman generator for creating MEAN stack applications, using MongoDB, Express, AngularJS, and Node

github.com/csharon/generator-ngfs

csharon/generator-ngfs

66 lines (48 loc) • 2.6 kB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
# Contributing See the [contributing docs](https://github.com/yeoman/yeoman/blob/master/contributing.md) Additionally for this generator: * When submitting an issue, please follow the [guidelines](https://github.com/yeoman/yeoman/blob/master/contributing.md#issue-submission). Especially important is to make sure Yeoman is up-to-date, and providing the command or commands that cause the issue. * When submitting a PR, make sure that the commit messages match the [AngularJS conventions][commit-message-format] (see below). * When submitting a bugfix, write a test that exposes the bug and fails before applying your fix. Submit the test alongside the fix. * When submitting a new feature, add tests that cover the feature. ## Git Commit Guidelines These rules are adopted from the AngularJS project. ### Commit Message Format Each commit message consists of a **header**, a **body** and a **footer**. The header has a special format that includes a **type**, a **scope** and a **subject**: ``` <type>(<scope>): <subject> <BLANK LINE> <body> <BLANK LINE> <footer> ``` Any line of the commit message cannot be longer 100 characters! This allows the message to be easier to read on github as well as in various git tools. ### Type Must be one of the following: * **feat**: A new feature * **fix**: A bug fix * **docs**: Documentation only changes * **style**: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc) * **refactor**: A code change that neither fixes a bug or adds a feature * **test**: Adding missing tests * **chore**: Changes to the build process or auxiliary tools and libraries such as documentation generation ### Scope The scope could be anything specifying place of the commit change. For example `app`, `gen`, `docs`, `gen:view`, `gen:route`, `gen:service`, etc... ### Subject The subject contains succinct description of the change: * use the imperative, present tense: "change" not "changed" nor "changes" * don't capitalize first letter * no dot (.) at the end ###Body Just as in the **subject**, use the imperative, present tense: "change" not "changed" nor "changes" The body should include the motivation for the change and contrast this with previous behavior. ###Footer The footer should contain any information about **Breaking Changes** and is also the place to reference GitHub issues that this commit **Closes**. A detailed explanation can be found in this [document][commit-message-format]. [commit-message-format]: https://docs.google.com/document/d/1QrDFcIiPjSLDn3EL15IJygNPiHORgU1_OOAqWjiDU5Y