gittutorial-2(7) Manual Page

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

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

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

さて、ここで、Gitがコミットで返してきた7桁の16進数は一体何でしょうか？

入門のパート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」オブジェクトは、ツリーの新しい状態を指します:

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

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

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

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

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

注意: ちなみに、多くのコマンドは引数としてツリーを使用することに注意してください。 しかし、上で見ることができるように、ツリーは多くの異なる方法(そのツリーのSHA-1名、そのツリーを参照するコミットの名前、そのツリーを参照するヘッドを持つブランチの名前など)で参照できます。そのツリーのSHA-1名、ツリーを参照するコミットの名前、ヘッドが参照するブランチの名前 そのツリーなどに-そしてそのようなコマンドのほとんどはこれらの名前のいずれかを受け入れることができます。

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

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

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

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

しかし、今回はすぐにコミットするのではなく、中間のステップを踏んで、何が起こっているかを追跡するために途中で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コマンドのマニュアルページを読むために必要なすべてを知っている必要があります。それを始めるのに適した場所の1つは、 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