These guidelines are meant to be a simple, effective way to quickly discern the type of contribution in our projects, as well as an attempt to enforce limiting commits to a single topic and avoid unwieldy commits
It's based on Angular's contribution guidelines, and this document about commit messages in general. I suggest that you give them a read, too.
A commit message consists of, at the very least, the summary. It may also include a body, separated from the summary by a blank line.
Try to always hard wrap each line at 72 characters (i.e. with an actual line break). Very long, unbreakable lines such as URLs are obviously exempt from this.
Your commit summary should be prefixed with a specific string that depends on the topic of the commit. Something like this:
(feat) Add task to minify SVG files
or:
(fix) Make wiredep work on all html files
Remember to use the imperative tense (unless in special cases like posts): "rewrite" instead of "rewrites" or "rewrote".
Including this prefix, the summary should not exceed 72 characters.
Use this section to elaborate on the reasoning and/or details of a commit, if the summary is not enough. Additional considerations also go here, for example, if the commit involves having to install a new plugin with npm or something like that.
Like in the summary, use the imperative tense ("rewrite"). Also, just like the summary, each line should be 72 characters or less.
Feel free to use Markdown here, but be mindful of the 72 character limit.
Each project may have its own set of topic prefixes to use, but these are our suggestions.
This includes anything that is mostly HTML, CSS and JavaScript. Nowadays, this basically means whatever we've started with Yeoman and uses our standard grunt or gulp workflows.
- (feat) for new site-wide features (e.g. a scrolling sidebar)
- (comp) for new components (e.g. RSCSS- or BEM-style, Polymer stuff, Jade or SCSS mixin)
- (page) for new pages (e.g. home, user profile screen, etc.)
- (tmpl) for new templates (for e.g. Jade projects)
- (fix) for fixes to existing pages or functionality
- (tool) for build process changes (e.g. changes to the gulpfile)
- (style) for code style changes (e.g. formatting, alignment, etc.)