Git コミットメッセージ オレオレ グッド・プラクティス
はじめに
こんにちは! Build サービス推進チームで CDS をしている t.g です
みなさん Git つかってますか？ 複数メンバーで Git を使い始めると、コミットメッセージの書き方やそもそものコミットの作り方で慌てることがまれによくあります。
フォーマットやお作法などはプロジェクト毎で共通のものを作るのが良いでしょうが、それでも自分の中に「芯」があると慌てることが少なくなるはずです。
今回は、自分がよくお手本にしている Git Commit Good Practice をご紹介しようと思います。
元ネタ
Git Commit Good Practice 巨大プロジェクト OpenStack が作ったドキュメントです。 あまり、規則規則しておらずプラクティカルに書かれているため、初級を脱した方に良いと思われます
以下、自分が特に気に入った箇所を抜粋してお送りします
1. 機能変更によるコード変更と、空白追加によるコード変更を混ぜない
本当に必要な機能変更と、機能に関係ないコード変更(空行/空白の追加などno-opなコード)を同一コミットに混ぜないほうが良いとのこと。 必要なら、コミット分割で対処
はじめのコミット: 空白行だけ
次のコミット: 機能変更
こうしないとレビューの邪魔になります。なお、順番は決まっておらず好きな方でとのこと。
2. 大量の新機能を巨大な 1 個のコミットに入れない
ある単一の新機能を成立させるために、複数のコード変更が必要な場合にやってしまいがち。 その場合、コミットを以下のように分割する
既存コードのリファクタリング
新機能の追加
こうすれば、リファクタリングが予期せぬ機能変更を行っていないことを、レビューやテストで確認できます
3. 無関係な 2 個の機能変更を混ぜない
一番大事な基本: 「1 コミットに含まれる"ロジック変更"は 1 個まで」
レビューが早くなる
潜在的なバグが見つけやすくなる
コード変更部分にバグが見つかったときの revert 単位が小さくなる <-- ココ大事
特に revert 単位を小さくしておくのは、万一のときの負債が小さくなり効果絶大です。
最後に
まとめると以下のようになります
・no-opsな変更は別コミットに入れる
・コードのリファクタリングは別コミットに入れる
・1 コミットに含まれるロジック変更は最大１個まで
本文にはもっとたくさん有益な情報が書いてあります(コミットメッセージに含めるべき情報 vs 含めない情報 など) ぜひ本文も見て活用してみてください!!