こんにちは。私はここヴィテイのプログラマー、ダニーです。 今日は「git入門」ということで、gitの使い方とかを勉強していますが、 せっかくだからgitの内側や実装を説明させていただきたいと思います。

これは、gitを使うのに本当は覚える必要はないけど、 面白いし、何か変なこと起こったらその原因を調べるのに役に立つと思います。

一つお願いがあります。これからの話はちょっと技術的だし、 私は日本語は母国語ではないので、 「意味分からない！」と思うときは是非質問してください。 我慢しないでください！

追跡　ついせき

まず、gitとは、いったい何か？と考えたらいいと思います。 gitのマニュアルを見るとこういう風に書いている：「おバカなソース追跡ツール」。 この定義が好きです。 「stupid」とは「バカ」という意味ですけど、ある意味「simple」ですね。 gitは最もシンプルなシステムであり、 そのシステムを上手く使うことはあなた達ユーザーの責任だよ！というスタンスで作られています。

でもgitを考えるとどいう特徴があるでしょうか？

その上にVCSが作られていますけど、gitの中核（ちゅうかく）はこの連想記憶ファイルシステムです。 ...とは言っても、連想記憶ファイルシステムって何でしょう？

連想記憶　れんそうきおく 表す　　　あらわす

First Row: Figure out how to say "one-to-one mapping" so I can explain this better. gitの場合はSHA1というアルゴリズムで名前が決まっているので、 「名前」ではなく「SHA1」とはよく言われています　（例：コミットのSHA1、ファイルのSHA1）

Second Row: 元のデータが残るので、不変的なファイルシステムとも言えます

Third Row: 連想記憶ファイルシステムではヒエラルキーは必要なくなります。 同じ名前で違うデータを入れることができないからです。

Example: Traditional

        $ cd fs
        $ mkdir foo bar
        $ echo foo > foo/hoge
        $ ls -l foo            #See there is a file called 'hoge'
        $ cat foo/hoge         #See the contents of the file is 'foo'
        $ echo bar > bar/hoge
        $ ls -l bar
        $ cat bar/hoge
        $ tree
        $ echo baz >> foo/hoge
        $ cat foo/hoge         #Now says "foobaz"; no way to restore the original
        $ cat bar/hoge
        

Example: Content-Addressable

        $ cd cafs
        $ git init             #We will be using git as our content-addressable fs
        $ git count-objects    #There are no objects
        $ echo foo | git hash-object -w --stdin
        $ git count-objects    #Now there is one object!
        $ git cat-file -p 257cc5642cb1a054f08cc83f2d943e56fd3ebe99
        $ git cat-file -p 257c #As the number of objects increase you might need more characters...
        $ echo bar | git hash-object -w --stdin
        $ git count-objects    #Now there are two objects!
        $ git cat-file -p 5716
        $ echo `git cat-file -p 257c`baz | git hash-object -w --stdin
        $ git cat-file -p 9dab
        $ git count-objects    #Now there are three objects!
        $ find .git/objects -type f
        

ただ、本当にこれだけだったらVCSとして使えないので、 gitはレイヤーで作られています。 一番したのレイヤーは連想記憶ファイルシステムであり、 その上に何が必要でしょうか？

それは、gitのオブジェクトモデルということです。

導く　みちびく

• コミットするための準備エリア
• 作業フォルダーのキャッシュ
• データ自体は入っていない。git addをするとき、ブロブを作られる。そのブロブのidをindexに入れられる。
• gitの速度はindexによってだいぶ変わるので、最適化のために何回も変わっています。現在使われているバージョンは２、３、４（？）
• 最初からgitの大事な部分でした。ツリーを読み込むときも、書き出すときも、現在作業フォルダーから直接作ることではなく、indexから作られています。
• 作業フォルダーが全部なくなっても、indexから取り戻すことができます。

gitの基本データはこれぐらいですが、まだちょっと不便なことがあります。 それは、idからデータを取得することです。確かに、ツリーを持っていたらファイル名で取得できますが、 そのツリーはどうやって取得できるでしょうか？ コミットを持っていたらツリーを取れるけど、そのコミットは？ gitのストラクチャーを導かれる（？）ために、次のレイヤーが必要です。

        # OK, some examples of how to do "normal git stuff" with just the original 7 commands!
        $ cd cmds

        # Initialise git.  This is synonymous with `git init`
        $ git init-db
        $ find .git/objects -type f

        # Let's create some content and add it to the staging area
        $ vim README.md # Write some stuff
        $ git update-index --add README.md

        # The blob file is made automatically when you add it to the index
        $ find .git/objects -type f
        $ find .git/objects -type f | awk -F'/' '{ print $3$4 }' | while read o; do echo $o $(git cat-file -t $o); done

        # We need to make a tree, though...
        $ git write-tree
        $ find .git/objects -type f | awk -F'/' '{ print $3$4 }' | while read o; do echo $o $(git cat-file -t $o); done
        $ git cat-file -p (SHA1)

        # OK, now we actually want to take a tree and make it into a commit object
        $ git commit-tree (SHA1) -m "Initial commit"
        $ git cat-file -p (SHA1)
        $ find .git/objects -type f | awk -F'/' '{ print $3$4 }' | while read o; do echo $o $(git cat-file -t $o); done

        # Let's cheat a bit and use the log to see if it worked
        $ git log

        # bad default revision 'HEAD'? What's that all about?
        $ tree .git

        # There's a file called head in there, what's in that?
        $ cat .git/HEAD

        # OK, but there aren't any refs... let's try just putting tha sha1 in that filename
        $ echo (SHA1) > .git/refs/heads/master
        $ git log

        # Awesome! It works.  Let's make a change.
        $ vim README.md #Change something
        $ git diff-files

        # What does that all mean? Left-to-right:
        #   permissions(src)
        #   permissions(dst)
        #   blob-sha1(src)
        #   blob-sha1(dst)
        #   status (added, removed, modified, etc)
        #   filename
        # The dest blob is 000.. because it hasn't yet been added to the index!
        $ git update-index README.md
        $ git diff-files
        $ find .git/objects -type f | awk -F'/' '{ print $3$4 }' | while read o; do echo $o $(git cat-file -t $o); done
        $ git write-tree

        # This time we want to write our commit message in a proper text editor
        $ vim .git/COMMIT_EDITMSG #Write it
        $ git commit-tree (SHA1) -p (LAST_SHA1) -F .git/COMMIT_EDITMSG
        $ git log # Master hasn't been updated!

        # OK, so commit-tree doesn't update any refs because refs exist in a
        # layer above these seven commands.  But we can easily update it
        # automatically...
        $ vim README.md # Change it
        $ git update-index README.md
        $ vim .git/COMMIT_EDITMSG
        $ git commit-tree $(git write-tree) -p (LAST_SHA1) -F .git/COMMIT_EDITMSG > .git/refs/heads/master

        # Hmm, wouldn't it be easier to wrap this process up into a script?
        $ vim git-commit
            #!/bin/bash

            TREE=$(git write-tree)
            HEAD=$(cat .git/refs/heads/master)

            echo "" > .git/COMMIT_EDITMSG
            vim .git/COMMIT_EDITMSG
            git commit-tree $TREE -p $HEAD -F .git/COMMIT_EDITMSG > .git/refs/heads/master

        $ chmod +x git-commit
        $ git update-index --add git-commit
        $ ./git-commit
        $ git log