プルリクエスト

プルリクエストは当然、このフローの中で一番重要なステップです。 そのため、プルリクエストの作り方に集中して制約を作ると、Gitの迷いが激減します。

多くのプロジェクトでsquashを求められるので、最初からsquashするようにします。 もちろん、1つのコミットにまとめるといっても、それが複雑で膨大になってしまってはいけません。 レビューも難しく、変更内容の記録としても役に立たないからです。 よってGitを使う上で最も重要なことは、1つのコミットの変更範囲をよく考えることです。 コードを変更する際は、最終的にどのようなプルリクエストになるか、というところを意識して、逆算でコードを変更したほうが良いでしょう。

分割する

ひとつのコミットは極力小さくしましょう。 その変更のトピックが一瞬でわかるように、時には恣意的とも感じるような分割をします。 例えば、機能開発中にリファクタリングはすることは多々ありますが、その場合リファクタリング部分だけを別プルリクエストにします。 リファクタリングも徹底的に小さく、ひとつのコミットにはひとつのトピックだけにし、数をたくさん撃ったほうがいいでしょう。 互換性のある変更と破壊的な変更は、それぞれ分割したプルリクエストにしたほうが見通しが良くなります。

変更点は小さく、まとめるよりは分割し、変更内容を明確にし、レビューはしやすく・・・ これ、何かに似てませんか? 行数は少なく、まとめるよりは分割し、責務を明確にすることで、処理の見通しはよくシンプルな単体テストで十分になる、メソッドの設計と非常に似ています。 プルリクエストの単位は、メソッドを設計するのとほぼ同様な考え方で細分化できます。

説明のしかた

メソッドと同様なので、良いメソッドがコメント不要であるように、良いプルリクエストはコミットコメント不要です。 実際、筆者はここ数年、ほとんど全くコミットコメントを書いていません。 コミットコメントが不要なほど徹底的にシンプルなプルリクエストを目指しましょう。

コメントが不要な良いメソッドを設計ために、 まずなにより重要なのは、メソッドに適切な名前を付けることです。 メソッドの中身を実装することより、数倍の時間を名前を考えることに費やします。 我々はよく名前大事と言っています。

では、プルリクエストにおけるメソッド名とは何でしょうか。 それはおそらくブランチ名なのではないでしょうか。 つまり、プルリクエストを作る際に最も気を使うべきところはブランチ名で、 そのプルリクエストが実現する変更を端的に、正確に表さなければなりません。 逆に言うとブランチ名の名付けが上手ければ、レビューも一気に簡単になります。

もちろん、実際にコミットコメントを空にしているわけではありません。 空でコミットすることはできないし、プルリクエストにもタイトルは必要です。 そのため、コミットコメントの1行目(コミットタイトル?)には、ブランチ名と全く同じ文章を入れています。 ブランチ名が1次情報で、コミットタイトルがコピーというスタンスを意識しているということです。

勘違いしてはいけません。 説明しなくていいとは言ってません。 説明の必要がないシンプルなプルリクエストを作れと言っています。