hiroaki's blog

技術系を中心に気になったこととかいろいろと。

Git のコミットメッセージに Semantic Commit Messages のテンプレートを追加する

Git のコミットメッセージ周りで毎回気になって調べているのでメモとしてまとめておく。

よく発生する問題

Git のコミット周りでは主に下記の 2 つの内容が問題として上がってくることが多い。

1. Git のコミットメッセージが個人によってばらつきが出てくる。

実際にどういう修正をしたのかを具体的にコミットメッセージに書いてほしいが、その時の状況によって特に意味のないメッセージでコミットしてしまうことがよくある気がする。

開発中には特に問題になることはないが、あとからコミットメッセージを見返すとき(例えば障害の原因調査など)にどんな修正をしたのかがコミットメッセージからは判別できなくなるという状況になってしまう。

2. 導入したコミットフォーマットを導入しても普段の開発で必ず遵守されるとは限らない。

上記の問題を解決するためにコミットのテンプレートを用意したとしても、必ずそれに従って書いてくれるかというとそれは別の問題となってくる。

よくありがちなのは README にルールは書いてあるが書いてあるということを知らなかった、ということが起きる。新規参画者向けに導入マニュアルを準備して「これに従ってね」と書いても見るのは最初の 1 度のみで開発を進めていくにつれ内容を忘れてしまうということが起きる。

解決したいこと

これを解決するためには極力ルール化による手作業に頼らず、開発フローの中で目につくところにルールを差し込んでおけるようにしておきたい。具体的には下記の 2 点を対応することである程度の問題が回避できるはずだと思っている。

  1. コミットメッセージを分かりやすくするためにフォーマットを導入する
  2. コミットの際に入力フォーマットを確認できるようにする。

1. コミットのフォーマットを導入する

1つ目のコミットメッセージのばらつきに関してはフォーマットを導入することで平準化することができる。自分たちでフォーマットを考えてもよいが、既にわかりやすい一般化されたルールがあるのでそれに従うのがわかりやすい。

Semantic Commit Messages · GitHub

ざっくりと説明するとコミットメッセージの prefix としてコミットタイプを記載することで「このコミットがどういう内容を含んでいるのか」を表現する。(詳細はリンク先を参照)

+ feat: (new feature for the user, not a new feature for build script)
+ fix: (bug fix for the user, not a fix to a build script)
+ docs: (changes to the documentation)
+ style: (formatting, missing semi colons, etc; no production code change)
+ refactor: (refactoring production code, eg. renaming a variable)
+ test: (adding missing tests, refactoring tests; no production code change)
+ chore: (updating grunt tasks etc; no production code change)

今までのプロジェクトでもこのようなルールは使っていたが、具体的に「Semantic Commit Messages」という名前がついているのは知らなかった。

2. コミット時に入力フォーマットを確認できるようにする

コミットルールを周知させるために Git の Commit Template という機能を利用する。

Git - Git Configuration

テンプレートファイルの作成

Git の config で対象ファイルをコミットテンプレートとして使用するように設定しておくことで、コミット時のデフォルトメッセージとしてセットされる。ファイル名には特に指定はないので .git_commit_template という名前でファイルを作成する。凡例はコメントアウトとして認識させるために先頭に # を追加しておく。

  
# feat: (new feature for the user, not a new feature for build script)
# fix: (bug fix for the user, not a fix to a build script)
# docs: (changes to the documentation)
# style: (formatting, missing semi colons, etc; no production code change)
# refactor: (refactoring production code, eg. renaming a variable)
# test: (adding missing tests, refactoring tests; no production code change)
# chore: (updating grunt tasks etc; no production code change)

テンプレートとして認識させるための設定

このファイルをテンプレートとして使用するには下記のコマンドを実行する。

git config commit.template ~/.git_commit_template

自分のルールとして必ず適用させたい場合は --global で一律設定してしまってもよいが、プロジェクトによってルールが異なることがほとんどだと思うので、プロジェクトごとのリポジトリ内にテンプレートファイルを配置してプロジェクト単位で設定するほうが良いと思う。

実際のコミット

この状態で git commit を実行すると下記のように、

git commit template で指定した内容 ← ここが今回追加した箇所
git status の結果(デフォルトで表示されるもの)

という順番で表示されるようになる。コメントアウト部分はコミット時に無視されるので、先頭部分にフォーマットに従ってコミットメッセージを記述して保存するだけで良い。

  
# feat: (new feature for the user, not a new feature for build script)
# fix: (bug fix for the user, not a fix to a build script)
# docs: (changes to the documentation)
# style: (formatting, missing semi colons, etc; no production code change)
# refactor: (refactoring production code, eg. renaming a variable)
# test: (adding missing tests, refactoring tests; no production code change)
# chore: (updating grunt tasks etc; no production code change)

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
#
# On branch master
# Your branch is up to date with 'origin/master'.
#
# Changes to be committed:
# new file:   git/Git-Commit-Template.md
#

まとめ

これである程度のルール化と周知ができるようになる。
ただ、初回の commit.template の設定だけは必ずやってもらう必要があるので README に書いておくとか初回のセットアップマニュアルに組み込むなりで対応する必要があるのでご注意を。