---
layout: "@/layouts/BlogPostLayout.astro"
title: "Git Commit Convention"
description: "This article details the Git commit convention, including the specific content and usage rules of the Header, Body, and Footer sections, helping team members better understand and follow a unified commit standard."
date: "2023-10-20"
image: "https://images.unsplash.com/photo-1618401471353-b98afee0b2eb?q=80&w=1476&auto=format&fit=crop"
tags: ["Git", "Convention", "Version Control"]
tagId: ["git", "convention", "version-control"]
category: "Development Tools"
categoryId: "dev-tools"
readTime: "5 min read"
---

### 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>
```

#### Header

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

#### Footer

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.