Enforcing Clear Git Commit Messages with a Webhook‑Based Monitoring Service

Background

In many teams developers write arbitrary commit messages—mixing Chinese and English, using vague terms like "fix bug"—which makes later maintenance difficult because it is hard to understand what a change actually does. To improve code‑base quality and developer efficiency, the team decided to monitor and enforce a clear commit‑message convention.

Standard Construction

After reviewing many public guidelines, the team adopted the Angular commit‑message style (the most widely used and supported by IDE plugins) and extended it with internal requirements, resulting in a concrete format: <type>(<scope>): <subject> type (required) indicates the category of the change. Allowed values are: feat: new feature fix / to: bug fix ( fix creates a diff and automatically resolves the issue; to only creates a diff, suitable for multi‑step fixes) docs: documentation style: formatting changes that do not affect code execution refactor: code restructuring without adding features or fixing bugs perf: performance or experience improvements test: adding tests chore: build or auxiliary tool changes revert: revert to a previous version merge: merge commits sync: synchronize mainline or branch bugs

scope (optional) describes the part of the code affected (e.g., DAO, Controller, service). If a change touches multiple scopes, * can be used.

subject (required) is a concise description of the commit purpose, limited to 50 characters, preferably in Chinese, and without a trailing period.

Example messages:

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

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

Benefits of the Standard

Easy traceability of the commit history.

Encourages granular commits, preventing unrelated changes from being bundled together.

Facilitates automated generation of changelogs.

Monitoring Service

To enforce the convention, the team built a webhook‑based monitoring service that triggers on every git push. The service extracts the commit message, validates it against the format, and sends warning messages for violations. It also checks for large‑code submissions and file deletions, storing all records in a database for later statistics.

The workflow is:

Service registration – add repository information.

Duplicate check – avoid re‑running validation on already processed merge requests.

Message alert – send warnings for non‑compliant messages, large commits, or deletions.

Database – persist project and commit data to calculate compliance rates.

When a commit is pushed, the webhook:

Retrieves the commit message and validates the format.

If valid, calls the GitLab API to obtain the diff, checks commit size and file operations, and records the data.

If invalid, sends an alert to a DingTalk group.

Architecture diagram:

Future Considerations

Git hooks can be implemented on both client and server sides. Server‑side hooks (e.g., post‑receive) can only warn, while pre‑receive can reject non‑compliant commits outright if repository permissions allow. Client‑side hooks ( pre‑commit, commit‑msg) can enforce the standard before the push, but require distributing hook scripts to all developers, possibly via a global Git template.

Beyond message validation, the monitoring data can be used to:

Track individual developer activity and compliance rates.

Link commits to bug IDs or requirement IDs (e.g., feat*786990) for traceability.

Generate richer change‑log and impact reports.

Conclusion

Adopting a clear Git commit‑message standard and automating its enforcement through a webhook dramatically improves code‑base maintainability, reduces debugging time, and supports automated changelog generation, all with minimal additional effort.