はじめに
新年あけましておめでとうございます。今年もよろしくお願いします。
で、新年一発目の記事ですが、現在業務でアプリ開発以外にチーム運営にも携わっており、その中でGit運用のことを少しやっております。
今回から数回は、そのGit運用について書こうと思います。
今回＆今後記載する内容
- コミットメッセージを統一する ←今回はこれ
- コミットメッセージをチェックする
- ログ＆バージョニングを管理する
目的
コミットメッセージを統一する目的としては
- コミットメッセージから変更内容をわかりやすくする
- チーム内で記法を統一する。(メンバー間でばらばらにしない)
- リポジトリ(≒アプリ)のバージョン管理をしやすくする
- これは「ログ＆バージョニングを管理する」で説明します
等があります。
たとえば、「index.jsを変更」というコミットメッセージがあった場合、下記の問題があります。
- 具体的にindex.jsの何を変更したのかが分からない。
- それは何のために実施したのかが分からない。(バグ修正、パフォーマンス改善など)
こういった点を極力無くし、意味のある分かりやすいコミットメッセージにしよう、というのがその狙いです。
コミットメッセージの統一
コミットメッセージの統一の指標として、「Semantic Commits」とか「Conventional Commits」と呼ばれるものがあります。
こういった指標を用い、意味のある(=semantic)かつ定型的(=conventional)なコミットメッセージを作成することで、チーム内でコミットメッセージを統一するのに役立ちます。
Semantic CommitsやConventional Commitsの概要
Semantic CommitsやConventional Commitsの概要ですが、コミットメッセージは下記の形式で書くことが必要とされます。
<type>[optional (scope)]: <description> [optional body] [optional footer(s)]
各項目の説明は、下記のとおりです。
| 項目 | 説明 | 備考 |
|---|---|---|
| type(必須) | 変更の種類 | 詳細は下表参考 |
| scope(任意) | 変更対象の範囲 | アプリ名、ライブラリ名、モジュール名など |
| description(必須) | 変更内容の概要 | git commit -m で記載する内容 |
| body(任意) | 変更内容の説明 | descriptionで説明しきれない場合。 |
| footer(任意) | 補足説明 | breaking change(破壊的変更)がある場合、その内容をここに書く |
また「type」には、下記のようなものがあります。(あくまで推奨されているもので、これをベースにチーム内で検討するのが良い)
| 項目 | 説明 | 備考 |
|---|---|---|
| feat | 新規機能の追加 | |
| fix | バグ修正 | |
| docs | ドキュメントのみの変更 | ソース自体には変更なし。readme.mdの修正のみとか |
| style | スペース、インデント、末尾のセミコロンなどのみの修正 | |
| refactor | ソースのリファクタリング | |
| perf | パフォーマンス改善 | improveにする場合もある模様 |
| test | テストソースの変更 | |
| build | ソースのビルド関連の処理の変更 | webpackやbabelとか |
| ci | ci/cd関連のソースや設定の変更 | github ActionsやCircle CIなど |
| chore | ライブラリ追加など、ソース本体には影響しない変更。 | 上記に該当しないすべてのケースに当てはめてもOK |
たとえば「feat(components/xxx): add validation」だったら「xxxというコンポーネントにバリデーション機能を追加した」となります。
破壊的変更(breaking changes)
また、ソースに破壊的変更(=下位互換性を保証しない変更)が発生した場合、下記のいずれかを行う必要があります。
- type(またはtype(scope))の後に「!」をつける。(例：feat(app)!: xxx)
- footerに「BREAKING CHANGE:」 という記載をする。
上記が含まれたコミットは破壊的変更となり、下位互換性を保証しません。
またバージョン時には、メジャーバージョンが上がる形となります。(v1.0.0→v2.0.0)
サポートツール
上記のSemantic CommitsやConventional Commitsですが、手作業コミットで導入しようとしても、なかなか大変だと思います。(スペルミスなどもあるでしょうし)
そこで、これらをサポートするツールもあります。
cz-cli(https://github.com/commitizen/cz-cli)
commitizenが提供するサポートツール。
commitizenをglobal installすることで使えるようになります。
対話形式でSemantic CommitsやConventional Commitsのtype, scope, descriptionなどを設定することで、自動でそれらの形式のコミットメッセージを作成してcommitをしてくれます。
カスタマイズは後述のgit-czよりちょっとややこしそうですが、その分git-czより突っ込んだカスタマイズが出来そうです。
参考：Customization - Commitizen
git-cz(https://github.com/streamich/git-cz)
cz-cli同様、対話形式でSemantic CommitsやConventional Commits形式のコミットメッセージを設定できるツール。
こちらはcommitizenなしでも使えます。(一緒にインストールしてもOK)
cz-cliよりカスタマイズできる範囲は限られますが、その分カスタマイズ自体はcz-cliよりやりやすいです。(チーム内での運用レベルなら、必要十分な設定は揃っている印象)
なおcz-cliもエイリアスで「git-cz」を持っていますが、これはそれとはまったく別物になります。
まとめ
今回はGit運用として、コミットメッセージ統一、及びSemantic CommitsやConventional Commitsについて書きました。
これらの指標をベースにチーム内でコミットメッセージを統一すると、後で見返した際にも変更内容などが把握しやすくてよいと思います。
また「ログ＆バージョニングを管理する」で書きますが、これらをやっておくとバージョニングもやりやすくなるのでおススメです。
次回は「コミットメッセージのチェック」について記載しようと思います。
それでは、今回はこの辺で。
