意味のあるprefixをコミットメッセージにつけてレビュワーに思いやりを
2024-07-03
5 months ago
前提
そもそもコミットメッセージにPrefixをつけるとは？という疑問をお持ちの方は以下の記事などご一読ください。
Prefixを付ける意義や導入時におすすめのツールなど、すでに記事などがたくさんあるので割愛します。
本題
コミットメッセージにPrefixをつける運用を始めてみて、プロジェクトによって必要なPrefixは変わってくるな、と感じました。
Prefixは以下のhttps://github.com/commitizen/cz-cliの8種類を利用していることが多いと思います。
しかし、プロジェクトによってはこういう時どうなの？みたいな疑問が出てくることが多々があります。
例えばCIでGitHubActionsを利用しているプロジェクトだと、CI関連の変更はchore:に入れる？どうする？となったりします。
また、Amplifyのプロジェクトで作業ブランチごとにバックエンドを生成しているプロジェクトだと、環境を変更するだけで自動的に相当数のファイルが書き変わります。
これらは本質的な変更ではないので、PRでは無視したい内容とも言えます。
結論、以下の２点がとても大事です。
- プロジェクトごとに柔軟に変更する必要はあるので、随時話し合ってアップデートしていくこと
- Prefixを追加することが目的にならないこと
- ドキュメント化して開発者が迷うことなく使えること
あくまでも一例ですが、ci:やprepare:のようなPrefixを用意するのもありかと思います。
### feat:
- 説明: 新しい機能の追加。
- 例: `feat: ユーザー認証機能を追加`
### fix:
- 説明: バグの修正。
- 例: `fix: ログインページのエラーを修正`
### docs:
- 説明: ドキュメントの作成、変更。コードには変更を加えない。
- 例: `docs: READMEにインストール手順を追加`
### style:
- 説明: コードのスタイルに関する変更。動作には影響しない（ホワイトスペース、フォーマット、セミコロンの欠如など）。
- 例: `style: インデントを2スペースに変更`
### refactor:
- 説明: リファクタリング。バグ修正や機能追加を伴わないコードの改善。
- 例: `refactor: 認証ロジックをリファクタリング`
### perf:
- 説明: パフォーマンスを向上させる変更。
- 例: `perf: クエリの実行速度を改善`
### test:
- 説明: テストの追加や修正。
- 例: `test: 新しいテストケースを追加`
### chore:
- 説明: ライブラリインストールなどソースコードやテストには影響しない変更。
- 例: `chore: パッケージのバージョンをバンプ`
### ci:
- 説明: 継続的インテグレーションに関する設定やスクリプトの変更（例: GithubActionsなどの設定ファイル）。
- 例: `ci: GitHubActionsの設定を更新`
### prepare:
- 説明: 環境構築、切り替え時の差分（PR時はこのPrefixコミットは無視してOK）。
- 例: `prepare: 新しくバックエンド環境を作成`さいごに
一番大事なことは、Prefixを追加することが目的にならないことです。
例えば今回紹介したprepare:では、これを追加することでコードレビューの際に特定のコミットを無視することでレビュワーの負担軽減を狙っています。
また、細かく分けすぎると、逆に開発者の負担になるのである程度大まかに考えるのがおすすめです。
うまく活用すると間違いなく開発しやすくなると思うので、いろいろ試してみてください。