Skip to content

Latest commit

 

History

History
97 lines (64 loc) · 4.26 KB

CONTRIBUTING.adoc

File metadata and controls

97 lines (64 loc) · 4.26 KB

Commit Message Guidelines

We borrow from the Angular project’s guidelines here. Our commit guidelines are pedantic so that we can use the git log to generate the change log.

Most of the following is copied from the above Angular project link.

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>

The header is mandatory and the scope of the header is optional.

No line of the commit message may be longer 100 characters. This allows the message to be easier to read on GitHub as well as in various git tools.

The footer should contain a closing reference to an issue if any.

Samples: (even more samples)

docs(changelog): update change log to beta.5
fix(release): need to depend on latest rxjs and zone.js

The version in our package.json gets copied to the one we publish, and users need the latest of these.

Revert

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.

Type

Must be one of the following:

  1. build: Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)

  2. ci: Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs)

  3. docs: Documentation only changes

  4. feat: A new feature, or improvements to an existing one.

  5. fix: A bug fix

  6. perf: A code change that improves performance

  7. refactor: A code change that neither fixes a bug nor adds a feature

  8. style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)

  9. test: Adding missing tests or correcting existing tests

Scope

The scope should be a reasonable summation of where one could find the work done in the app.

The following is the list of supported scopes. It is not set in stone, so do add a scope if nothing already present makes sense. Consider it as to be priority-ordered, and use the first thing that feels like a solid fit.

{feature-name}

New feature or edits/fixes to features. Features would be anything exported as its own package, e.g. registered in tsconfig.json as a 'namespace'.

firebase-function

Changes to or new Firebase Functions.

firebase

Updates to the Firebase templates, default users, document layout etc.

IAM

Identiy and Access Management. Any work that touches on authorization and security, again, that doesn’t fit in anything above. Which is unlikely

tools

Changes that affect anything under the /tools path.

There are already some exception to the above that don’t really come up much:

changelog

used for updating the release notes in CHANGELOG.md

none/empty string

useful for style, test and refactor changes that are done across all packages (e.g. style: add missing semicolons)

Subject

The subject contains succinct description of the change:

  1. use the imperative, present tense: "change" not "changed" nor "changes"

  2. don’t capitalize first letter

  3. no dot (.) at the end

Body

As with 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.

Closes should start with the word Closes with a space followed by the GitHub issue that the commit closes. For example "Closes #42".

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.

A detailed explanation can be found in this document.

Many thanks to the Google team for developing and publishing this document.