この記事は DeNA 21 新卒 Advent Calendar 2020 の16日目の記事です。
はじめに
Gitを使っていく上でコミットメッセージは必須なものです。
そのメッセージ、fix とか適当になっていませんか？
コミットメッセージがおざなりなままだと、どんな変更をしたのかが掴みにくく、レビュー時や後で見たときにコードを追うのが難しくなります。
逆に、コミットメッセージをこだわるだけでより良い開発環境、開発者体験を実現できます。今回は僕が良いと考えている書き方をまとめてみようと思います。
この記事のターゲット
- Gitを使ったことがある方
- チームで決められたコミットルールを理解、改善したい方
- よりよい開発者体験を実現したい方
※諸注意
まず、コミットメッセージの書き方に正解はありません。タイトルにもあるとおり、あくまで「僕が良いと考えている」書き方なので、一意見として参考にしていただけると嬉しいです。
結論
以下のようになります。
feat: 〇〇なため、△△を追加
ここから各ポイントについてそれぞれ説明していきます。
- Prefixをつける
- 理由を書く
- 日本語 or 英語？
1. Prefixをつける
Prefixとは何かしらのテキストの先頭につける文字のことです。
コミットメッセージのPrefixは様々な種類があり、独自のルールを作っているチームもあるのではないでしょうか。
こちらの参考記事でも紹介されていますが、Angular.js/DEVELOPERS.mdのものが今の所一番しっくりきており、基本的にこのルールで書くことが多いです。
feat: A new feature
fix: A bug fix
docs: Documentation only changes
style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
refactor: A code change that neither fixes a bug nor adds a feature
perf: A code change that improves performance
test: Adding missing or correcting existing tests
chore: Changes to the build process or auxiliary tools and libraries such as documentation generation
- feat: 新しい機能
- fix: バグの修正
- docs: ドキュメントのみの変更
- style: 空白、フォーマット、セミコロン追加など
- refactor: 仕様に影響がないコード改善(リファクタ)
- perf: パフォーマンス向上関連
- test: テスト関連
- chore: ビルド、補助ツール、ライブラリ関連
理由としては、
- どのカテゴリのものを修正したのかが見てわかりやすい
- コードロジックに影響がある変更かが瞬時にわかる
などがあり採用しています。
また、このprefixに合わせてコミットを分けることで、大きすぎず小さすぎない、適切な大きさになると思います。
2. 理由を書く
feat: 〇〇なため、△△を追加
変更した理由や目的を書くことでコードレビューが圧倒的にしやすくなります。例えばライブラリの追加時にも
chore: hogeを追加
ではなく
chore: ネットワーク通信するため、hogeを追加
と書いた方がよりわかりやすいと思います。
また、理由を書くように意識することで なぜこの変更をする必要があったのか(変更の意図)、コミットの大きさは適切かなどを深く考えることとなり、コードもより洗練されていくと思います。
もちろん、(Modelの定義など) 理由が書きにくい場合もありますが、あくまで後でどんな人が見てもわかるメッセージであれば大丈夫だと思うので、場合によっては書かなくてもOKだと思います。
3. 日本語 or 英語？
英語で書くべきか、迷うことも多いですよね。
自分は 個人開発やOSSとして公開するものは 英語で書き、日本人が多いチームでの開発では日本語 で書くようにしています。
英語で書くメリット
- 語学力向上
- 最初に動詞が来るためぱっと見てわかりやすい
- OSSの貢献ハードルが下がる
英語で書くデメリット
- 英文を考えるのに時間がかかる(語彙の検索など)
- 読むのに時間がかかる
英語の方がスキルとして伸ばせて良い感じがしますが、日本語に比べ読み書きに時間がかかってしまいがちです。
ただ、開発者チームの中で共通意識が取れるものであればどちらでも良いと思っています。
終わりに
コミットメッセージにこだわることでコードレビューも不具合への対処もスムーズになります。より良い開発者体験を実現するため、ぜひこだわってみてください！
宣伝
この記事を読んで「面白かった」「学びがあった」と思っていただけた方、よろしければ Twitter や facebook、はてなブックマークにてコメントをお願いします！
また DeNA 公式 Twitter アカウント @DeNAxTech では、 Blog記事だけでなく色々な勉強会での登壇資料も発信してます。ぜひフォローして下さい！→ Follow @DeNAxTech