Commitizen工具在Monorepo项目中的配置指南

Commitizen工具在Monorepo项目中的配置指南

前言

在大型前端或后端项目中，Monorepo（单一代码仓库管理多个项目）架构越来越流行。Commitizen作为一款优秀的Git提交信息规范化工具，在Monorepo环境下也能发挥重要作用。本文将详细介绍如何在Monorepo项目中配置Commitizen，实现各子项目的独立版本管理和变更日志生成。

Monorepo项目结构

典型的Monorepo项目通常采用以下两种目录结构之一：

1. 平铺式结构：

.
├── library-b
│   └── .cz.toml
└── library-z
    └── .cz.toml

2. 嵌套式结构：

src
├── library-b
│   └── .cz.toml
└── library-z
    └── .cz.toml

子项目独立配置

每个子项目需要独立的Commitizen配置文件（.cz.toml），主要配置项包括：

[tool.commitizen]
name = "cz_customize"  # 使用自定义配置
version = "0.0.0"      # 初始版本号
tag_format = "${version}-library-b"  # 带子项目标识的标签格式
ignored_tag_formats = ["${version}-library-*"]  # 忽略其他子项目的标签
update_changelog_on_bump = true  # 版本更新时自动生成变更日志

关键点说明：

• tag_format确保每个子项目有独立的版本标签
• ignored_tag_formats避免其他子项目的标签干扰当前子项目的版本检测

版本更新操作

为各子项目单独执行版本更新命令：

cz --config library-b/.cz.toml bump --yes
cz --config library-z/.cz.toml bump --yes

变更日志管理策略

在Monorepo中，为每个子项目生成准确的变更日志需要特别处理。推荐两种策略：

1. 基于提交范围的策略（推荐）

利用Conventional Commits规范中的scope字段，在配置中指定匹配模式：

[tool.commitizen.customize]
changelog_pattern = "^(feat|fix)\\(library-b\\)(!)?:"

匹配的提交示例：

fix(library-b): 修复某个重要问题

2. 基于文件变更的策略

依赖CI/CD工具的文件变更检测功能，如：

• GitHub Actions的paths条件
• Jenkins的changeset条件
• GitLab CI的rules:changes条件

注意：这种方法可能不够可靠，因为开发者可能意外修改了其他子项目的文件。

最佳实践建议

1. 统一提交规范：全Monorepo采用相同的Conventional Commits规范
2. 明确scope命名：每个子项目应有独特且明确的scope名称
3. 自动化流程：将版本更新和变更日志生成集成到CI/CD流程中
4. 文档说明：为团队编写清晰的提交指南，特别是scope的使用规范

总结

通过上述配置，Commitizen可以在Monorepo环境中为每个子项目提供：

• 独立的版本管理
• 精确的变更日志生成
• 规范的提交信息约束

这种方案既保持了Monorepo的代码集中管理优势，又实现了各子项目的独立发布能力，是大型项目开发的理想选择。