Day 12：Commitizen

话说今天本来是打算要接着昨天的进度纪录架设 grafana 的 dashboard，可是昨天半夜 debug 到一半突然发现，今天不是 PyCon sprints 的日子吗，刚好我这次打算参与的专案是 commitizen，那我就借题发挥一下，来讲讲这个题目好了。虽然这跟 SRE 所关注的领域我认为算是稍微有点不同，但是在 DevOps 当中我想也是相当重要的一个部分。

commit message 的重要性

commit message 为什麽很重要？我想下面这张图应该可以很清楚的说明。记得我在前面几天的文有写到，有时候我们难免会将 bug 部属到生产环境内，在这个时候要让服务回复运作，比较合理的选项应该是赶紧恢复到上个可以运作的版本，可是若是打开 gis history 一看，commit 都长得跟图片里面一样的话，那可就令人头疼了。BTW，这是真的去 NOJ 的 repo 里面翻出来的 commit，不过应该都算是蛮久以前的，现在应该有比较好了。

commitizen 是什麽

那麽这个工具究竟是拿来做什麽的呢？简单来说它是可以帮助我们写出良好 commit message 的工具，让在同一个专案底下工作的每个成员都可以使用一套共同的规范来撰写漂亮的 commit message，举例来说，约定式提交 (Conventional Commits) 就是其中一个例子，遵循这套规范的 commit message 看起来大致上会像这样：

<类型 type>[可选的作用范围 scope]: <描述 description>

[可选的正文 body]

[可选的页脚 footer]

可以看到，它是有一个固定格式的，当每个 commit 都按照同样的规则来撰写的时候，也就意味着我们可以自动化的从里面 parse 出各种资讯，进而替专案引入一些方便的功能。

一个比较常见的例子是可以自动更新版号，因为针对每一笔 commit，我们都可以透过 type 栏位，或是检查 footer 里面是否有 BREAKING CHANGE 等资讯来判断一堆 commit 里面到底产生了多少变更，是修了 bug（对应的 type 是 fix）？还是引入了新的功能（对应的是 feat）？听说 commitizen 本身已经没有手动更新版号了，全部都是透过 GitHub Actions 处理。

另一个常见的功能是可以自动产生 changelog，像是下面这张是从 commitizen 的 changelog 截下来的。它就是 parse 两次版本之间的 commit message，然後再把它传换成 markdown 格式输出的结果。当 commit 有共通格式的时候，就可以让 parse 这件事变得比较简单，生出来的 changelog 比较好读。

小结

突然发现，今天好像是我第一次对开源专案发 PR（除了学校的专案，如果那算是开源的话），也是我第一次接触 commitizen 这个工具，希望以後可以逐渐习惯在专案中使用它。