Commitizen工具在多Poetry项目中的版本管理实践

Commitizen是一个优秀的Git提交规范和版本管理工具，它能够帮助开发者维护一致的提交消息格式并自动化版本管理流程。本文将重点介绍如何在包含多个Poetry项目的monorepo中使用Commitizen进行版本管理。

多Poetry项目版本管理需求

在monorepo架构中，我们经常会遇到多个Poetry项目共存的情况。每个项目都有自己的pyproject.toml文件，其中包含了项目版本信息。传统的手动维护这些版本信息既繁琐又容易出错。

Commitizen提供了两种主要的版本管理方式：

1. 直接从pyproject.toml读取版本信息(version_provider="poetry")
2. 使用Git标签管理版本(version_provider="scm")

配置方案详解

方案一：基于Poetry的版本管理

对于简单的场景，可以直接在.commitizen.cfg或pyproject.toml中配置：

[tool.commitizen]
tag_format = "v$version"
version_scheme = "pep440"
version_provider = "poetry"
version_files = ["**/pyproject.toml"]

这种配置会：

1. 使用Poetry作为版本提供者
2. 自动更新所有匹配的pyproject.toml文件
3. 遵循PEP 440版本规范
4. 生成的标签格式为"vX.Y.Z"

方案二：基于SCM的版本管理

更推荐使用Git标签来管理版本，配置如下：

[tool.commitizen]
tag_format = "v$version"
version_scheme = "pep440"
version_provider = "scm"
version_files = ["**/pyproject.toml"]

这种方式的优势在于：

1. 完全依赖Git标签管理版本，无需硬编码版本号
2. 与Poetry的SCM版本支持良好集成
3. 支持开发版本(dev)和预发布版本的自动管理

开发版本管理实践

对于开发中的版本，Commitizen与Poetry的集成可以很好地处理开发版本号。当使用version_provider="scm"时，Commitizen会自动识别Git中的最新标签，并根据提交历史决定下一个版本号。

开发版本通常遵循以下模式：

• 主版本号.次版本号.修订号.devN (如1.2.3.dev1)
• 主版本号.次版本号.修订号aN (alpha版本)
• 主版本号.次版本号.修订号bN (beta版本)

最佳实践建议

1. 对于monorepo项目，优先使用version_provider="scm"方式
2. 使用通配符(**/pyproject.toml)匹配所有子项目
3. 确保所有开发者在提交时都使用Commitizen规范
4. 在CI/CD流程中集成Commitizen版本检查
5. 定期使用cz bump更新版本并创建标签

通过以上配置和实践，可以在多Poetry项目的monorepo中实现高效、一致的版本管理，减少人为错误，提高开发效率。