gitchangelog 实用技巧用正则表达式把提交精准分类到 New、Changes、Fix 各分节完整指南【免费下载链接】gitchangelogCreates a changelog from git log history.项目地址: https://gitcode.com/gh_mirrors/gi/gitchangeloggitchangelog 是一款从 git 提交历史自动生成 changelog更新日志的 Python 工具。只要约定好提交信息的前缀格式如new:、fix:、chg:它就能借助正则表达式把每一条提交精准分类到 New、Changes、Fix 等分节中输出排版整齐的 ReStructuredText 或 Markdown 格式更新日志帮你彻底告别手写 changelog 的痛苦 1. 它解决什么问题手动维护更新日志有两个痛点耗时每次发版都要翻阅git log手动整理哪些是功能、哪些是修复易错容易漏写、错分类格式也难以统一。gitchangelog 的思路是提交信息本身就是数据。你在提交时写上的new:、fix:前缀就是分类的依据。工具读取整个仓库历史后自动分组归类一次生成所有版本的完整日志。核心能力一览完全由配置文件驱动可按需定制 changelog 策略用正则表达式过滤提交、过滤 tag用正则表达式把提交消息分类到不同分节New、Changes、Fix……用正则替换即时重写提交标题让输出更美观支持 mako、mustache 等模板引擎输出任意格式。2. 一分钟安装上手 通过 pip 安装即可pip install gitchangelog安装后把配置文件放在 git 仓库根目录推荐命名为.gitchangelog.rc。然后在仓库中执行gitchangelog更新日志就会打印到标准输出。 项目自带了一份注释详尽的参考配置所有默认值都来自它src/gitchangelog/gitchangelog.rc.reference。建议直接复制一份作为起点。3. 分类核心section_regexps 是怎么工作的 gitchangelog 的分节分类完全由配置项section_regexps决定。它是一个**分节标签 → 正则表达式列表的有序列表**对每条提交的标题subject逐一做正则匹配命中哪一节的正则就归入哪一节。官方默认配置见src/gitchangelog/gitchangelog.rc.reference长这样section_regexps [ (New, [ r^[nN]ew\s*:\s*((dev|use?r|pkg|test|doc)\s*:\s*)?([^\n]*)$, ]), (Changes, [ r^[cC]hg\s*:\s*((dev|use?r|pkg|test|doc)\s*:\s*)?([^\n]*)$, ]), (Fix, [ r^[fF]ix\s*:\s*((dev|use?r|pkg|test|doc)\s*:\s*)?([^\n]*)$, ]), (Other, None ## 兜底匹配所有剩余行 ), ]逐行拆解这条正则你会发现它的精准来自三处设计^[nN]ew\s*:——^锚定行首保证前缀必须在提交标题开头避免正文里偶然出现 new: 被误分类可选受众段(dev|use?r|pkg|test|doc)\s*:\s*—— 兼容new: xxx和new: usr: xxx两种写法(Other, None)—— 列表末尾放一个正则值为None的兜底分节它匹配所有未命中任何规则的提交保证日志不丢内容。实际效果一条fix: usr: 修复空提交消息导致崩溃的提交会进入Fix节new: dev: 增加分节排序功能进入New节其余杂项进入Other节。顺序即优先级一个必须知道的细节源码中分节匹配的函数 first_matching 是按列表顺序逐个尝试、命中即返回的。这意味着列表靠前的分节优先级更高如果你的两条正则会命中同一条提交它只会进入先出现的那一节兜底分节(Other, None)必须放在最后否则所有提交都会先被它吞掉。这正是 README 中提到的设计意图用元组列表而不是字典就是为了让你能通过调整顺序控制分节展示顺序和匹配优先级最终日志中分节的排列顺序也与section_regexps的书写顺序一致。4. 过滤噪音ignore_regexps 先于分类生效 ✂️分类之前还有一道过滤关卡ignore_regexps。任何完整提交消息匹配其中任一正则的提交会被整体忽略不出现在 changelog 中。官方默认值过滤了四类内容带!minor、!cosmetic、!refactor、!wip标签的琐碎提交错别字、重排版等面向pkg:、dev:受众的内部变更第一条 first commit空提交消息。约定玩法在提交标题里加!minor标签这条提交就会自动从日志中隐身。比如fix: 修正注释中的拼写错误 !minor这样你的 changelog 只保留用户真正关心的内容而不是一堆格式化噪音。5. 美化输出subject_process 正则替换 分类归分类展示归展示。section_regexps只负责归入哪一节不会修改文字本身。想让输出的提交描述干净漂亮还要配置subject_process处理管线。官方默认管线是subject_process (strip | ReSub(r^([cC]hg|[fF]ix|[nN]ew)\s*:\s*((dev|use?r|pkg|test|doc)\s*:\s*)?([^\n]*)([a-z]\s)*$, r\4) | SetIfEmpty(No commit message.) | ucfirst | final_dot)它做四件事用竖线|串联成流水线步骤作用ReSub(...)用正则替换剥掉new:、usr:等分类前缀只留正文SetIfEmpty(...)空消息兜底为 No commit message.ucfirst首字母大写final_dot确保以句号结尾也就是说同一条提交在内部经历了用前缀分类 → 剥掉前缀 → 规范化格式的完整流程。你完全可以自定义这条管线比如换成剥掉feat:/bugfix:之类的团队前缀输出立刻适配你们的提交规范。6. 换输出格式一行配置的事 默认引擎rest_py输出 ReStructuredText。想输出 Markdown只需把配置末尾的output_engine改为output_engine mustache(markdown)项目内置了多个可直接引用的模板src/gitchangelog/templates/mustache/markdown.tpl—— Markdown 格式src/gitchangelog/templates/mustache/restructuredtext.tpl—— mustache 版 RSTsrc/gitchangelog/templates/mako/ChangeLog.tpl、restructuredtext.tpl—— mako 引擎模板。也可以指定自己的模板文件路径相对路径从 git 仓库根目录解析模板数据结构的说明可参考 README 中的 Changelog data tree 一节。7. 进阶增量生成只更新新版本区块 发版时不想重新生成整份日志gitchangelog 支持REVLIST 增量模式例如gitchangelog 0.0.2..0.0.3只输出 0.0.2不含到 0.0.3含之间的内容。配合publish配置如FileInsertAtFirstRegexMatch还能把结果自动插入现有 CHANGELOG.rst 的指定位置。README 中给出了两套可直接复制的完整配方RST 版与 Markdown 版是每次发版提交一份日志工作流的官方答案。8. 新手避坑清单 正则写^开头了吗不锚定行首正文中的 fix: 会造成误分类兜底分节放最后了吗(Other, None)放前面会让所有提交进 Other分节顺序 展示顺序 匹配优先级三者在section_regexps中由列表顺序统一决定分类正则和展示正则别混为一谈section_regexps不改文字subject_process才负责剥离前缀只认提交标题subject做分类多行消息的正文不参与分节匹配标签如!minor也要写在第一行不想分节把section_regexps设为[(, None)]即可同时保留前缀不剥离。写在最后gitchangelog 的精髓在于配置即策略ignore_regexps管过滤、section_regexps管分类、subject_process管展示、publish管落地。把这三条正则管线配好git log里零散的前缀就会自动变成一份分节清晰、排版规范的 changelog——而且随着提交累积它永远保持最新 ✅更多使用场景无分节模式、增量日志、合并分支的历史归属可参考 README.rst 的 Use cases 章节。【免费下载链接】gitchangelogCreates a changelog from git log history.项目地址: https://gitcode.com/gh_mirrors/gi/gitchangelog创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 gitchangelog 实用技巧：用正则表达式把提交精准分类到 New、Changes、Fix 各分节（完整指南）
gitchangelog 实用技巧用正则表达式把提交精准分类到 New、Changes、Fix 各分节完整指南【免费下载链接】gitchangelogCreates a changelog from git log history.项目地址: https://gitcode.com/gh_mirrors/gi/gitchangeloggitchangelog 是一款从 git 提交历史自动生成 changelog更新日志的 Python 工具。只要约定好提交信息的前缀格式如new:、fix:、chg:它就能借助正则表达式把每一条提交精准分类到 New、Changes、Fix 等分节中输出排版整齐的 ReStructuredText 或 Markdown 格式更新日志帮你彻底告别手写 changelog 的痛苦 1. 它解决什么问题手动维护更新日志有两个痛点耗时每次发版都要翻阅git log手动整理哪些是功能、哪些是修复易错容易漏写、错分类格式也难以统一。gitchangelog 的思路是提交信息本身就是数据。你在提交时写上的new:、fix:前缀就是分类的依据。工具读取整个仓库历史后自动分组归类一次生成所有版本的完整日志。核心能力一览完全由配置文件驱动可按需定制 changelog 策略用正则表达式过滤提交、过滤 tag用正则表达式把提交消息分类到不同分节New、Changes、Fix……用正则替换即时重写提交标题让输出更美观支持 mako、mustache 等模板引擎输出任意格式。2. 一分钟安装上手 通过 pip 安装即可pip install gitchangelog安装后把配置文件放在 git 仓库根目录推荐命名为.gitchangelog.rc。然后在仓库中执行gitchangelog更新日志就会打印到标准输出。 项目自带了一份注释详尽的参考配置所有默认值都来自它src/gitchangelog/gitchangelog.rc.reference。建议直接复制一份作为起点。3. 分类核心section_regexps 是怎么工作的 gitchangelog 的分节分类完全由配置项section_regexps决定。它是一个**分节标签 → 正则表达式列表的有序列表**对每条提交的标题subject逐一做正则匹配命中哪一节的正则就归入哪一节。官方默认配置见src/gitchangelog/gitchangelog.rc.reference长这样section_regexps [ (New, [ r^[nN]ew\s*:\s*((dev|use?r|pkg|test|doc)\s*:\s*)?([^\n]*)$, ]), (Changes, [ r^[cC]hg\s*:\s*((dev|use?r|pkg|test|doc)\s*:\s*)?([^\n]*)$, ]), (Fix, [ r^[fF]ix\s*:\s*((dev|use?r|pkg|test|doc)\s*:\s*)?([^\n]*)$, ]), (Other, None ## 兜底匹配所有剩余行 ), ]逐行拆解这条正则你会发现它的精准来自三处设计^[nN]ew\s*:——^锚定行首保证前缀必须在提交标题开头避免正文里偶然出现 new: 被误分类可选受众段(dev|use?r|pkg|test|doc)\s*:\s*—— 兼容new: xxx和new: usr: xxx两种写法(Other, None)—— 列表末尾放一个正则值为None的兜底分节它匹配所有未命中任何规则的提交保证日志不丢内容。实际效果一条fix: usr: 修复空提交消息导致崩溃的提交会进入Fix节new: dev: 增加分节排序功能进入New节其余杂项进入Other节。顺序即优先级一个必须知道的细节源码中分节匹配的函数 first_matching 是按列表顺序逐个尝试、命中即返回的。这意味着列表靠前的分节优先级更高如果你的两条正则会命中同一条提交它只会进入先出现的那一节兜底分节(Other, None)必须放在最后否则所有提交都会先被它吞掉。这正是 README 中提到的设计意图用元组列表而不是字典就是为了让你能通过调整顺序控制分节展示顺序和匹配优先级最终日志中分节的排列顺序也与section_regexps的书写顺序一致。4. 过滤噪音ignore_regexps 先于分类生效 ✂️分类之前还有一道过滤关卡ignore_regexps。任何完整提交消息匹配其中任一正则的提交会被整体忽略不出现在 changelog 中。官方默认值过滤了四类内容带!minor、!cosmetic、!refactor、!wip标签的琐碎提交错别字、重排版等面向pkg:、dev:受众的内部变更第一条 first commit空提交消息。约定玩法在提交标题里加!minor标签这条提交就会自动从日志中隐身。比如fix: 修正注释中的拼写错误 !minor这样你的 changelog 只保留用户真正关心的内容而不是一堆格式化噪音。5. 美化输出subject_process 正则替换 分类归分类展示归展示。section_regexps只负责归入哪一节不会修改文字本身。想让输出的提交描述干净漂亮还要配置subject_process处理管线。官方默认管线是subject_process (strip | ReSub(r^([cC]hg|[fF]ix|[nN]ew)\s*:\s*((dev|use?r|pkg|test|doc)\s*:\s*)?([^\n]*)([a-z]\s)*$, r\4) | SetIfEmpty(No commit message.) | ucfirst | final_dot)它做四件事用竖线|串联成流水线步骤作用ReSub(...)用正则替换剥掉new:、usr:等分类前缀只留正文SetIfEmpty(...)空消息兜底为 No commit message.ucfirst首字母大写final_dot确保以句号结尾也就是说同一条提交在内部经历了用前缀分类 → 剥掉前缀 → 规范化格式的完整流程。你完全可以自定义这条管线比如换成剥掉feat:/bugfix:之类的团队前缀输出立刻适配你们的提交规范。6. 换输出格式一行配置的事 默认引擎rest_py输出 ReStructuredText。想输出 Markdown只需把配置末尾的output_engine改为output_engine mustache(markdown)项目内置了多个可直接引用的模板src/gitchangelog/templates/mustache/markdown.tpl—— Markdown 格式src/gitchangelog/templates/mustache/restructuredtext.tpl—— mustache 版 RSTsrc/gitchangelog/templates/mako/ChangeLog.tpl、restructuredtext.tpl—— mako 引擎模板。也可以指定自己的模板文件路径相对路径从 git 仓库根目录解析模板数据结构的说明可参考 README 中的 Changelog data tree 一节。7. 进阶增量生成只更新新版本区块 发版时不想重新生成整份日志gitchangelog 支持REVLIST 增量模式例如gitchangelog 0.0.2..0.0.3只输出 0.0.2不含到 0.0.3含之间的内容。配合publish配置如FileInsertAtFirstRegexMatch还能把结果自动插入现有 CHANGELOG.rst 的指定位置。README 中给出了两套可直接复制的完整配方RST 版与 Markdown 版是每次发版提交一份日志工作流的官方答案。8. 新手避坑清单 正则写^开头了吗不锚定行首正文中的 fix: 会造成误分类兜底分节放最后了吗(Other, None)放前面会让所有提交进 Other分节顺序 展示顺序 匹配优先级三者在section_regexps中由列表顺序统一决定分类正则和展示正则别混为一谈section_regexps不改文字subject_process才负责剥离前缀只认提交标题subject做分类多行消息的正文不参与分节匹配标签如!minor也要写在第一行不想分节把section_regexps设为[(, None)]即可同时保留前缀不剥离。写在最后gitchangelog 的精髓在于配置即策略ignore_regexps管过滤、section_regexps管分类、subject_process管展示、publish管落地。把这三条正则管线配好git log里零散的前缀就会自动变成一份分节清晰、排版规范的 changelog——而且随着提交累积它永远保持最新 ✅更多使用场景无分节模式、增量日志、合并分支的历史归属可参考 README.rst 的 Use cases 章节。【免费下载链接】gitchangelogCreates a changelog from git log history.项目地址: https://gitcode.com/gh_mirrors/gi/gitchangelog创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考