Git Commit Convention | Joy Zhao - Full Stack Developer

Why We Need Commit Conventions

In team collaboration, if Git commit messages are precise, they become traceable during later collaboration and bug handling. Project development can quickly generate development logs based on standardized commit messages, making it easier for developers or users to track project development information and feature updates.

Structure of Commit Messages

A commit message consists of three parts: Header, Body, and Footer.

<Header>

<Body>

<Footer>

The Header section includes three fields: type (required), scope (optional), and subject (required).

<type>(<scope>): <subject>

type

The type indicates the category of the commit and only allows the use of the following seven identifiers:

feat: new feature
fix: bug fix
docs: documentation
style: formatting (changes that do not affect code execution)
refactor: code changes that neither add features nor fix bugs
test: adding tests
chore: changes to the build process or auxiliary tools

If the type is feat or fix, the commit will definitely appear in the Change log. For other cases (docs, chore, style, refactor, test), it’s up to you whether to include them in the Change log, though it’s recommended not to.

scope

The scope indicates the range affected by the commit, such as data layer, control layer, view layer, etc., which varies depending on the project.

subject

The subject is a brief description of the commit’s purpose, not exceeding 50 characters.

Start with a verb in the present tense of the first person, such as “change” instead of “changed” or “changes”
First letter lowercase
No period (.) at the end

Body

The Body section is a detailed description of this commit and can be divided into multiple lines.

There are two points to note:

Use the present tense of the first person, such as “change” instead of “changed” or “changes”
Should explain the motivation for the code change and the comparison with previous behavior

The Footer section is only used for two situations:

Breaking Changes

If the current code is incompatible with the previous version, the Footer section should start with BREAKING CHANGE, followed by a description of the change, the reason for the change, and the migration method.

BREAKING CHANGE: isolate scope bindings definition has changed.

    To migrate the code follow the example below:

    Before:

    scope: {
      myAttr: 'attribute',
    }

    After:

    scope: {
      myAttr: '@',
    }

    The removed `inject` wasn't generaly useful for directives so there should be no code using it.

Closing Issues

If the current commit addresses a specific issue, you can close this issue in the Footer section.

Closes #234

You can also close multiple issues at once.

Closes #123, #245, #992

Examples

feat(browser): onUrlChange event (popstate/hashchange/polling)

Added new event to browser:
- forward popstate event if available
- forward hashchange event if popstate not available
- do polling when neither popstate nor hashchange available

Closes #123, #305, #392

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.

docs(changelog): update change log to beta.5

style(router): fix linting errors

refactor(core): rename onInit to ngOnInit

chore(deps): bump rxjs from 5.0.0-beta.2 to 5.0.0-beta.6

Summary

Standardized Git commit messages can help team members better understand and follow unified commit standards, improve team collaboration efficiency, and also provide convenience for later project maintenance.