【ITニュース解説】Git Bits: The Graph

Gitは、ソフトウェア開発における変更履歴を管理するための強力なツールだが、その仕組みの核となるのは「グラフ」という考え方だ。このグラフは、有向非巡回グラフ（DAG: Directed Acyclic Graph）と呼ばれ、Gitリポジトリ内のすべてのコミット間の関係性を視覚的に表現するものだ。

具体的には、Gitにおける各コミットは、このグラフ上の「ノード」として扱われる。そして、それぞれのコミットは、その前に作成された一つまたは複数のコミット、つまり「親」のコミットを「知っている」（参照している）関係にある。この参照はグラフ上の「エッジ」となり、時間の流れに沿ってコミットの履歴をたどることができるようになっている。過去から現在へ向かう一方向のつながりであるため、履歴を逆方向にたどることはできないし、ループ（循環）も存在しない。ただし、二つのノード（コミット）の間には複数の異なるパスが存在する可能性もある。

グラフ上に現れるノードは主に二つのタイプがある。一つは通常の「コミット」で、これはコードの変更を記録したスナップショットを表す。もう一つは「マージ」コミットだ。通常のコミットが一つの親を持つことが多いのに対し、マージコミットは複数の親を持つ。例えば、ある機能開発用のブランチで行われた変更をメインの開発ライン（例えばdevelopブランチ）に統合する際に作成されるコミットがこれにあたる。このマージコミットは、統合元となった複数のブランチの最終コミットを親として指し示すため、二つ以上の親を持つことになる。非常に稀なケースだが、「オクパス・マージ」と呼ばれる三つ以上の親を持つマージも理論上は可能だ。

Gitのブランチシステムは「軽量ブランチ」と称されることがある。これは、他のバージョン管理システムが新しいブランチを作成する際に、プロジェクト全体の完全なコピーを作成するのに対し、Gitのブランチはグラフ上の特定のコミットを指し示す「ポインタ」に過ぎないためだ。つまり、新しいブランチを作成する操作は、実質的に新しいポインタを作成するだけであり、非常に高速に行われる。例えば、mainブランチで一つコミットを作成した後、git branch developコマンドでdevelopブランチを作成すると、git logで確認できる履歴には、同じコミットがmainとdevelopの両方から指されていることが示される。これは、ブランチがリポジトリの内容をコピーするのではなく、コミットに関する「メタデータ」、つまり付随情報であることを意味している。

ブランチは、そのブランチのすべてのコミットを追跡しているわけではない。ブランチが把握しているのは、そのブランチにおける最新のコミットだけだ。なぜなら、その最新コミットが、その一つ前のコミットを、さらにそのコミットがその前のコミットを知っている、という連鎖によって、ブランチ全体の履歴を遡って構築できるからだ。これにより、例えばdevelopブランチがmainブランチとどこで共通の祖先コミットを持っていたか（つまり、どこで分岐したか）を簡単に特定できる。

ここで一つ重要なのは、Gitのグラフにおいて、時間は必ずしも不可欠な要素ではないという点だ。コミットにはタイムスタンプが付与されているが、グラフが本質的に関心を抱いているのは、コミット間の「方向性」と「関係性」である。人間が履歴を理解しやすくするために時間順序で考えるが、グラフそのものは時間にとらわれない構造を持っている。

Gitが最も関心を持つ「時間」は、「今」だ。Gitはこの「今いる場所」をHEADという値で表現する。HEADは現在チェックアウトしているブランチ、あるいは特定のコミットを指すポインタである。例えば、HEADがmainブランチを指している状態でgit checkout developを実行すると、HEADの指し示す先はdevelopブランチに切り替わる。これは、リポジトリのファイル内容は変わらない場合でも、HEADがどこを指すかが変わることで、Gitが今どの作業ライン上にいるかを認識する仕組みだ。さらにgit checkout HEAD~1のようにコマンドを使うことで、HEADの指すコミットから一つ前のコミットへ移動することも可能だ。

このグラフは、一度作成されたら永遠に変わらないものではない。Gitでは、過去の履歴を「書き換える」いくつかの方法が存在する。しかし、履歴の書き換えには注意が必要だ。特に、複数の開発者で共有されているブランチの履歴を書き換えると、それぞれの開発者の持つ履歴が食い違い、まるでコードの「タイムライン」が複数存在するかのような混乱が生じるリスクがある。これは、開発者にとって悪夢のような状況を引き起こす可能性がある。しかし、個人的な作業ブランチ内であれば、履歴の書き換えは非常に有用だ。例えば、git commit --amendコマンドを使えば、直前のコミットの内容やメッセージを修正し、まるで最初から間違っていなかったかのような履歴を作成できる。これは、些細な誤りを修正するのに役立ち、コミット履歴をきれいに保つことができる。

履歴を書き換えるもう一つの強力な方法が「リベース」だ。リベースは、「自分のブランチの開始地点を移動する」操作と説明されることが多い。これは、複数の開発者が並行して同じブランチやリポジトリに変更を加えていくような状況でよく使われる。他の開発者の変更がメインブランチに統合された後、自分の作業ブランチにもその変更を取り込みたい場合、選択肢がいくつかある。一つはgit merge mainを実行してマージコミットを作成する方法だ。これは、履歴に元の分岐とマージの事実を残す。しかし、もし自分の作業ブランチが個人的なものであれば、git rebase mainを使うことで「よりきれいな」履歴を作成できる。リベースは、自分のコミットをメインブランチの最新コミットの「上」に再適用することで、あたかも最初からメインブランチの最新状態から作業を開始したかのように履歴を一直線にする。これにより、履歴に余計な分岐点やマージコミットが残らず、シンプルで追いやすい履歴が形成される。リベースは、グラフの一部を切り離し、別の場所に再接続するような操作と理解できる。

まとめると、Gitはコミットというコードのスナップショットをノードとし、親への参照をエッジとする有向グラフを中心に構成されている。ブランチやタグは、このグラフ上の特定のコミットを指し示すメタデータであり、開発者はこれらの情報を活用してコードの変更履歴を管理する。そして、このグラフは、必要に応じてコミットを追加したり、その関係性を変更したり、さらには一部を移動させたりすることも可能なのである。