How a Structured Git Commit Message Standard Boosts Code Quality and Automation

Background

Every Git commit requires a commit message, but in practice messages are often inconsistent, mixing languages and using vague terms like "fix bug," which makes later maintenance difficult. To improve code quality and developer efficiency, a monitoring system was built to enforce a clear commit‑message standard.

Specification Construction

After reviewing many Git commit guidelines, the widely adopted Angular convention was chosen as a base because it is systematic and has IDE support. The team combined it with existing internal rules to create a custom Git commit standard.

Commit Message Format

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

type (required)

The type indicates the category of the change and must be one of the following:

feat: new feature

fix/to: bug fix (fix creates a diff and automatically resolves the issue; to creates a diff without automatic resolution)

docs: documentation

style: formatting changes that do not affect code execution

refactor: code refactoring without new features or bug fixes

perf: performance or experience improvements

test: adding tests

chore: changes to build process or auxiliary tools

revert: revert to a previous version

merge: code merge

sync: synchronize mainline or branch bugs

scope (optional)

The scope describes the part of the code affected (e.g., data layer, controller, view). Multiple scopes can be represented with an asterisk (*).

subject (required)

The subject is a brief description of the commit purpose, limited to 50 characters, preferably in Chinese, and should not end with punctuation.

Examples

fix(DAO):用户查询缺少username属性

feat(Controller):用户查询接口开发

Benefits of the Standard

Facilitates traceability of commit history.

Encourages granular, meaningful commits rather than large, mixed changes.

Enables automated changelog generation.

Monitoring Service

A webhook monitors commits: if a message violates the standard, an alert is sent; otherwise, the webhook records diff size, file deletions, and other metrics. Alerts are delivered to a DingTalk group.

The service workflow includes registration, duplicate checking, alerting, and storing commit information for statistics.

Future Considerations

Git hooks (client‑side and server‑side) can enforce the standard more strictly. Server‑side pre‑receive hooks could reject non‑compliant commits, while client‑side pre‑commit hooks can prevent bad messages before they reach the server. Additionally, commit metadata can be linked to bugs or requirements for richer traceability.

Conclusion

Adopting a clear Git commit standard and monitoring it significantly reduces development friction, improves code traceability, and supports automated processes without adding noticeable overhead.