【Git】良いcommitとは - ﾅｶﾞﾓﾄの blog

突然ですが、良いcommitとはなんだと思いますか？

Gitの使い方を解説するサイト、学習サイト*1は数あれど、「チーム開発ではこういうcommitをしましょう」といったことを解説されることはあまりないように感じます。

私は新人のPull Requestをレビュする際に、そもそも良いcommitについて共有することから始めたりします。その時のために自分の考えを整理する意味でもこの記事にまとめておきます。

良いcommitの特徴

良いcommitの粒度で良いcommitメッセージが書かれていれば、上記の特徴を持つ良いcommitだと言えるのではないでしょうか。

「アトミックである」の一言につきます。

日本語で言えば分割可能な最小単位であるということです。もちろん意味上の最小単位であって、1行変更ごとにcommitしろというわけではないです。

コードには How
テストコードには What
コミットログには Why
コードコメントには Why not

を書こうという話をした
— Takuto Wada (@t_wada) September 5, 2017

理想は上記の通り、whyが書いてあることです。アトミックなcommitであれば、どんな変更を加えたかはdiffから確認できます。diffからはわからない変更の意図を書きましょう。

こちらの記事も非常に参考になります。可能な範囲で原則に忠実にコミットしていくべきだと思います。 rochefort.hatenablog.com

ここまで理想を語りましたが、現実的には分割可能な最小単位に頭を悩ませたり、1つ1つのcommitにwhyを考えてメッセージに設定するのは時間がかかります。そして、大きな時間をかけるだけの価値があるかと言えば微妙です。ある程度の落とし所を探るべきでしょう。

Issueに取り組むとき、頭の中でステップを考えるかと思います。その1ステップを1commitと対応させましょう。

例) データ処理を行うAPIエンドポイントの追加(MVC Frame Workを使用している場合)

上から考えて、書けるものを書きましょう

whyを書こうと意識しすぎている場合に多いです。「改善のため」のような抽象的なwhyしか浮かばない場合はwhyで書くことを諦めても良いかもしれません。

うまく要約できていない場合に多いです、コミットメッセージだけで意味を成す表現にしましょう。「前のコミットの修正」ではどんな変更かイメージできませんし、「バグ対応」ではどんなバグやねんと思われます。「バグ対応続き」とかやめてくれ・・・

「Aをした」と書いてあるのに実際にはBしているようなメッセージが稀にあります。これなら書いていないほうがマシです。whyも要約も難しければ「AをBに、CをDに変更」などと愚直に書きましょう。

チームで統一しましょう、混同していなければ良いです。英語で書くのは難しいですが、プログラムは英語ベースですし、個人的には頑張ってみるのもおすすめします。

程度問題ではありますが、あまりに煩雑な場合は指摘しましょう。とはいえ、すぐにうまく書けるようになるものでもないので、最初にcommitの粒度・メッセージについて共有した上で、見守りましょう。commit logの潔癖性を押し付けるのはアンチパターンだと思います。

どんなcommitが良いcommitなのかチームで認識を共有して、ほどほどの落とし所を設定しましょう。