ある本を読んでいたら…バージョン管理システムにおけるソースコードの管理は、機能ベースではなく意味ある単位でコミットしないと管理されているとは言えない。とう趣旨の内容が書いてあって、イマイチよくわからなくなったので調べてみた。普段、Git使っていない人の覚書きなのでズレているかもしれませんが、わりと普遍的な内容にはなっているのではないかと思います。
結論から言えば、
・機能視点ベースでコミットするが、意味のある単位でコミットすることもある。
・意思決定の履歴はマージリクエストとレビューコメントに残す。
・必要に応じて、ドキュメント（ADRなど）に残す。
一般的にソースコードの管理は機能ベースであることが基本だが、その機能の実装が複雑であればあるほど機能内には様々なバージョンが含まれることになる。ソースコードの管理ができているという状態は、例えばどのように実装したとか、どのようなバグを含むかどうかの履歴も、重要なのではないだろうか？
この疑問を更にまとめると『機能が複雑になるほど、実装は段階的・試行錯誤的になる。それを（Gitの場合は） squash や rebase でまとめてしまうと、「どういう思考・設計変更・技術的判断があったのか」が履歴から消え、ソース管理が“成果物だけの管理”になってしまうのではないだろうか』ということになる。実際、Gitの美しい履歴は情報が欠落したり嘘が含まれることもあるのではないだろうか。
※【用語】squah…複数コミットを１つにまとめる（a-b-cをa-dにする）rebase…コミットの並び替え・付け替えをする（コミットを消して新しくコミットを作る）
結論から言えば、Gitは状態を管理するものであってツールの問題ではない↓
Gitのコミットは主に「状態」を管理するものであり、詳細な意思決定の履歴をすべて残すことを目的としたものではない。意思決定の背景や検討過程は、マージリクエストおよびレビューコメント、あるいはADRなどのドキュメントに残す。
ただし、ビルド可能で意味のある中間地点については、同一機能内であっても分割コミットして管理することが望ましい。もし意思決定の履歴がどこにも残っていないのであれば、それはGitの問題ではなく、運用ルールの問題である。
【用語】
ARD…Architecture Decison Record = 「なぜその設計・技術選択をしたのかを残すための公式メモ」設計や構造に影響する判断/後戻りすると高コスト/将来なぜ「こうなのか？」と疑問に思う人がいた場合の回答、を明記するもの
なお、GitやADRで管理されるものは組織的なメモであり、管理個人レベルのメモ書きは組織的なマネジメントにおいては個人で管理する。
まとめ
ツールという視点からこの問題について１文でまとめると、
GIT「何が入ったか」MR「どう決めたか」ADR「なぜ選んだか」をそれぞれ管理するものだ。
ということになる。
※ちなみに、GITはツールで、MR（マージリクエスト）はGitHub/GitLabのコミュニケーション機能で、ADRはドキュメントの役割名称です。
コメント