gittutorial-2(7) Manual Page

このGit入門パート2を読む前に、 gittutorial(7) (Git入門)を読んで下さい。

この入門の目的は、Gitのアーキテクチャの2つの基本的な部分(オブジェクトデータベースとインデックスファイル)を紹介し、残りのGit文書を理解するために必要なすべてのものを読者に提供することです。

新しいプロジェクトを開始して、履歴を少々作成しましょう:

さて、ここで、Gitがコミットで返してきた7桁の16進数(訳注: 54196cc とか c4d59f3)は一体何でしょうか？

入門のパート1で、コミットには名前が付いていることがわかりました。Git履歴内のすべてのオブジェクトは、40桁の16進名で保存されていることがわかりました。その名前は、オブジェクトの内容のSHA-1ハッシュです。特に、これにより、Gitが同じデータを2回保存することはなく(同一のデータには同一のSHA-1名が付けられるため)、Gitオブジェクトの内容が変更されることはありません(オブジェクトの名前も変更されるため)。ここでの7文字の16進文字列は、このような40文字の長さの文字列の略語です。 略語は、明確である限り(訳注:その環境で一意になる限り)、40文字の16進文字列を使用できるすべての場所で使用できます。

上記の例に従って作成したコミットオブジェクトのコンテンツは、コミットオブジェクトが作成された時刻とコミットを実行した人の名前を記録するため、上記とは異なるSHA-1ハッシュを生成することが期待されます。

cat-file コマンドを使用して、 この特定のオブジェクトについてGitに問い合わせることができます。 上記の例から40桁の16進数をコピペするのではなく、 あなた自身が実行したバージョンの16進数を使用してください。 40桁すべての16進数を入力する手間を省くために、数文字に短縮できることに注目です:

ツリーは、それぞれがファイルに対応する、1つ以上のブロブ(blob)オブジェクトを参照できます。さらに、ツリーは他のツリーオブジェクトを参照することもできるため、ディレクトリ階層が作成されます。 ls-tree を使用して任意のツリーの内容を調べることができます(その際、SHA-1の最初の部分を指定するだけで十分なことを忘れないでください)。

これで、このツリーには1つのファイルが含まれていることがわかります。SHA-1ハッシュは、そのファイルのデータへの参照(reference)です:

「blob」は単なるファイルデータであり、cat-fileで調べることもできます:

注意: これは古いファイルデータであることに注意してください。つまり、Gitが最初のツリーに対する応答で名付けたオブジェクトは、最初のコミットで記録されたディレクトリ状態のスナップショットを持つツリーです。

これらのオブジェクトはすべて、Gitディレクトリ内部にSHA-1名で保存されます:

そして、これらのファイルの内容は、圧縮されたデータに加えて、ファイルの長さとタイプを識別するヘッダーだけです。 タイプは、blob、tree、commit、tag のいずれかです。

見つけるのが最も簡単なコミットはHEADコミットで、これは .git/HEAD から見つけることができます:

ご覧のとおり、これにより、現在どのブランチを使用しているかがわかります。 .git ディレクトリの下にあるファイルに名前を付ける事でこれを私達に知らせます。このディレクトリ自体には、コミットオブジェクトを参照するSHA-1名が含まれていて、 cat-file で調べることができます:

ここでの「tree」オブジェクトは、ツリーの新しい状態を指します:

そして「parent」(親)オブジェクトは前のコミットを参照します:

このツリー・オブジェクトは最初に調べたツリーであり、 このコミットには親がないという点でレアです。

多くのコミットでは親が1つしかないですが、 複数の親を持つコミットも割とあります。 その場合、コミットはマージを表し、 親参照はマージされたブランチのヘッドを指します。

ブロブ(blob)とツリー(tree)とコミット(commit)以外に残っているオブジェクトのタイプは「タグ」(tag)だけです。これについてはここでは説明しません。 詳細については、 git-tag(1) を参照してください。

これで、Gitがオブジェクトデータベースを使用してプロジェクトの履歴を表す方法がわかりました:

なお、 多くのコマンドがツリーを引数として受け取ります。 しかし、 上記でわかるように、 ツリーはさまざまな方法で参照できます。 ツリーの SHA-1 名や、 ツリーを参照するコミットの名前や、 ツリーを参照するブランチのヘッドの名前などです。 そして、 ほとんどのそのようなコマンドはこれらのいずれかを受け入れることができます。

コマンドの概要では、「tree-ish」(ツリーっぽい)という単語がそのような引数を示すために使用されることがあります。

コミットを作成するために使用している主なツールは git-commit -a です。これは、作業ツリーに加えたすべての変更を含むコミットを作成します。しかし、特定のファイルの変更のみをコミットしたい場合はどうでしょうか？ または、特定のファイルの特定(一部の)の変更のみをコミットしたい場合はどうでしょうか？

コミット作成の秘密を知れば、 コミットを作成する、 より柔軟な方法があることがわかります。

我々のテストプロジェクトを続けて、file.txt を再び変更しましょう:

しかし、 今回は直ちにコミットするのではなく、 中間のステップを踏んで、 何が起こっているかを追跡するために、 以下のように途中で diff を要求しましょう:

ここで、 最後の git diff の結果は空です。 しかし、 これは、 まだ新しいコミットは行われておらず、 ヘッドにはまだ新しい行が含まれていないからです:

そうです、 git diff は(作業ツリーを)ヘッド以外の何かと比較しています。 比較しているのは、 実際にはインデックス・ファイルです。 これはバイナリ形式で .git/index に保存されていますが、 その内容は ls-files で調べることができます:

つまり、 「git add」が行ったことは、 新しいブロブを格納し、 それへの参照をインデックス・ファイルに配置することでした。 ファイルを再度変更すると、 新しい変更が「git diff」出力に反映されていることがわかります:

適切な引数を使用すると、 git diff は、 以下のように、 作業ディレクトリと最後のコミットの違いや、 インデックスと最後のコミットの違いを示すこともできます:

あなたは、 以下のようにして、 いつでも git commit ( -a オプションなし)を使用して新しいコミットを作成することができ、 コミットされた状態にはインデックス・ファイルに保存されている変更のみが含まれ、 作業ツリーにのみ残っている追加の変更が含まれてい無いことを確認できます:

つまり、 デフォルトでは、 git commit は作業ツリーではなくインデックスを使用してコミットを作成します。 コミット時に -a オプションを指定すると、 まず作業ツリーのすべての変更をインデックスに反映します。

最後に、 インデックス・ファイルに対する git add の効果を確認しておきましょう:

git add の効果は、 以下のようにインデックス・ファイルに1つのエントリを追加することでした:

そして、 以下の cat-file でわかるように、 この新しいエントリはファイルの現在の内容を参照しています:

「status」コマンドは、状況の概要をすばやく取得するための便利な方法です:

closeing.txtの現在の状態はインデックスファイルにキャッシュされているため、「コミット予定の変更点」(Changes to be committed)としてリストされます。 file.txtには、インデックスに反映されていない作業ディレクトリの変更があるため、「Changes not staged for commit」とマークされています。 この時点で、「git commit」を実行すると、（新しいコンテンツを含む)closeing.txtが追加されたコミットが作成されますが、file.txtは変更されませんでした。

また、裸の git diff はfile.txtへの変更を示しますが、closeing.txtの追加は示しません。これは、インデックスファイルのcloseing.txtのバージョンが作業ディレクトリのバージョンと同じであるためです。

インデックスファイルは、新しいコミットのステージング領域であることに加えて、ブランチをチェックアウトするときにオブジェクトデータベースからも入力され、マージ操作に関係するツリーを保持するためにも使用されます。詳細については、 gitcore-tutorial(7) および関連するマニュアルページを参照してください。

この時点で、 あなたは任意の Git コマンドのマニュアルページを読むために必要な知識はすべて身についているはずです。 その良い出発点は giteveryday(7) で紹介されているコマンドから始めることです。 あなたが知らない専門用語は gitglossary(7) で調べる事もできます。

Git User’s Manual は、Gitのより包括的な紹介を提供します。

gitcvs-migration(7) は、CVSリポジトリをGitにインポートする方法を説明し、CVSのような方法でGitを使用する方法を示しています。

Gitの使用に関する興味深い例については、 howtos を参照してください。

Git開発者向けに、 gitcore-tutorial(7) で、新しいコミットの作成などに関連する低レベルのGitメカニズムについて詳しく説明しています。

gittutorial(7), gitcvs-migration(7), gitcore-tutorial(7), gitglossary(7), git-help(1), giteveryday(7), The Git User’s Manual

Part of the git(1) suite