Gitの内部データ構造をGraphvizで描画してみた 第2回 ブランチとマージ
解決すべき問題
一年前のこと、Subversionを長く使ってきた開発チームにGitを教えようとした。わたしはGitのブランチをちゃんと説明したかった。というのもSubversionにもブランチという用語があるが、GitのブランチはSubversionとは似て非なるものだからだ。"Git"と"Subversion"と"ブランチ"をキーにネットを検索すると解説記事がたくさんみつかった。だがわたしが同僚諸君に説明するのに使えるようなひと目で理解できる記事が見当たらなかった。
いま自分の手元にあるプロジェクトの.gitディレクトリのなかにあるGitレポジトリの実物を読み出して図にしてくれる、そういうツールがほしい。
解決方法
Pythonでツール kazurayam/visualize_git_repository.py を開発した。これを使えばいま自分の手元にあるプロジェクトの .git ディレクトリのなかにあるオブジェクト群の実物を読み出し、Graphvizでグラフを生成してPNG画像ファイルを出力することができる。
説明
デモ用にディレクトリを作りGitレポジトリを作ろう。masterブランチとdevelopブランチでファイルを追加・変更などして、developをmasterにマージしよう。Gitレポジトリのなかがどんなふうに形を変化させていくか、図を示しつつ、説明しよう。
ステップ1 最初のコミット
新しいGitレポジトリを作ろう。いくつかファイルを作ってコミットしよう。
作業用ディレクトリを作った
git initしたファイルを３つ作った。
README.md、.gitignore、src/greeting.plを。git add .したgit commit -m "initial commit'した
この時点でvisualize_git_repositoryツールを実行したら次のグラフが生成された。
| master | develop |
|---|---|
 |
まだ無い |
このグラフから次のことが読みとれる。
git initするとmasterという参照名が自動的に作られる。Gitにおいてブランチとはひとつのcommitオブジェクトを指す別名にすぎない。上記の図で参照名
masterはinitial commitというコメントを含むひとつのcommitオブジェクトを指す別名にすぎない。Gitには
HEADという名前の参照名が組み込みで定義されている。HEADもやはりひとつのcommitオブジェクトを指す。上記の図でHEADは参照名masterを指しているが、masterがcommitオブジェクトを指すので、けっきょくHEADもmasterを介して間接的にひとつのcommitオブジェクトを指すと解釈することができる。HEADは特殊な参照名だ。さまざまのgit xxxコマンドを実行した副作用としてHEADが指すモノが切り替わる。参照名
HEADが参照名masterを指しているという状態を「カレント・ブランチがmasterである」と表現することもある。この言い方のほうが日本語としてすなおなので多用するだろう。以下で「カレント・ブランチが...」という文がでてきたら、参照名HEADから伸びた矢印 → が何を指しているかを思い浮かべてほしい。
ステップ2 developブランチを作る
新しいブランチ develop を追加しよう。
- カレント・ブランチがmasterである状態で
git branch developコマンドを実行した
この時点でvisualize_git_repositoryツールを実行したら次のグラフが生成された。
| master | develop |
|---|---|
| 前と同じ |  |
このグラフから次のことが読みとれる。
新しい参照名
developが作られた。参照名
developはinitial commitというコメントを含む
commitオブジェクト すなわちmasterが指していたのと同じcommitオブジェクトを指している。参照名
HEADが参照名developを指すかたちに変更された。別の言い方をすると カレント・ブランチがmasterからdevelopに切り替えられた。カレント・ブランチが
developに切り替えられた後でも参照名masterはGitレポジトリのなかに存続している。上の図ではmasterの図を省略したがそれは図をシンプルにして見やすくするためであって、消えてなくなったわけではない。
ステップ3 developでコミットする
developブランチで新しいファイルを追加してコミットしよう。
ワーキングツリーで新しいファイル
doc/TODO.txtを追加したカレント・ブランチが
developであることをたしかめてgit add .を実行したgit commit -m "add doc/TXT.txt"を実行した
この時点でvisualize_git_repositoryツールを実行したら次のグラフが生成された。
| master | develop |
|---|---|
| 前と同じ |  |
このグラフから次のことが読みとれる。
新しいcommitオブジェクトができた。新しいcommitオブジェクトが親commitにリンクする形になり、commitオブジェクトの鎖がひとつ伸びた。新しいcommitオブジェクトはルートディレクトリ
/を指すtreeオブジェクトにリンクしている。treeのなかにはdoc/TODO.txtファイルのblobオブジェクトがある。つまり追加したファイルがちゃんと認識されている。参照名
developすなわちdevelopブランチがどのcommitオブジェクトを指しているか？を見ると自動的に更新されたのがわかる。ブランチ名はcommitオブジェクトの鎖の端っこ(ゴーヤの蔓の成長点のようなところ)を指すようにgitによって自動的に更新されるのだ。
ステップ4 masterブランチに戻る
ファイル README.md を修正してコミットする前に、masterブランチに戻ろう。
-
git checkout masterを実行した
この時点でvisualize_git_repositoryツールを実行したら次のグラフが生成された。
| master | develop |
|---|---|
 |
前と同じ |
このグラフから次のことが読みとれる。
参照名
HEADが参照名masterを指すように更新された。すなわちカレント・ブランチがmasterに切り替わった。masterブランチの中身は1回目のcommitをした時のままで変わっていない。
カレント・ブランチが
masterに切り替えられた後でも参照名developはGitレポジトリのなかに存続している。上の図ではdevelopの図を省略したがそれは図をシンプルにして見やすくするためであって、消えてなくなったわけではない。
ステップ5 masterでコミットする
masterブランチで既存のREADME.mdファイルを変更してコミットしよう。
git branch --show-currentとやってカレント・ブランチがmasterであることを確かめたecho "#Read me carefully" > README.mdとやってファイルを更新したgit add .したgit commit -m "modified README.md"とやった
この時点でvisualize_git_repositoryツールを実行したら次のグラフが生成された。
| master | develop |
|---|---|
 |
前と同じ |
このグラフから次のことが読みとれる。
- 新しいcommitオブジェクトができた。新しいcommitオブジェクトが指すtreeのなかにある
README.mdファイルのblobをみるとhash値が変わっている。つまり変更されたREADME.mdファイルのために新しいblobオブジェクトがひとつ生成されて、そのhash値をcommitが参照している。これこそが「変更後のREADME.mdファイルがレポジトリにコミットされた」という表現の意味するところだ。 - 参照名
masterが新しいcommitオブジェクトを指すように更新された。
ステップ6 developをmasterにマージする
developブランチをmasterブランチにマージしよう。すなわちdevelopブランチで行ったファイルの追加・変更・削除をmasterブランチにとり込もう。
git branch --show-currentとやってカレント・ブランチがmasterであることを確かめたgit merge developとやった
この時点でvisualize_git_repositoryツールを実行したら次のグラフが生成された。
| master | develop |
|---|---|
 |
前と同じ |
このグラフから次のことが読みとれる。
マージする前にmasterブランチにはcommitオブジェクトが2個あった。マージした後にmasterブランチにcommitオブジェクトが4個ある。2個増えた。
増えた2個のcommitオブジェクトうちひとつは
developブランチで作られたものだ。add doc/TODO.txtというコミットメッセージをもっている。developブランチだけで見えていたcommitオブジェクトがgit merge developコマンドによってmasterブランチでも見えるようになった。増えた2個のcommitオブジェクトのうち残るひとつは新しく
masterブランチに追加されたものだ。このcommitオブジェクトは親(parent)コミットを2つ持っている点が特徴的だ。これをマージコミットともいう。マージコミットの親コミット2つとはカレント・ブランチの先端にあったcommitオブジェクトと、マージされたブランチの先端にあったcommitオブジェクトである。マージコミットによってコミットの履歴2本が合流する。マージコミットより古い履歴は2本のまま残されて、マージコミットからあとは1本の履歴が始まる。
参照名
masterはマージコミットを指すように自動的に更新された。マージコミットは普通のcommitオブジェクトと同様にルートディレクトリ
/に対応するtreeオブジェクトへの参照をもっている。そのtreeオブジェクトを起点としてすべてのファイルのblobオブジェクトを参照することができる。それらblobはmasterブランチとdevelopブランチにおいてこれまでに追加・変更・削除されたファイルの最新状態が反映されている。上の図ではマージコミットが指しているtreeオブジェクトだけを描き、時系列的に古いcommitオブジェクトが指しているtreeオブジェクトを省略した。これは図を簡素化するためだ。treeオブジェクトがGitレポジトリから消えて無くなったわけではない。
ツールについて
本稿で示したPNG画像は自作のツール visualize_git_repository で描画した。このツールはPython言語で開発した。ソースコードは下記のGitHubレポジトリにある。
このツールは下記2つのライブラリを利用している。
PNG画像を生成するにはコマンドラインで下記の操作をする。
$ cd $visualize_git_repository
$ pytest -s kazurayam/visualize_git_repository.py::test_2_branch_and_mearge
上記の例を作るのにどういうgitコマンドを実行したのかを知りたいならプログラムのソースコードを読み解いてください。下記を入り口として解読してください。
まとめ
一年前の同僚諸君に本稿を読んでもらいたいなあ。これならGitのブランチとマージが理解できるだろうと思うのだが、どうだろうか？
- author: kazurayam
- date: June, 2021
連作の目次
Author And Source
この問題について(Gitの内部データ構造をGraphvizで描画してみた 第2回 ブランチとマージ), 我々は、より多くの情報をここで見つけました https://qiita.com/kazurayam/items/18419085764ff1d81406著者帰属：元の著者の情報は、元のURLに含まれています。著作権は原作者に属する。
Content is automatically searched and collected through network algorithms . If there is a violation . Please contact us . We will adjust (correct author information ,or delete content ) as soon as possible .