Git Commit Message Standardization and Monitoring Service

Background

In many teams, commit messages are inconsistent, mixing Chinese and English, using vague terms like "fix bug", which makes later maintenance difficult. To improve code quality and developer efficiency, a clear commit‑message standard is needed.

Commit Message Specification

The adopted format follows the Angular convention:

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

Where type is mandatory and must be one of the following identifiers:

feat – new feature

fix / to – bug fix (fix creates a diff and automatically fixes, to only creates a diff)

docs – documentation

style – formatting changes that do not affect code execution

refactor – code changes that are neither features nor bug fixes

perf – performance or experience improvements

test – adding tests

chore – build process or auxiliary tool changes

revert – revert to a previous version

merge – code merge

sync – sync mainline or branch bugs

scope (optional) describes the part of the system affected (e.g., DAO, Controller). If multiple scopes are affected, use * .

subject (mandatory) is a concise description of the commit purpose, no longer than 50 characters, without trailing punctuation. Chinese is recommended for clarity.

Example messages:

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

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

Benefits of the Standard

Facilitates traceability of changes.

Encourages granular commits, improving history readability.

Enables automated generation of changelogs.

Monitoring Service

To enforce the standard, a webhook‑based monitoring service was built. When a developer pushes commits, the webhook extracts the commit message, validates it against the specification, and sends warning messages for violations. It also checks for large code changes and file deletions.

The service workflow includes:

Service registration – storing repository information.

Duplicate verification – preventing re‑validation of the same merge request.

Message alert – notifying about non‑compliant messages, large diffs, or deletions.

Database storage – persisting commit metadata for compliance statistics.

Webhook processing steps:

Trigger on push events.

Extract commit messages and diff information via GitLab API.

Validate format, diff size, and file operations.

Send alerts to a DingTalk group if any rule is violated.

Store the results for later reporting.

Statistics are visualized to show individual commit counts, non‑compliant counts, and compliance rates.

Future Considerations

Git hooks can be implemented on the client side (pre‑commit, commit‑msg, etc.) or server side (pre‑receive, post‑receive). Client‑side hooks can reject non‑compliant commits outright, while server‑side post‑receive hooks only warn. Integrating commit messages with bug or requirement IDs (e.g., feat *786990 ) can further link code changes to work items.

Conclusion

Standardizing commit messages and monitoring them is essential for software development efficiency and quality. The described webhook solution provides a practical way to enforce the standard and gather useful metrics without blocking developers.