-
Notifications
You must be signed in to change notification settings - Fork 0
Contribution Guidelines
Instead of starting completely from scratch here the guidelines set out by the AngularJS team will be used as a base and modified to fit our needs.
#Git Commits We have very precise rules over how our git commit messages can be formatted. This leads to more readable messages that are easy to follow when looking through the project history. One bennifit of such precise rules is that the git commit messages can be used directly to generate the project change log.
##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.
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
- perf: A code change that improves performance
- test: Adding missing tests
- chore: Changes to the build process or auxiliary tools and libraries such as documentation generation
The scope could be anything specifying place of the commit change, the name of the angular module that is added/modified will usually be the best choice here.
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 referenced Pivotal Tracker issues that this commit pertains to.
##Pivotal Tracker Integration A post receive hook has been setup for this repository and will automatically alert Pivotal Tracker to new commits. The commit message will be parsed and any issues containing a reference to an issue ID will automatically be linked and optionally finished or delivered.
The format is as follows:
[(Finishes|Fixes|Delivers) #TRACKER_STORY_ID]
Excerpt from the PivotalTracker Docs
To associate an SCM commit with a specific Tracker story, you must include a special syntax in the commit message to indicate one or more story IDs and (optionally) a state change for the story. Your commit message should have square brackets containing a hash mark followed by the story ID. If a story was not already started (it was in the "not started" state), a commit message will automatically start it. For example, if Scotty uses the following message when committing SCM revision 54321:
[#12345677 #12345678] Diverting power from warp drive to torpedoes.
>...it will result in the following comment being added to Tracker stories 12345677 and 12345678, and the stories will be started if they were not yet started:
>````
[#12345677 #12345678] Diverting power from warp drive to torpedoes.
To automatically finish a story by using a commit message, include "fixed", "completed" or "finished" in the square brackets in addition to the story ID. You may also use different cases or forms of these verbs, such as "Fix" or "FIXES", and they may appear before or after the story ID. Note: For features, this will put the story in the 'finished' state. For chores, it will put the story in the 'accepted' state. For example:
[Fixes #12345678] Torpedoes now sufficiently powered.
>In some environments, code that is committed is automatically deployed. For this situation, include "delivers" and the story will be put in the 'delivered' state:
>````
[Delivers #12345679] Scotty can beam up Captain Kirk.
#IDE Configuration
##Git & Github
Useful Links