「タスクの単位」が鍵！ 適切なコミットでレビューの品質を上げるには？
ここからはGit中級者への第1歩につながる具体的な話をします。まずはレビューの品質向上につながるGitのテクニックについてです。
Gitのどのような部分がレビューの品質向上につながるかというと「コミット」だと筆者は考えています。コミットの単位に気をつけて、適切なメッセージを付けることによって2つの観点からレビューがしやすくなります。
1点目は「重要なところを重点的にレビューしやすくなる」という点です。コミットが適切な単位で分かれていることによって、レビュアーがコミットごとにコードを確認しやすくなります。
たとえば、誤字の修正とロジックの修正を1つのプルリクでレビューする場合、ロジック修正の方をより詳しくレビューしたいはずです。この2つがそれぞれ別のコミットになっていることによって、レビュアーはコミットごとにコードを確認しつつ、ロジック修正のコードのレビューに注力できるはずです。
2点目は「実装者の意図が伝わりやすくなる」という点です。コミットの流れは実装の流れを表すことができます。また、適切な粒度のコミットがなされることによって、コミットの一覧からプルリクエストの概要を知ることもできます。
たとえば、複数の変更点を含んだプルリクエストを作成したとします。そのうちの変更Aにはコミットが2つあります。下図の青いコミットです。その際にコミットの順番が、A-1、B、C、A-2、のような順番になってしまうことがあります（そういえばAについてはこの変更も必要だった、と最後に思い出すパターンなどですね）。順番として、A-1、A-2、B、Cと並んでいる方が、レビュアーとしては理解しやすいはずです。
ここからはコミットの単位について、気を付けた方が良い3点のポイントを紹介します。
エラーがない状態でコミットする
どのようなコミットでも基本的に意識すべきこととして「エラーがない状態でコミットする」という点が挙げられます。エラーというのは、コンパイルエラー、実行時エラー、静的解析エラー、自動テストの失敗、など多岐にわたります。このようなエラーがない状態でコミットするのが望ましいです。
たとえばバグが発生した際にコミットを1つずつさかのぼって、どこでバグが混入したかを調べることがあります。その際にこのようなエラーが残っていると、バグによるエラーなのか、中途半端な状態でコミットしたから発生しているエラーなのかの判別をつけるというワンステップが必要になってしまいます。
ロジックに影響がないものは単独でコミットする
変数名やファイル名の変更、ファイル移動、誤字脱字の修正、スクリプト実行の結果などその変更単独で意味を持つものについては、それぞれ単独でコミットすると良いです。
たとえばファイルを移動すると修正量は意外と多くなります。実際に変更する際にはエディタのリファクタリング機能などを利用して一括で変更することが多いはずですので、細かく隅々までレビューしたい、というものではないはずです。このような修正は単独でコミットされていることでレビュー時にわかりやすくなります。
プロジェクトで良く行う作業をスクリプト化したりすることもあります。スクリプト実行によってコードに変更が入る場合はその変更を1つのコミットにするとわかりやすいです。その際に、コミットメッセージにスクリプト名だったり実行時のコマンドを入れるのも良いでしょう。
「コミットの単位」より「タスクの単位」
今まで説明してきた2点以外はすべて1つのコミットで良いのかというと、そうでもありません。ここから先が工夫のしどころです。その際のコミットの分け方についてオススメの考え方を紹介します。
その考え方とは「『コミットの単位』よりも『タスクの単位』を考える」ということです。何かタスクを行う際に、まずはToDoリストを作ります。今から実装しようとしていることを小さいタスクに分解します。そのToDoリストに沿って1つずつ実装し、1つずつコミットします。作業中にやることが増えることもあります。たとえば既存コードにタイポを発見することもあるでしょう。その場合はToDoリストにタイポ修正を加えて、今の作業を続けます。
このように進めることによって、1つのコミットに複数の変更を混ぜることなく作業を進めることができます。見通しが立たない状況で実装を進めると、複数の変更を同時並行で進めてしまい、コミットにも複数の変更が混ざり合ってしまうことがあります。コミットの単位を考えるよりも、今から何をするのかの見通しを立てて進めることが結果的に適切なコミットの分割にもつながります。
