視覚から理解するGit

視覚から理解するGit

1. 視覚から理解するGit

こんにちは、最近入社したymizushiです。
Gitはバージョン管理システムのデファクトスタンダードになったと言っていいと思いますが、
Subversionとは内部構造が違うのに、コマンドラインからは中途半端に似たようなインターフェースになっているため、
Gitを使っているけど実はよくわかっていないという方も多いと思います。

でもGitの基本的な構造自体は驚くほどシンプルで、
普通に使うだけなら下の図を見て理解するだけで大丈夫だと思います。

git

(クリックで拡大します)

この図はGitの基本構成を本家GitのDocumentationを参考に、
自分なりにわかりやすく図にしてみたものです。

これから実際のコマンドラインを通して、
どのコマンドがどのような意味を持ち、
図ではどのような部分にあたるのかを説明していきます。

2. コマンドから理解するGit

これからの説明は、branchに新たに
piyo.clj
foo.clj
bar.clj
というファイルを作成したという前提で進めていきます。

work treeのrootで以下のコマンドを実行します。

この3ファイルが図の「untracked」にあたります。

今度は以下のコマンドをを実行します

この操作によりpiyo.cljのgit addした時点での全ての差分が、
「staged」に取り込まれます。

この状態でpiyo.cljを編集し、git statusを実行すると
以下のような出力がされます。

前回の出力と違う部分は

の部分です。
つまり「not staged」が追加されたようです。

同じファイルなのになぜnew file とmodifiedに分かれたのかと疑問に思った人がいるかもしれませんが、
add して「staged」の状態に変更してから、さらに変更が加えられると、
add してからの差分が「not staged」となります。

つまり、
ブランチから行った変更 = 「stagedの差分」+「not staged」の差分 + 「untracked」
です。

またcommitでは「staged」に反映された変更しかリポジトリに反映出来ないため、
commitされる内容と git diff –cachedで表示される内容は等価です。

3. スナップショットと差分

work treeはbranchからの差分で表現されますが、
gitに取り込まれるのはスナップショット(ファイルのデータそのもの)です。

「staged」での差分をあてた内容がデータとしてblobオブジェクトで作成され、
blobへの参照を持ったtreeと
treeへの参照と親commit(基本的にそのbranchの一つ前のcommit。mergeの際は二つ以上の親を持つ)への参照
を持ったcommitオブジェクトが生成されます。

Gitではcommitごとにこのようなことが行われますが、
commitが持っているtree構造は基本的に普通のファイルシステムとそう変わりがなく、
違うのはblobは不変であるということです。

以上のことさえわかっていれば、
例えば、git reset でどのような情報が失われるのか、
なども自ずとわかってくると思います。

参考

http://git-scm.com/


この記事はあなたの役に立ちましたか?他の人達にも役立ちそうでしたら、上のボタンより共有をお願いします。共有して頂けたら今後提供する記事の参考やモチベーションアップにつながります。

Categorized: git