GitのCommitについて
ここではtraPのSysAd班などで活動する人が触れることになるGitに関連する重要な内容として、コミットの粒度やコミットメッセージの付け方などについて説明します。 Gitの基本的な内容については省略しますので、もし不安がある人はGit講習会の資料や公式のドキュメントを読んでください。
コミットの粒度の基本原則
まず、コミットは小さい単位で行うのが良いです。その理由としては、トラブルシューティングが容易であることが挙げられるでしょう。小さいコミットを繰り返すことにより、問題が発生した時にその原因を特定しやすくなります。また、細かい変更ごとに履歴が残るため、どの変更がどのような影響を与えたのかを簡単に追跡することができます。
加えて、チーム開発においてもメリットがあります。複数人で開発する際にはGitHubなどを活用してチームメンバーからレビューをもらうことが多いですが、その際にコミットのサイズが小さければレビューする側もどのような内容を確認すれば良いのか明快でやりやすいという利点もあります。
ただし，小さければ小さいほどいいわけではありません。例えば一行ずつコミットを出してしまうと，見返しづらく，またその変更によって実現される動作が何なのかがわかりません。
では具体的にどのようなサイズでコミットを出せば良いのか，という疑問を持っている人もいると思うので，それについて次の章で説明します。
コミット粒度の具体例
ここからは、具体的にどのような区切りでコミットをすれば良いかということについて話します。最も良いのは，プログラムが意図した通りに動く変更の最小単位ごとにコミットを出すというものです。言葉を変えると，1つの機能追加/1箇所のバグ修正につき1コミットする，とも言えるでしょう。これには前述したように、変更の影響範囲を明確にしたり、レビューをやりやすくしたりという意図があります。他にも、コーディングのフォーマットやスタイルの変更やリファクタリング(コードの整理・最適化)なども1つのコミットとして扱うこともあります。
いずれにせよ、最も重要なことはチームメンバーとコミットに関するルールを共有し、それに従うことです。上記の話はあくまで基本原則であってその時の状況や開発チームの方針によって変わりうるものですから、チーム内での方針に則って進めていくことが大切でしょう。もし何かわからないことや不安なことがあれば、チームメンバーに相談することも大切です。
コミットメッセージの書き方
次に、コミットメッセージの書き方について説明します。コミットメッセージとはGitではコミットをする際につけることができる、コミットのタイトルのようなものです。
このコミットメッセージの書き方としてはまず、変更内容が簡潔に伝わるような内容を書く必要があります。また、そのコミットが何のためのものであるかの大まかな分類を接頭辞(Prefix)としてコミットメッセージに含める場合もあります。Prefixは沢山ありますが，その内よく使うものをまとめたので参考にしてください。
| Prefix | 説明 |
|---|---|
fix | バグ修正 |
feat/add | 新機能の追加 |
chore | ライブラリや補助ツールなどの更新 |
clean/refactor | リファクタリング、コードの改善 |
test | テストに関する変更 |
docs | ドキュメントの更新 |
より詳細な説明をする必要があれば、GitHubなどのコメント機能なども活用しましょう。コミットメッセージの書き方についてもチームごとに方針が決まっている場合があるので、チームのやり方に合わせるようにしましょう。
上記2章分の内容の総括として、実際の開発でどのようなコミットを出せば良いのか具体例を示しておきたいと思います。 みなさんにこの後作ってもらうToDoアプリを例に考えてみると、例えばfeat:ハンバーガーメニューやfix: onClick関数が意図しない動作をしていた問題のような粒度でコミットを出すと良いと思います。どちらも1つのコミットでの変更される機能は1つにとどまっていそうですし、コミットメッセージからそのコミットの役割を容易に推察することができます。
ぜひみなさんも、よりより開発ができるよう、Gitの扱い方に少しずつ慣れていってください。