gitのコンフリクト解決したときのコミットにはどのような情報が含まれているのでしょうか？

Question

以下のような事例について質問です

---

・masterのコミット
A - B - C - D
・topicのコミット
A - B - E - F

topicをmasterへマージするためにPullRequestを送ろうとしたところ、Github上でコンフリクトが発生していることがわかりました。

masterへマージする権限がないため、topicブランチにmasterをマージし、コンフリクトを解決させました。

・topicのコミット
A - B - E - F - C - D - G
（Gはマージコミット)

Github上でコンフリクトは無いと判定され、無事マージすることができました。

---

このとき、topicでmasterをマージし、コンフリクトを解決したコミット G にはどのような情報が含まれているのでしょうか？
私の予想では「masterのコミットDまでの競合を解決した」といった情報が保存されているのかなと推測しています。

Answer 1

こんにちは。

gitの内部の話をします。
gitのコミットは、「差分情報」を一切保持していません。もう少し具体的に言うと、コミットオブジェクトは、コミッター名、作成日時、コミットメッセージ、コミット時のインデックスツリーオブジェクトへの参照(ツリーオブジェクトは各ファイルオブジェクトへの参照を持ちます)、そして、親コミットのID、を固めたものです。gitそれ自体はとてもシンプルなオブジェクトツリーデータベースであり、コミットの差分情報というのは「画面に表示する時に」自分のツリーのファイルと親コミットの持つツリーのファイル同士を比較して作成されているのです。
よって、マージコミットが持つのは「コミットの各種メタデータ」、「マージコミット時点のインデックスツリーへの参照」「二つ(以上)の親コミットのID」となります。
仮にマージする段階でコンフリクトを解消する編集を加えたとして、それは「編集された後のファイル」がマージコミットのインデックスツリーに含まれるだけなので、マージがどのようにコンフリクトして、どのように解消したかという情報は失われます。「マージする前の二つのインデックス(ディレクトリ)の状態」と、「マージが完了した時点のインデックスの状態」があれば、バージョン管理には十分なのです。

---

githubでコミットログを表示すると、マージ含め直線的に表示されてしまいますが、マージは実際にはツリー構造になっています。ローカルでCUIからgit log --graphや、またはSourceTreeなどを使うと視覚化できるので、理解の助けになると思います。

Comments

[jimyo]

ありがとうございます。
知りたいことが完全にわかりました！

以下、本質問と少し離れてしまうのですが気になったのでよろしかったら教えてください。

>コミットの差分情報というのは「画面に表示する時に」自分のツリーのファイルと親コミットの持つツリーのファイル同士を比較して作成されているのです。

これはつまりある1つのファイルを変更してコミットするたびにそのファイルのコピーのようなものができるということでしょうか？
もしそうならファイル数が爆発的に増えてGithubのようなサービスはすぐ破綻してしまう気がするのですが……

[tamoto]

コメントに回答します。
その通りです。ファイルに変更を加えれば、その回数だけファイルオブジェクトが生成されます。gitが大容量(目安として、10MB～)の単一ファイルの取り扱いを苦手としているのはそれが理由です。しかし、各gitオブジェクトは生成される時点で圧縮が掛かっており、ソースコード程度のファイルサイズであればそこまで容量は大きくならないため、運用に支障が出るほどのリポジトリは稀です。現に、linuxカーネルのソースコードを管理することができる程度には動きます。
githubの運用状況は流石に分かりませんが、殆どのリポジトリは数100kbから数10MB程度に収まるので、リポジトリのサイズ上限などを設けておけば、運用が破綻することはないでしょう。自リポジトリの.gitディレクトリのサイズを確認してみてください。それこそがgitリポジトリのサイズです。
そして、gitでも大容量のファイルを取り扱いたいという要望もあり、gitシステム上ではファイルポインタのみを取り扱い、その実体は別のサーバに配置するという「git-lfs」というソリューションが存在します。また、Microsoftがgitで運用するには辛いほどの規模のリポジトリを効率的に取り扱うための「GVFS - Git Virtual File System」というソリューションを開発していたりもします。

Answer 2

topicブランチのコミットグラフは質問主さんが書かれているような一直線のものではなく、以下のような形で残されています。
git log --graph --pretty=oneline topicやgitk topicコマンドで確認してみてください。

A ─ B ┬ E ─ F ─────┬─ G 
       │                  │
       └───── C ─ D ┘

コミットGには「コミットFとコミットDが、その親である」という情報が含まれています。
コミットDを親に持つことから、masterブランチのコミットDまでがマージ済みだと判断できます。