git commitする時に意識していること

この記事はPREVENTアドベントカレンダーの14日目の記事です。
https://adventar.org/calendars/10319

---

はじめまして！
株式会社PREVENT開発部にてフロントエンド開発をメインとしております、むぷんです。

下記では、Gitでコミットを作成する時に意識している3つの自分ルールについて述べます。

1.コミットメッセージで内容を説明する

「そんなんアタリまえじゃんッ」と思われるかもしれませんが、忙しい時、疲れている時に意外とおざなりになることがあります。
私が一番よく見てきた（やってしまった）アンチパターンが以下です。

良くない例

レビュー指摘事項を修正

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
#
# On branch feature/hoge
# Changes to be committed:
# modified:   src/path/to/hoge.ts
#
# ------------------------ >8 ------------------------
# Do not modify or remove the line above.
# Everything below it will be ignored.
-const sum = (a, b) => {
-  return a * b;
+const sum = (a: number, b: number): number => {
+  return a + b;
 };

メッセージ部分が

レビュー指摘事項を修正

となっています。

これだと、レビューする側・される側の間で意図が完結してしまい、
第三者がログを見た際に何を修正したのか、どんな理由でどのように修正をしたのかがわかりません。

5W1Hのうち、what（何を）、why（なぜ）、how（どのように）のいずれかは最低限ほしい情報です。
簡潔で良いので、変更内容を説明するコミットメッセージになるよう気をつけています。

改善例1

sum関数の型名と返り値を修正

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
#
# On branch feature/hoge
# Changes to be committed:
# modified:   src/path/to/hoge.ts
#
# ------------------------ >8 ------------------------
# Do not modify or remove the line above.
# Everything below it will be ignored.
-const sum = (a, b) => {
-  return a * b;
+const sum = (a: number, b: number): number => {
+  return a + b;
 };

メッセージを

sum関数の型名と返り値を修正

に変更し、ひとまず何を修正したかが明確になりました。

2.コミットメッセージにprefixをつける

prefix（接頭辞）を付けると、コミットの主旨がわかりやすくなります。

改善例2

fix: sum関数の型名と返り値を修正

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
#
# On branch feature/hoge
# Changes to be committed:
# modified:   src/path/to/hoge.ts
#
# ------------------------ >8 ------------------------
# Do not modify or remove the line above.
# Everything below it will be ignored.
-const sum = (a, b) => {
-  return a * b;
+const sum = (a: number, b: number): number => {
+  return a + b;
 };

fix: sum関数の型名と返り値を修正

fix:を頭に付与することで、修正のためのコミットのであることがより明確になりました。

PREVENTでは概ね、以下のprefixを付与するルールで運用しています。

• first: ブランチ作成後最初の空commit
• add: 新規ファイルや機能の追加
• fix: バグの修正
• update: 機能修正（バグではない、リファクタなども当てはまる）
• remove: ファイルやライブラリの削除

こちらはツールによるルール化が有効です。
huskyのpre-commitフックを設定することで、コミットにprefix付与を必須とするルールを強制することができます。

https://typicode.github.io/husky/

3.コミットを意味のある単位に分割する

今度はコミットの差分について触れます。

-const sum = (a, b) => {
-  return a * b;
+const sum = (a: number, b: number): number => {
+  return a + b;
 };

上記のTypeScriptコードは「型名の追加」と「返り値を掛け算から足し算に修正」の両方を同時に修正した差分ですが、
本来これらは独立した意味を持つものです。

このような場合はコミットの分割を考えます。

改善例3-1

add: sum関数の引数と返り値の型名を追加

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
#
# On branch feature/hoge
# Changes to be committed:
# modified:   src/path/to/hoge.ts
#
# ------------------------ >8 ------------------------
# Do not modify or remove the line above.
# Everything below it will be ignored.
-const sum = (a, b) => {
+const sum = (a: number, b: number): number => {
   return a * b;
 };

改善例3-2

fix: sum関数の返り値を足し算に修正

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
#
# On branch feature/hoge
# Changes to be committed:
# modified:   src/path/to/hoge.ts
#
# ------------------------ >8 ------------------------
# Do not modify or remove the line above.
# Everything below it will be ignored.
 const sum = (a: number, b: number): number => {
-  return a * b;
+  return a + b;
 };

add: sum関数の引数と返り値の型名を追加
fix: sum関数の返り値を足し算に修正

の2コミットに分割しました。

このようにするメリットは以下が挙げられます。

• レビュアーがコミットログを見る際に、具体的な変更箇所を把握しやすくなる
• これらのコミットが原因でバグが見つかった場合に、git revertコマンドでrevert（打ち消し）する範囲を最小限にできる

記載した例は単純なコードのため実感しづらいのですが、
コードの規模が大きくなるにつれて、適切な単位にコミットを分割することが有効だと考えています。

とはいえ毎度そんな都合よく分割などできず、うっかり巨大な差分を作ってしまう（レビュー負荷を上げてしまう）ことも少なくないのですが…

• git add -pでこまめにインデックス追加しながら、細かくコミット作成する
• 細かく分けすぎた！となったら、有意な単位のコミットにするためgit rebase -iなどでsquashし、複数のコミットをまとめる

といった手順を普段から意識し、計画的にコミット作成していくことが大事です。
※この場ではgitコマンドの解説は割愛します。悪しからず🙇

おわりに

Gitのコミットログもまた、開発に欠かせないドキュメントの一つだと考えています。
可読性の高い、リーダブルなコミットにすることを習慣づけたいですね！