Commit-Message-Guidelines.md

Commit Message Guidelines

• This project commit specification is inspired by, and heavily based on, the Angular Commit Guidelines and Conventional Commits.
• Please read the Angular Commit Guidelines and Conventional Commits specifications before you make any contribution to this project.
• I, Dileepa Bandara, personally follow some standards on most commits to keep the format constant in order to make git commit messages easier to read and faster to reason about. Here, I am sharing an example of a commit message that follows the standards.

Commit Message Format

<type>(<scope>): <short_summary>
  │       │             │
  │       │             └─⫸ Summary in present tense. Not capitalized. No period at the end.
  │       │
  │       └─⫸ Commit Scope: animations|theme|version|common|compiler|compiler-cli|core|
  │                          elements|forms|http|language-service|localize|platform-browser|
  │                          database|server|routing|api|
  │                          upgrade|myl|packaging|changelog|readme|migrations|lock|build|
  │                          devtools, etc.
  │
  └─⫸ Commit Type: build|ci|docs|feat|fix|perf|refactor|test

<type>

Must be one of the following:

• build: Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)
• ci: Changes to our CI configuration files and scripts (example scopes: Circle, BrowserStack, SauceLabs)
• docs: Documentation only changes
• feat: A new feature
• fix: A bug fix
• perf: A code change that improves performance
• refactor: A code change that neither fixes a bug nor adds a feature
• test: Adding missing tests or correcting existing tests
• BREAKING CHANGE: A breaking API change is introduced after the type or scope, or whenever the directories are affected.

Examples:

build: commit message

ci: commit message

docs: commit message

feat: commit message

fix: commit message

perf: commit message

refactor: commit message

test: commit message

BREAKING CHANGE: commit message

<scope>

The scope could be anything specifying place of the commit change and it is optional. For example animations, theme, version, common, compiler, compiler-cli, core, elements, forms, http, language-service, localize, platform-browser, database, server, routing, api, upgrade, yml, packaging, changelog, readme, migrations, lock, build, devtools, etc.

The following is the list of examples of supported scopes:

• all: Changes that affect all the scopes.
• app: Changes that affect the app.
• blog: Changes that affect the blog.
• readme: Changes that affect the readme documentation.
• home: Changes that affect the home page.
• projects: Changes that affect the projects page.
• skills: Changes that affect the skills page.
• social: Changes that affect the social page.
• work: Changes that affect the work page.

<short_summary>

Use the summary field to provide a succinct description of the change:

• Use the imperative, present tense: "change" not "changed" nor "changes"
• Don't capitalize the first letter
• No dot (.) at the end

Example

feat: add new theme colors
docs(readme): update relevant screenshots
fix(routing): fix service routing issue