Git ユーザマニュアル (バージョン 1.5.3 以降用)

このマニュアルを読む際には、実験用のリポジトリを取得しておくと便利です。

実験用リポジトリを取得する一番良い方法は git-clone(1) コマンドを使用し、 既存のリポジトリのコピーをダウンロードすることです。

初めてのclone(複製)では大きなプロジェクトの場合、時間をかなり消費するかもしれませんが、 clone は１回行なうだけで良いです。

clone コマンドはそのプロジェクトにちなんだ新しいディレクトリを作成します (上記例では "git" 又は "linux-2.6")。 このディレクトリ内にはプロジェクトファイルのコピーが存在し (これは 作業ツリー といいます)、 それと一緒に ".git" という特別なトップレベルディレクトリが存在します。 ".git" ディレクトリにはプロジェクトの履歴の全てが含まれています。

git はファイル集合の履歴を格納するツールとして非常によく考えられたツールです。 git は履歴を圧縮した集合として格納し、 プロジェクトの内容を相互に関連したスナップショットとして格納します。 git ではこれらのバージョンを コミット と呼びます。

それらのスナップショットは必ずしもすべてが古いものから最新のものに 単線で並んでいるとは限りません；その代り、開発ラインが並行して 進むことがあります (これは ブランチ といいます)。 ブランチは分岐し統合されます。

１つの git リポジトリは複数のブランチを追跡することができます。 Git は 各ブランチの最新のコミットの参照を ヘッド の 一覧に保管することで複数のブランチを追跡します； git-branch(1) コマンドはブランチの一覧を表示します：

新しく clone したリポジトリは、１つのブランチヘッド(デフォルトではその名前は "master"です) を持っており、作業ディレクトリは、そのブランチ head が参照するプロジェクトの状態で 初期化されています。

多くのプロジェクトは tags も使用しています。 tag は head のようにプロジェクトの履歴を参照していて、 git-tag(1) コマンドを用いてリスト表示できます。

tag は常にプロジェクトの特定のバージョンを指し示し、 head は開発が進むに従い更新されていきます。

あるバージョンを指し示す新しいブランチの head を作成し、 そのブランチの head をチェックアウトするには git-checkout(1) を使用します：

この時、作業ディレクトリは v2.6.13 の tag を付けた時に プロジェクトのもっていた内容が反映されています。 そして、git-branch(1) すると２つのブランチが表示され、 現在チェックアウトしているブランチのマークがアスタリスク(*)で表示されます。

もしバージョン 2.6.17 をむしろ参照したいと考えたなら、 現在のブランチを v2.6.17 を参照するように変更できます。次のようにして：

ある特定の履歴がを参照しているのが、現在のブランチのみの場合、 ブランチをリセットすると、もやはその履歴を参照できなくなることに注意してください； ですから、このコマンドは注意して使用してください。

プロジェクトの全ての変更履歴は、commit として表現されます。 git-show(1) コマンドは現在のブランチ上で最後にコミットした 履歴を表示します：

このように、コミットは誰が最後に変更したか、何を、何故変更したかを表示します。

全てのコミットは 40桁の16進数の ID ("オブジェクト名" 又は "SHA-1 id" と呼ぶこともあります) を持ち、"git show" の出力の１行目にその ID が表示されます。 通常、コミットはタグやブランチ名のような短い名前で参照できますが、 この長い名前も役に立つことがあります。特に重要なのは、この ID がこのコミットを 大局的にユニークにしている点です：つまり、他のだれかにその ID を (例えば emailで)伝えた場合、その ID が彼らのリポジトリ内でもあなたのリポジトリ内でも 同じコミットを指し示すことを保障しています。 (彼らのリポジトリにそのコミットが完全に含まれている場合にはです)。 オブジェクト名はコミット対象のコンテンツのハッシュとして計算される為、 変更しない限りは、決して変わらないことが保障されています。

実際、gitのコンセプト では、git に格納されている全ての履歴が、 ファイルデータとディレクトリの中身も含めて、その中身のハッシュの名前で オブジェクトが格納されていることを見るでしょう。

         o--o--o <-- Branch A
        /
 o--o--o <-- master
        \
         o--o--o <-- Branch B

ブランチの作成/削除/変更はとても簡単です； 以下にコマンドのサマリを載せます：

特別なシンボル "HEAD" 使用すると、常に現在のブランチを参照することができます。 実際 git は .git ディレクトリにある "HEAD" という名前のファイルを使用して 現在のブランチの場所を記憶しています。

git checkout コマンドは通常はブランチヘッドが引数で渡されることを期待していますが、 任意のコミットを指定することもできます；例えば、 タグによって参照されるコミットをチェックアウトすることができます。

この時 HEAD はブランチの代わりにコミットの SHA-1 値を参照しており、 git branch を実行するとブランチにいないことが分かります。

この状態を HEAD が "切り離されている (detached)" と言います。

この方法は、新しいブランチを作成せずに特定のバージョンを チェックアウトする手軽な方法です。 こうした後でも、後からこのバージョンに対して新しいブランチ(またはタグ)を 作成することができます。

複製(clone)した時に作成される "master" ブランチは、 複製元リポジトリのヘッドのコピーです。 しかし複製元リポジトリにはそれ以外にもブランチがあるかもしれません。 ローカルリポジトリは、リモート(複製元)ブランチのそれぞれを追跡する為の ブランチを持っています。 それらのブランチは "-r" オプションを付けて git-branch(1) を実行すると 確認できます：

それらリモート追跡ブランチを直接チェックアウトすることはできませんが、 自身のブランチを作成しそこで調べることはできます。

"origin" という名前は、複製(clone)したリポジトリを参照する為に git がデフォルトで使用する名前にすぎないことに注意してください。

ブランチ、リモート追跡ブランチ、タグは全てコミットを参照しています。 全ての参照は "refs" で始まるスラッシュ区切りのパス名が付けられています； これまで使用してきた名前は実のところ全て略記です。

フルネームは時折役に立つことがあります。例えば、 同じ名前のタグとブランチがあるような場合です。

(新しく作成された参照は .git/refs ディレクトリ内にその参照の 名前で格納されています。しかし、効率性の理由により、 １つのファイルに纏めて圧縮されることもあります；git-pack-refs(1) 参照)

もう一つ役に立つ略記として、あるリポジトリの "HEAD" は、単にそのリポジトリ名 を使うだけで参照できるというのがあります。 例えば "origin" は通常、リポジトリ "origin" の HEAD ブランチの略記を表わします。

参照先として git がチェックするパスの完全なリストと、 同じ略記をもつ複数の参照がある場合の選択規則については git-rev-parse(1) の "SPECIFYING REVISIONS" の節を 確認してください。

複製(clone)元の開発者はいずれ自身のリポジトリに変更を加えたり、 新しいコミットを作成したり、新しいコミットを参照したブランチを作成するでしょう。

"git fetch" コマンドは、引数なしの場合、全てのリモート追跡している ブランチを複製元リポジトリの最新バージョンの状態に更新します。 この動作は、自分自身のブランチについては何も変更しません。 — "master"ブランチも同じです、それは複製時にあなたの開発用に 作られたものです。

複製元以外のリポジトリにあるブランチを追跡することもできます。 そうするには git-remote(1) を使用します：

新しいリモート追跡ブランチは "git remote add" で指定した 省略名で格納され、上記場合は linux-nfs です：

"git fetch <remote>" をその後に実行すると、<remote> という名前の 追跡ブランチが更新されます。

 .git/config ファイルを見ると、git が新しい節を追加したことを
確認できます。

これは、git がリモートブランチを追跡する為に作成したものです； テキストエディタで .git/config を編集し、これらの設定オプションを 変更、削除することもできます。 (詳細は git-config(1) の "CONFIGURATION FILE" を参照してください)

プロジェクトのバージョン 2.6.18 では動作するが、"master" ブランチの 最新バージョンではクラッシュするとしましょう。 そのようなリグレッションの原因を探し出す最良の方法は プロジェクトの履歴を総当たりで検索し、問題を引き起こす特定のコミットを見つけることです。 git-bisect(1) コマンドはこの作業の手伝いをしてくれます：

この時点で "git branch" を実行すると、git は一時的に "(no branch)" に移動していることが確認できます。 HEADはいまやあらゆるブランチから分離されており、 "master" からは到達可能だが、v2.6.18 からは到達できない コミット(id が 65934… のコミット)を指しています。 コンパイルとテストをし、クラッシュするかを確認します。 もしクラッシュするのなら、以下のように：

として、より古いバージョンを確認します。このように git に各段階でそのバージョンが good か bad かを伝える作業を続け、 テストすべきリビジョンの残数は各回で約半分ずつに削られていきます。

(今回の場合では)約13回テストした後、罪を犯したコミットの id を 見つけることができます。そのコミットに対して git-show(1) を実行し、 誰がそのコミットを書いたかを見つけ出し、コミットの id を添えて、 バグレポートをメールします。最後に、

を実行し、以前いたブランチに戻ます。

ここで注意すべきことはgit bisect が各状態でチェックアウトする バージョンが単なる提案にすぎないことです。 違うバージョンをテストしてもかまわないのです。 例えば、関係のない変更をしているコミット上にいるかもしれません； その時は以下を実行してください。

こうすると gitk が起動して、選択されたコミットに "bisect" という マーカーをつけます。近くの安全そうなコミットを探し、コミットIDをメモして 次のコマンドでチェックアウトします。

そしてテストし、"bisect good" または "bisect bad" の適切な方を実行し、 作業を続けます。

"git bisect visualize"を実行して"git reset —hard fb47ddb2db…" を実行するかわりに、単に現在のコミットをスキップしたいかもしれません。 その場合は以下を実行してください。

しかしこの場合にgitは結果的いくつかの最初のスキップされたコミットと その後の悪いコミットの間にある最初の悪いコミットが わからなくなる可能性があります。

もし良いコミットと悪いコミットを判断することが可能な テストスクリプトがあるなら、bisect作業の自動化には いくつかの方法があります。 詳細はgit-bisect(1)をご覧ください。

既にコミットの指定方法をいくつか紹介してきました：

他にもたくさんあります；リビジョンの呼び方の完全なリストは git-rev-parse(1) の man ページにある "SPECIFYING REVISIONS" の節で 確認できます。

マージコミットは１つ以上の親を持ちます；デフォルトでは ^ と ~ はコミットリストの１つ目の親を指しますが、 次のように指定することもできます；

HEAD の他にも、コミットを指す特殊な名前があります：

(後に説明する)マージは、git reset のような操作と同じように、 現在チェックアウトしているコミットを変更し、 一般的には ORIG_HEAD に現在の操作以前にもっていた HEAD の値をセットします。

git fetch の操作は、常に最後にフェッチしたブランチのヘッドを FETCH_HEAD に 格納します。例えば、操作対象であるローカルブランチを指定せずに git fetch を 実行した場合、

フェッチされるコミットは FETCH_HEAD 取得されます。

マージについて議論するとき、MERGE_HEAD という特別な名前を目にします。 これは、現在のブランチにマージしようとしているもう一方のブランチを 参照しています。

git-rev-parse(1) コマンドは、低レベルのコマンドであり コミットに対する名前をコミットのオブジェクト名に変換するのに役立ちます。

特定のコミットを参照する為にタグを作成することができます； 以下の操作を実行すると、

stable-1 という名前で 1b2e1d63ff のコミットを参照できるようになります。

これは "軽量" タグと呼ばれるものです。 タグにコメントを含めたい場合や、暗号化して署名したい場合には、 その代わりにタグオブジェクトを作成することができます；詳細は git-tag(1) の man ページを参照してください。

git-log(1) コマンドはコミットの一覧を表示します。 現在のブランチ上にある親コミットから到達可能な全てのコミットを表示します。； しかし、さらに特定のリクエストをすることもできます：

そしてもちろん、これら全てを組み合わせることもできます； 以下は v2.5 以降のコミットで、Makefile 又は fs 配下のファイルを変更している コミットを検索します。

git log を使用し、パッチを表示することもできます：

他の表示オプションについては git-log(1) の man ページにある "—pretty" オプション を参照してください。

git log は最新のコミットから開始し、親を辿って後方に検索します； しかし、git の履歴は複数の独立した開発ラインを含むことができる為、 一覧表示されるコミットの順番はいくらか任意になります。

git-diff(1) を使用すると２つのバージョン間の差分を 生成することができます：

これは２つのブランチの先端の間の差分を表示します。 ２つのブランチの共通の祖先から test までの差分を表示したい場合は ドットを２つではなく３つとし、次のようにします：

時には差分ではなく各パッチの集合が必要な場合もあります；その際には git-format-patch(1): を使用します：

このようにすると、test から到達可能だが、master からは到達できない各コミットの パッチを含むファイルを生成できます。

特定のリビジョンをチェックアウトすることで、ファイルの古いバージョンを表示させる ことができます。しかし時にはある１つのファイルの古いバージョンを チェックアウトせずに表示できると便利です； 次のコマンドでそれができます：

コロン(:) の前はコミットを指す任意の名前で、その後ろは git が追跡しているファイルの任意のパスです。

コミットをする前に、git に自己紹介をすべきです。 一番簡単な方法はホームディレクトリ下にある .gitconfig というファイルに 次の行が表示されていることを確認することです。

(設定ファイルの詳細は git-config(1) の "CONFIGURATION FILE" 節を 参照してください)

ゼロから新規リポジトリを作成するのはとても簡単です：

最初に登録したいものがある場合は (tarball の場合)：

新しいコミットを作成するには３つのステップが必要です：

実際には、ステップ１と２を相互に好きなだけ繰り返すことができます： ステップ３でコミットしたいものの追跡を保つ為、git は "索引(index)" と呼ばれる 特別なエリア内にツリーの中身のスナップショットを保管しています。

最初は索引の中身は HEAD の中身と同じです。 コマンド "git diff —cached" は HEAD と索引間の差分を表示する為、 この時点では何も出力しません。

索引を変更するのは容易です：

索引を新しく修正したファイルの中身で更新するには、以下のようにします。

新しいファイルの中身を索引に追加するにも、以下のようにします。

索引と作業ツリー上からファイルを削除するには、

各ステップを行った後には、

を行うことで HEAD と索引ファイル間の差分を確認することができます。— これはコミットした時に作成される内容です。— そして

は、作業ツリーと索引ファイル間の差分を表示します。

"git add" は常に現在のファイルの中身を索引に追加することに注意 してください；さらに同じファイルに変更を加えても再度 git add をそのファイルに 行わない限りは無視されます。

準備ができたら、

を実行します。git はコミットのメッセージの入力を促してから 新しいコミットを作成します。意図した結果になっているかを確認するには、以下のようにします。

特別なショートカットとして

というのがあります。これは変更又は削除した全てのファイルの索引を更新し コミットを作成する操作を、１回のステップで全て行います。

たくさんのコマンドがコミットしようとしているものの追跡を保つ為に 役に立ちます：

これらのことをするために git-gui(1) を使用することもできます。 git-gui は コミットの作成や、索引と作業ツリー間の差分の参照、 索引に含めるべき差分ハンクを個々に選択する(差分ハンクを右クリックして、 "Stage Hunk For Commit" を選択する) ことができます。

必須ではありませんが、格納メッセージを 次のようにするのは良い考えです。１行の短文(50文字未満)で変更のサマリを書き、 その後に空白行を挟んで、最後により綿密な記述をまとめる。 そうすることで、例えばコミットした内容を E-Mail に変更するツールにて、 Subjectに最初の行を使用し、残りの行を本文にすることができます。

プロジェクトはよく git に追跡してほしく'ない'ファイルを生成します。 典型的なものとしては、ビルドプロセッサーが生成するファイルや、 エディタが生成するバックアップファイルなどです。もちろん、 git が追跡しないファイルに対して git add`をしなければ良いだけの問題です。 しかし、これら追跡しないファイルがいることでイライラさせられることがあります； 例えば、それらファイルに対しての `git add . は実際に不要であるにも、 関わらず、 git status の出力でそれらが表示されてしまいます。

作業ディレクトリのトップレベルに .gitignore という名前のファイルを作成することで、 無視するファイルを git に伝えることができます。

記述形式の詳細は gitignore(5) を参照してください。 作業ツリーの他のディレクトリに .gitignore を置くこともできます。 その場合、そのディレクトリとサブディレクトリに適用されます。 .gitignore ファイルは他のファイルと同様、リポジトリに追加することができます (通常と同じで git add .gitignore と git commit を実行するだけです)。 (ビルド時の出力ファイルに一致するパターンのような) 除外パターンを git で管理することは、 あなたのリポジトリを複製する他のユーザにとっても便利なことです。

(プロジェクトの全てのリポジトリの代わりに)ある特定のリポジトリでだけ 除外パターンを適用したい場合は、リポジトリ内の .git/info/exclude という場所に それらを置くか、コンフィグレーション変数 core.excludesfile によって 指定することができます。git コマンドによってはコマンドラインで除外するパターンを 直接指定することもできます。 詳細は gitignore(5) を参照してください。

２つの分散した開発ブランチは git-merge(1) を使用して マージできます：

上記はブランチ "branchname" の開発を現在のブランチにマージします。 コンフリクトが発生した場合は — 例えば、リモートブランチとローカルブランチで 同じファイルが２つの異なる方法で変更された場合 — 警告が表示されます； 出力される内容は以下のようなものです：

コンフリクトマーカーは問題のあるファイルに残り、コンフリクトを 手作業で解消した後は、索引をそのファイルの中身で更新し、 git commit を実行することができます。通常の新しいファイルを作成するときと 同じようにです。

gitk を使用しコミット結果を確認すると、それが２つの親を持っていて、 現在のブランチの先頭と、もうひとつのブランチの先頭とを位置している ことが分かります。

マージが自動的に解決されない場合、git は索引と作業ツリーを 特別な状態にし、マージの解決を手助けするのに必要な全ての情報を与えて くれます。

コンフリクトしたファイルは、索引内で特別なマージが付けられ、 その為問題を解決し索引を更新するまで、git-commit(1) は 失敗します：

また、git-status(1) はそれらのファイルを "unmerged" として表示し、 コンフリクトしたファイルには以下のようなコンフリクトマーカーが追加されています：

すべきことは、ファイルを編集してコンフリクトを解決し以下のようにすることです。

コミットメッセージは既にマージに関する情報が埋められていることに 注意してください。通常このデフォルトのメッセージは変更せずに使用できますが、 必要であれば自身のコメントを追加することもできます。

上記は単純なマージを解決する為に知る必要のある全てです。 しかし、git はコンフリクトの解決を手助けするさらなる情報を与えてくれます。

git が自動的にマージできた全ての変更は既に索引ファイルに 追加されています。そして git-diff(1) はコンフリクトだけを 表示します。そうするには通常の構文を使用します：

このコンフリクトを解決した後、コミットされる予定の内容は 通常と違って２つの親を持っていることを思い出してください；一方は HEAD、つまり現在のブランチの先端；もう一方はもうひとつのブランチの先端で MERGE_HEAD に格納されています。

マージしている間、索引は各ファイルの３つのバージョンを持っています。 この３つはそれぞれファイルの異なる３つの "ファイルステージ" を表現しています：

コンフリクトが起こっている箇所を表示するために git-diff(1)を実行すると、 コンフリクトが起こったマージ結果の間の 三方向の差分(three-way diff)が表示されます。 差分にはステージ2と3双方からきたコンテンツ が混ざった状態で含まれています。 (言い換えるとハンクのマージ結果が ステージ2だけからなされる場合その部分ではコンフリクトは起こらず 表示されません。ステージ3についても同じです)

上記の差分は file.txt の作業ツリーのバージョンとステージ２とステージ３の バージョン間の差分を表示します。その為、各行の先頭に１つの "+" または "-" が 付けられるかわりに、２つの列が使用されます：１つ目は １つ目の親と作業ディレクトリコピーの間の差分を表すのに利用され、 ２つ目は２つ目の親と作業ディレクトリコピーの間の差分を表示するのに利用されます。 (このフォーマットの詳細は git-diff-files(1) の "COMBINED DIFF FORMAT" の 節を参照してください)

コンフリクトを通常と同じ方法で解決した後、(indexの更新前に) diff を 実行すると次のように表示されます：

これは、解決済みのバージョンが 一つ目の親から "Hello world" を削除し、 ２つ目の親から "Goodbye" を削除し、 両方の親に存在しない "Goodbye world" を追加したことを表しています。

他の特別な diff オプションを使用すると、これら任意のステージと 作業ディレクトリとの差分を表示することができます。

git-log(1) と gitk(1) コマンドもまた merge の手助けをしてくれます。

これらは、HEAD または MERGE_HEAD にだけ存在する全てのコミットを表示し、 マージされていないファイルを表示します。

linkgit:git-mergetool を利用することもできます。これを利用すると Emacs や kdiff3 のような外部ツールを使用してマージを行うことができます。

ファイルのコンフリクトを解決した後には、索引を更新してください：

すると、そのファイルの各ステージは "崩壊" され、 git diff はもはや (デフォルトでは) そのファイルに対する差分を表示しません。

マージ作業に行き詰まり、全ての処置を捨て去る場合には、 いつでもマージ前の状態に戻ることができます。次のようにします。

あるいは、既に削除したいマージ結果をコミット済みの場合には、次のようにします。

しかし、最後のコマンドは、幾つかの場合に危険となりえます。— そのコミットが 他のブランチにマージされている場合は、決してそのコミットを削除しないでください。 もしそうしたなら、さらにマージする場合に混乱が起きます。

上記で説明してこなかった特別なケースがあります。 通常マージコミットにおけるマージ結果は２つの親を持ち、 各親はマージした２つの開発ラインのそれぞれを指し示しています。

そのため、現在のブランチが他方の子孫である場合には — つまり 全てのコミットが既に他方のコミットに含まれている場合には — git は "fast forward" を行います；現在のブランチの先頭はマージされるブランチの 先頭の位置に進められ、新しいコミットは作成されません。

作業ツリーに手を入れたが、間違いをまだコミットしていない場合は、 以下のようにして作業ツリーを最後にコミットした状態に戻すことができます。

コミットした後ですべきではなかったと気が付いた時は、 ２つの異なる解決方法があります：

大きなリポジトリでは、git はディスクとメモリの使用量を節約するため、 履歴の情報を圧縮して管理することができます。

この圧縮は自動的には行なわれません。従って 時々 git-gc(1) を実行する必要があります：

アーカイブを圧縮する処理はたくさんの時間がかかるため、 git gc をするときは、他の作業をしない方が良いでしょう。

リポジトリを複製し、自分でソースを変更した後には、 元のリポジトリが更新されているかを確認し、自分の作業ディレクトリ上に マージしたいと思うでしょう。

既に git-fetch(1) を用いて 外部追跡ブランチを最新に保つ方法 と２つのブランチをマージする方法を見てきました。 従って、元のリポジトリのマスターブランチの変更をマージすることができます：

しかし、git-pull(1) コマンドを使用すれば、１回のステップで この操作を行うことができます。

実際のところ、あなたが "master" をチェックアウトしていたなら、"git pull" はデフォルトでは 元のリポジトリの HEAD ブランチからマージを行ないます。従って たいていは単に以下のようにするだけで、上記のことが出来ます。

より一般的には、リモートブランチで作成されたブランチは、 デフォルトではそのブランチから pull されます。 それらデフォルト値のコントロール方法を理解するには、 git-config(1) の branch.<name>.remote と branch.<name>.merge のオプション の記述と、git-checkout(1) の —track オプションの説明を参照してください。

さらに、キータイプを省略する為に "git pull" は pull 元のブランチとリポジトリを説明したデフォルトのコミットメッセージを 生成してくれます。

(しかし、fast forward の場合にはそのようなコミットは 作成されないことに注意してください；その代わり、あなたのブランチには 上流のブランチの最新のコミット位置に更新されます。)

git pull コマンドは "." を "remote" のリポジトリとして扱い、 その場合、単に現在のリポジトリからブランチにマージを行います； 従って次のコマンド

は、大雑把に言えば同じです。前者は実際に広く一般に使われています。

プロジェクトにパッチを投稿する

行なった変更を投稿する一番簡単な方法は email でパッチとして それらの変更を送信することです。

初めに、git-format-patch(1) を使用します。；例えば：

により、カレントディレクトリ内に番号付けされた一連のファイルが生成されます。 それらはカレントブランチには含まれるが origin/HEAD には含まれないパッチです。

これらをあなたのメールクライアントにインポートし、手作業でそれらを 送信できます。しかし、一度にたくさん送信したい時は、むしろ git-send-email(1) スクリプトを使用してこの作業を自動化させたいでしょう。 メーリングリストで助言を求め、あなたのプロジェクトがそのようなパッチを どのように扱うことを望むのか決定すると良いでしょう。

Git は git-am(1) (am は "apply mailbox(メールボックスを適用する" という意味です) と呼ばれるツールを提供しており、このようなメールされた一連のパッチを インポートすることができます。 パッチが含まれるメッセージ全部を順番に１つの mailbox ファイル、"patches.mbox" と言います、 に保存してください。そして、以下を実行します。

Git は各パッチを順番に適用します；もしコンフリクトが見つかった場合は、 適用は中止され、"マージの解決" で説明されているように コンフリクトを解決してください。( "-3" のオプションは git に マージすることを伝えます；もし単純に変更を取り消し、 ツリーと索引を変更したくない場合は、"-3" のオプションを省略してください。)

コンフリクトを解消して索引を更新した後は、 新しいコミットを作成する変わりに、

を実行すると、コミットが生成され、mailbox にある残りのパッチの適用が 再開されます。

最終的には、一連のコミットとなり、一つ一つが元の mailbox の パッチに対応し、各パッチに含まれているメッセージから取得された 著者とコミットログメッセージが利用されます。

プロジェクトに変更を投稿するもう一つの方法はプロジェクトの管理者に あなたのリポジトリから git-pull(1) を使用して変更を pull してもらうことです。 "git pull を使用して更新する" のセクションで 我々は "main" リポジトリから更新を取得する方法を説明してきましたが、 逆の方向についても同じことができます。

あなたと管理者が同じマシン上にアカウントを持っている場合は、 互いのリポジトリから直接変更を pull することができます； リポジトリの URL を引数として受け取ることのできるコマンドは ローカルのディレクトリ名もまた受け取ることができます：

又は、ssh の URL :

開発者の少ないプロジェクトや、少ないプライベートなリポジトリを同期 するような場合、これらが必要な全てとなりえます。

しかしながら、より一般的にこれを行なうには、 他のユーザが変更を pull する為の独立した公開リポジトリを(通常は別のホスト上に) 準備する必要があります。このほうが通常はより便利で、こうすることで 個人の作業中の変更と公開する変更とをきれいに分けることができます。

日々の作業は自分の個人用リポジトリ上で行い、 定期的に個人用リポジトリから公開リポジトリに変更を "push" することで 他の開発者は公開リポジトリから変更を pull できるようになります。 従って、変更のフローは、公開リポジトリを持つ別の開発者が１人いるような場合には、 次のようになります：

                             あなたが push
あなたの個人リポジトリ --------------------------> あなたの公開リポジトリ
                                                          |
      |                                                   |
      | あなたが pull                                     | 彼らが pull
      |                                                   |
      |                                                   |
      |                      彼らが push                  V
彼らの公開リポジトリ <--------------------------- 彼らのリポジトリ

次のセクションでどのようにこれを行なうかを説明します。

あなたが大きなプロジェクトのコントリビュータであったと仮定し、 複雑な変更を加えたとします。あなたはそれを他の開発者に公表する為、 その変更を読みやすい手順にし、それが正しいとわかることを証明し、 各変更を行なった理由がわかるようにしたいとします。

１つのパッチ(あるいはコミット)として変更全てを公表すると、 大き過ぎる為一度に全てを消化できません。

あなたの作業の完全な履歴を公表するとなると、間違いや訂正、意味無く終わったもの などが全て含まれ、冗長すぎてしまいます。

従って、通常は次のような一連のパッチを生成するのが理想的です：

これら作業の手助けをする幾つかのツールを紹介し、 それらの使い方を説明し、履歴を再編集することにより発生する問題の幾つかを 説明します

git rebase を使用して一連のパッチを最新に保つ

リモート追跡ブランチ "origin" の上にブランチ "mywork" を作成し、 幾つかコミットを作成したとします：

mywork にマージをしていないので、変更は "origin" から単純に並行に 行なわれています。

 o--o--o <-- origin
        \
         o--o--o <-- mywork

プロジェクトの上流では他の興味深い変更が行なわれ、 "origin" は発展します：

 o--o--O--o--o--o <-- origin
        \
         a--b--c <-- mywork

この時点で、"pull" を使用して変更をマージさせることができます； 結果として新しいマージコミットが生成されます、次のようにです：

 o--o--O--o--o--o <-- origin
        \        \
         a--b--c--m <-- mywork

しかし、自分の履歴をマージ操作の無い、単純な一連のコミットの状態で 保ちたいのであれば、その代わりに git-rebase(1) を使用すると 良いでしょう。

これは、mywork からあなたの各コミットを削除し、一時的に (".git/rebase-apply" という名前のディレクトリ内に)パッチとして保存し、 mywork を origin の最新バージョンの位置に更新し、その後で保存した 各パッチを新しい mywork ブランチに適用します。結果は次のようになります：

 o--o--O--o--o--o <-- origin
                 \
                  a'--b'--c' <-- mywork

この作業中にコンフリクトが発生するかもしれません。その場合は コンフリクトを解決してください；コンフリクトを解消した後に git add を使用してそれらの内容で索引を更新し、 git commit を実行する代わりに、

を実行します。すると、残りのパッチを適用する作業が続けられます。

どの時点でも —abort オプションを使用すると、この作業を取り消し、 rebase を開始する前の mywork の状態に戻ることができます：

履歴を再編集して間違いを訂正する で見てきたように直前のコミットを 以下のようにして修正することができます。

この操作は、過去のコミットをあなたが変更を受け入れる新しいコミットに 置き換え、過去のコミットメッセージを編集する機会を与えてくれます。

これと git-rebase(1) を組み合わせることで、履歴内のさらに過去のコミットについても 置き換えをし、その先頭の変更に立ち入ることができます。 初めに、次のようにして問題のあるコミットにタグを付けます。

(gitk または git log が問題のあるコミットを見つけるのに役立ちます。)

そのコミットをチェックアウトして編集し、残りの一連の変更を その先頭にリベースします(ここでは 引き剥がされたhead を 使用する代わりに、一時的なブランチ上にコミットをチェックアウトします。)：

これらを行なった後、チェックアウトした mywork が保たれ続け、mywork 上の 先頭のパッチは修正したコミットの先頭に再適用されます。 そして、これらを片付けることができます。

git の履歴が不変であるという性質は既存のコミットを実際に "変更" していない ことを意味していることに注意してください；代わりに、古いコミットを 新しいオブジェクト名を持つ新しいコミットで置き換えています。

存在するコミットを引数にして git-cherry-pick(1) コマンドを 実行すると、そのコミットが行なった変更を適用し、新しいコミットを 作成することができます。従って、例えば、"mywork" が "origin" の先頭の 一連のパッチを指しているなら、以下のようにすることができます：

そして、gitk を使用して mywork ブランチのパッチの一覧を表示し、 cherry-pick を使用して mywork-new にそれらを(可能なら異なる順番で)適用し、 可能であるなら git commit —amend を使用してそれらを修正します。 git-gui(1) コマンドは個々の選択した diff ハンクを索引に含めるかどうかを 選択するのに役に立つかもしれません。(diff ハンクを右クリックし、 "Stage Hunk for Commit" を選択します)

もう一つの技術は git format-patch を使用して一連のパッチを作成し、 パッチの前の状態にリセットすることです：

そして、修正し、順番を並び替え、取り除き git-am(1) を使用して 再びパッチを適用します。

他にもツールが多数あります。例えば StGIT です。stgit は一連のパッチを 管理するツールです。このマニュアルの対照から外れるため、説明は省略します。

ブランチの履歴を書き換えることによって生じる主な問題はマージに関する ことです。誰かがあなたのブランチをフェッチし、自分のブランチにマージ すると、結果は次のようになります：

 o--o--O--o--o--o <-- origin
        \        \
         t--t--t--m <-- their branch:

そして、最後の３つのコミットを修正したとします：

         o--o--o <-- new head of origin
        /
 o--o--O--o--o--o <-- old head of origin

もしそれらが１つのリポジトリに入っていたとすると、 次のようになります：

         o--o--o <-- new head of origin
        /
 o--o--O--o--o--o <-- old head of origin
        \        \
         t--t--t--m <-- their branch:

Git は新しい head が古い head の更新されたバージョンであることを認識 しません；Git はこのような状態を２つの開発者が古い head と新しい head で 並行に作業したものとして扱います。 その為、だれかが当たらし head を自身のブランチにマージしようとすると、 git は old を new に置き換える代わりに、その２つの開発ライン(old と new) をいっしょにマージしようとします。 その結果は、期待したものとはことなります。

履歴が再編集されたブランチをまだ公開しようとするかもしれません。 そして、それらブランチをフェッチし順番にテストするのは役に立つことだと 思うかもしれません。しかし、そのようなブランチを自分の作業エリアに pull すべきではありません。

適切なマージをサポートする本来の分散開発では、 公開されたブランチは決して再編集されるべきではありません。

git-bisect(1) コマンドはマージコミットを含んだ履歴を正確に扱います。 しかし、コミットがマージコミットである時は、そのコミットが何故問題を起こしている かの原因を見つけ出すのに苦労することがあります。

次の履歴を考えてください：

      ---Z---o---X---...---o---A---C---D
          \                       /
           o---o---Y---...---o---B

上側の開発ライン上のコミットXにて Zから存在する関数の意味が 変更されたとします。ZからAにつながるコミットは、関数の実装を変更し、 Zの時点で存在する全コール箇所と新しく追加したコール箇所の両方を変更して、 矛盾のない状態にしていたとします。 A の時点ではバグはありません。

それと同時に下側の開発ラインではコミットYにてその関数の新しい コール箇所を追加していたとします。 ZからBにつながるコミットの全ては、その関数の古い動作を想定していて コール元とコール先は互いに矛盾していません。Bにもバグはありません。

２つの開発ラインがきれいにマージできたとすると、 コンフリクトの解消要求はありません。

にもかかわらず、Cのソースは壊れています。なぜなら 下側の開発ラインは上側の開発ラインで行われた新しい動作に変換 されていないからです。 したがって、git-bisect(1) は D に問題があり、 Z には問題ないこと、そしてC が問題の原因であると伝えます。 どのようにしたら、問題が動作変更によるものだと見つけることが できるでしょうか？

git bisect の結果が非マージコミットの場合、通常、単にそのコミットを 確認するだけで問題を見つけることができます。 開発者はコミットを自己完結したより小さいものに分割することで これを容易に行うことができます。しかし、 上記場合には１つのコミットを確認することでは問題が明らかにならない為、 このような方法では解決の役に立ちません；その代わりに開発の大局的な視点が 必要となります。さらに悪いことに、問題となっている関数の動作変更が 上側の開発ラインの単なる小さな部分の変更であるかもしれません。

その一方で、C のマージをする代わりに、ZからBの履歴を Aの先頭 にリベースした場合、次のような１行の履歴を取得することができます：

    ---Z---o---X--...---o---A---o---o---Y*--...---o---B*--D*

Z と D* の間を git bisect すると、１つの問題の原因となるコミット Y* を見つけることができ、Y* が何故問題を引き起こしている理由を 容易に理解することができるでしょう。

部分的にですが、この理由により、たくさん経験を積んだ git ユーザは マージが頻繁に行われるプロジェクトで作業する場合でさえも 最新の上流バージョンに対するリベースを行うことによって 履歴を１ラインに保つようにしています。

git-remote(1) を使用する代わりに、時には１つのブランチだけを 更新し、任意の名前でローカルに保存することもできます：

最初の引数 "origin" はクローン元のリポジトリからフェッチすることを git に伝えています。２つ目の引数はリモートのリポジトリの "todo" という 名前のブランチをフェッチし、refs/heads/my-todo-work という名前で ローカルに保存することを git に伝えています。

他のリポジトリにあるブランチをフェッチすることもできます；例えば、

は "example-master" という名前の新しいブランチを作成し、 指定した URL にあるリポジトリの "master" という名前のブランチの内容を 保存します。既に "example-master" という名前のブランチが存在する場合は、 example.com の master ブランチが与えるコミットの fast-forward を 試みます。詳細は次の節で説明します。

前節の例では、存在するブランチを更新する時に、"git fetch" は リモートブランチの最新のコミットがあなたのコピーしたブランチの最新の コミットの子孫であることを確認してから、新しいコミットの位置に 更新しようとします。 Git はこのプロセスを fast forward と呼びます。

fast forward は、以下のように見えます：

 o--o--o--o <-- old head of the branch
           \
            o--o--o <-- new head of the branch

時には、新しい head は古い head の子孫ではない可能性があります。 例えば、開発者が深刻な間違いをしたことに気がつき、変更を 元に戻すことにした場合です、その結果は次のようになります：

 o--o--o--o--a--b <-- old head of the branch
           \
            o--o--o <-- new head of the branch

この場合、"git fetch" は失敗し、警告が表示されます。

その場合にも、次の節で説明する方法で、強制的に新しい head に 更新することができます。しかし、上記の場合には それらへの参照を既に作成していない限りは "a" と "b" のコミットが紛失することを意味することに注意してください。

新しいブランチの head が古い head の子孫ではない為に、 git fetch 失敗した場合には、次のようにして強制的に 更新することができます：

"+" 記号を追加していることに注意してください。代わりに "-f" を のフラグを使用し、フェッチした全てのブランチを強制的に更新することもできます：

この操作により、example/master の古いバージョンが指していたコミットは紛失して しまうことに注意してください。それは、前の節で説明したとおりです。

既に説明したように、"origin" はクローン元のリポジトリを参照する ショートカットです。この情報は git の構成ファイルに格納されており、 git-config(1) を使用して参照することができます：

他にも頻繁に参照するリポジトリがある場合は、タイピング数を節約するため、 同じように構成ファイルに登録することができます；例えば、

とすると、次の２つのコマンドは同じことをするようになります：

さらに、次のオプションを追加すると：

次のコマンドは全て同じことをするようになります：

"+" をつけて強制的に更新することもできます：

"git fetch" が example/master 上のコミットを捨て去る可能性があることを 嫌う場合は、この操作はしないでください。

また、上記の構成全ては、git-config(1) を使用する代わりに 直接 .git/config ファイルを編集して登録することもできます。

詳細は git-config(1) 内の 構成オプションについて触れられている 箇所を参照してください。

既に the section called “履歴の理解：コミット” で見てきたように、全てのコミットは 40桁の "オブジェクト名" で格納されています。実際、プロジェクトの履歴を 表現するのに必要な全ての情報は、そのような名前のオブジェクトとして格納されています。 それぞれの名前はオブジェクト内容の SHA-1 ハッシュによって 計算されています。SHA-1ハッシュは暗号学的ハッシュ関数です。 それはつまり、同じ名前を持つ２つの異なるオブジェクトを見つけるのが 不可能であることを意味します。このことは多くの利点を持っています。 とりわけ：

(オブジェクトの形式と SHA1 計算の詳細は the section called “オブジェクトの保管形式” を参照してください)

Gitが扱う オブジェクトには４種類あります："blob", "tree", "commit" そして "tag" です。

オブジェクトタイプの詳細：

索引はバイナリファイル(通常 .git/index 内に保管)であり、 ソートされたパス名と、パーミッション、blob の SHA-1値の一覧を含んでいます； git-ls-files(1) を使用すると索引の中身を参照できます：

古いドキュメントでは、"現在のディレクトリキャッシュ" または単に "キャッシュ" と呼んでいることがあります。索引には３つの重要な 性質があります：

このように索引は一時的な作業エリアの役割をし、 作業中のツリーの内容が詰められています。

索引を完全に消し去ると、それを記述していたツリーの名前を 持っていない限りは、全ての情報を失ってしまいます。

サブモジュールを参照する親プロジェクトの変更を公開する前には 必ずサブモジュールの変更を公開してください。もしサブモジュールの変更を 公開し忘れた場合、リポジトリを複製できなくなるでしょう：

親プロジェクトにより記録されたコミットよりも手前にサブモジュールのブランチを 巻き戻すべきではありません。

そうした場合、ブランチを最初にチェックアウトせずにサブモジュール内の変更を コミットした時に git submodule update は安全に動作しません。 何も言わずに変更を上書きしてしまいます。

注意：変更はサブモジュールの reflog にまだ残っています。

ただし、変更をコミットしていない場合は残っていません。

git-cat-file(1) コマンドは任意のオブジェクトの中身を表示する ことができますが、上位の git-show(1) の方が通常は便利です。

git-commit-tree(1) コマンドを用いると任意の親とツリーで コミットを構成させることができます。

git-write-tree(1) を用いるとツリーを作成することができ、 その中身は git-ls-tree(1) でアクセスできます。２つのツリーは git-diff-tree(1) で比較することができます。

タグは git-mktag(1) で作成でき、その署名は git-verify-tag(1) で検証することができます。しかし、これら２つは git-tag(1) を 使用すると同じようなことができます。

git-commit(1)、git-checkout(1)、git-reset(1) のような高レベルの操作は作業ツリー、索引、オブジェクトＤＢ間の データを移動することによって仕事をします。 Git はこれらの各ステップを独立に行なう下位レベルの操作を提供しています。

一般に、全ての "git" 操作は索引ファイル上で作用します。 いくつかの操作は 純粋に 索引ファイル(現在の索引の状態を表示) 上で作用しますが、ほとんどの操作は索引ファイルとデータベース又は 作業ディレクトリ間のデータを移動します。従って、主に４つの組み合わせがあります：

様々なヘルパーツールを用いることでオブジェクトDBと 索引の中身を確認することができます。 各オブジェクトの中身は git-cat-file(1) で確認します:

これはオブジェクトのタイプを表示し、タイプを確認した後は 次のようにして、中身を確認することができます。

注意！ Tree はバイナリであり、その中身を見るには git ls-tree という 特別なツールを使用します。これは、バイナリの内容をより読みやすい形式に 変換してくれます。

"commit" オブジェクトの中身を見ることはとても教育的です。 それらは小さく、一目瞭然です。特に、 最新のコミット名が .git/HEAD にあるという規約を使用し、 次のようにすると、最新のコミットの中身を確認できます。

Git は 3方向マージを行なう手助けをします。これは 任意の回数繰り返すことにより n方向マージに拡張することができます。 通常は3方向マージ(2つの親によるマージ)のみを行ないますが、 複数の親を1回でマージすることもできます。

3方向マージをするには、マージする2組の "commit" オブジェクトが 必要です。これを使用し共通の親(3番目の"commit"オブジェクト)を見つけ、 それら commit オブジェクトを使用してディレクトリ("tree" オブジェクト) の状態を探します。

マージの "ベース" を得るには、まず次のようにして ２つのコミットの共通の親を見つけます。

これは、共通のベースコミットを返却します。 これらコミットの "tree" オブジェクトは次のようにして 容易に見つけることができます。(例えば)

tree オブジェクトの情報は、コミットオブジェクトの１行目に 常に記述されています。

マージしようとする３つのツリー(１つは "original"の tree いわゆる 共通の tree、 ２つの "結果" tree、いわゆるマージしたいブランチ)を知った後は、 索引に読み込んでそれらを "マージ" します。 古い索引の中身を破棄しなくてはならない場合、エラーを表示します。 従ってそれらをコミットしたか確認してください。— 実際、通常は常に 最後にコミットした内容をもとにマージします(そのコミットは従って 現在の索引の内容と一致します)

マージをするには次のひょうにします。

これにより、自明のマージ操作は直接索引ファイルに行なわれ、 git write-tree を用いてその結果を書き込むことができます。

残念なことに、多くのマージは自明ではありませんん。 追加や移動、削除されたファイルがある場合や、あるいは両方のブランチ で同じファイルが変更されている場合、"マージエントリ" を含んだ 索引ツリーが残されます。このような索引ツリーは tree オブジェクトには書き込むことができません。その結果を書き込む前に 他のツールを使用してコンフリクトを解消する必要があります。

このような索引状態は git ls-files —unmerged を 用いると確認できます。例えば：

git ls-files —unmerged の出力の各行は blob のモードビット、 blob の SHA-1、stage番号'、そしてファイル番号で始まります。 'stage番号 はそれがどの tree から来たかを表す git のやり方です： stage 1 は $orig ツリーに対応し、stege 2 は HEAD の tree stage 3 $target tree です。

既に自明のマージは git read-tree -m にて行なわれたことを 説明しました。例えば、ファイルが HEAD と $target` のどちらでも 変更されていない場合や、HEAD と $target が同じ内容の場合は 明らかに最終的な結果は HEAD のものと同じです。 上記の例では hello.c は HEAD で変更されていて $target`でも 別の変更が行なわれている場合です。 好きな3方向マージツールを実行してこれを解決することができます。 例えば `diff3`、`merge あるいは git 自身の merge-file などを使用し これら３つのstage 上のファイルを次のようにしてマージします。

これはマージ結果は hello.c~2 ファイルに保存し、 コンフリクトがあるときは、コンフリクトマーカが付けられます。 マージ結果を確認した後、このファイルの最終的なマージ結果を git に次のようにして伝えます：

ファイルにマージ済みになっていない時は、git update-index は ファイルに解決済みのマークを付けます。

上記は下位レベルにおける git のマージ動作の解説で、 水面下でどのようなことが起きているかの概念を理解する手助けになります。 実際、誰も、git 自身でさえ、git cat-file を3回も実行しません。 git merge-index プログラムがあり、これが stage を一時ファイルとして 抽出し、"merge" スクリプトをコールします：

そして、上位レベルとして git merge -s resolve が実装されています。

すべてのオブジェクトは静的に決定された "種別" を持っており、 それによりオブジェクトの形式が特定されます(例えば、どのように使用され どのように他のオブジェクトを参照するかなど)。現在のところ、オブジェクト 種別は４つ存在します： "blob", "tree", "commit", "tag" です。

オブジェクトの種別に関係なく、すべてのオブジェクトは次の特徴を持ちます： オブジェクトは全て zlib で圧縮され、ヘッダにはオブジェクトの種別だけでなく、 オブジェクトデータのサイズの情報が含まれています。 なお、オブジェクトの名前に使用されている SHA-1 ハッシュ値は元データ＋このヘッダの ハッシュ値となっています。従ってファイルの sha1sum の結果は そのオブジェクトの名前とは一致しません。

その結果、オブジェクトの一般的な一貫性はその中身やオブジェクト種別とは 常に独立してテストすることができます：全ておオブジェクトは次のようにして 検証することができます。(a)それらのハッシュ値がファイルの中身と一致していること。そして、 (b)オブジェクトを解凍することができ、解凍したデータは <オブジェクトの種別> 空白 <サイズ> ＋ <byte\0> + <オブジェクトのバイナリデータ> の順番となっていること。

構造化されたオブジェクトの場合は、さらにその構造と他のオブジェクトの 連結性によって懸賞することができます。これらは git fsck プログラムが 通常行っている内容であり、全オブジェクトの完全な依存グラフを生成し、 それらの内部一貫性を検証します(さらに、単にハッシュを使用した表面的な 一貫性の検証も行います)

新しい開発者にとっては Git のソースコードの構成を理解するのは必ずしも 容易ではないでしょう。このセクションでは、どこから開始したら良いかを 示す小さなガイダンスです。

手始めとして良い場所は、初期コミットの内容を見ることです。次のように取得します：

初期コミットには現在の git のほとんど全ての基礎ができていますが、 ざっと読みとおすのには十分な小ささです。

現在ではこのリビジョンの頃から用語が変更されています。例えば、 このリビジョンの README では現在 コミット と呼んでいる ものを "チェンジセット" と呼んでいます。

また、現在は "キャッシュ" という言い方はせず それどころか"索引(index)" と呼んでいますが、 ファイルは今も cache.h です。(注釈：Not much reason to change it now, especially since there is no good single name for it anyway, because it is basically the header file which is included by all of Git's C sources.)

初期コミットを眺めて概要を把握できたら、より新しいバージョンを チェックアウトし、cache.h, object.h, commit.h にざっと目を 通してください。

初期の頃には、Git は UNIX の伝統にならい、非常にシンプルなプログラムの 集まりとなっていて、それらをパイプで組み合わせ、スクリプト化したりして 利用するようなツールでした。新しいことを試すのが容易であったため、 初期の開発でこれは良いことでした。しかし、現在では、これらの大部分は 内部に組み込まれ、いくつかのコア部分は "ライブラリ化" されました。 つまり、パフォーマンスや移植性、コードの重複の回避などの理由で libgit.a に入れられました。

ここまでの確認で、索引が何かを理解し、そして、cashe.h`内の索引のデータ 構造を理解することができたはずです。また、４つのオブジェクトタイプ(blob, tree, commit, tag)が `struct object の共通構造を継承していていることや、 struct object がそれらの最初のメンバであり 例えば (struct object *)commit のようにキャストすることで &commit->object と同じ結果が得られること、同じようにオブジェクト名やフラグも 得られることを確認できたはずです。

ここまでで、オブジェクトデータに関する確認はひと段落です。

次のステップ：オブジェクトの指定方法を理解してください。 コミットの指定方法 に書かれているとおり、 オブジェクトの指定方法は数個です(そして、それらはコミットだけに限ったことではありません!)。 これらの指定部分の実装は sha1_name.c で行われています。 その中の関数 get_sha1() をざっとみてください。 特徴的な部分は `get_sha1_basic() などの関数部分でハンドリングされています。

この部分は、Git の最もライブラリ化された部分、すなわちリビジョンウォーカー に対するよい導入になっています。

基本的には、git log の初期バージョンは次のようなシェルスクリプトでした：

これは何を意味するでしょうか？

git rev-list はリビジョンウォーカーの元になったバージョンであり、 常に リビジョンの一覧を標準出力に出力するコマンドです。 このコマンドは現在でも役に立っており、新しい Git プログラムを スクリプトとして作成するような場合によく利用されます。

git rev-parse はもはや重要ではありません；何故ならこれは、スクリプトにより コールされる異なる配管コマンドに対して、関連のあるオプションをフィルタリング する為だけに利用されているからです。

git rev-list が行っていることのほとんどは、revision.c と revision.h に含まれています。rev_info という名前の構造内のオプションを包み込み、 どのようにどのリビジョンにウォーク(アクセス)するかなどのコントロールをします。

git rev-parse の元の役割は、現在は setup_revisions() 関数に 取って代わられました。setup_revisions() はリビジョンウォーカーの為に リビジョンと共通のコマンドラインの解析をします。解析結果は rev_info に 保管されて利用されます。setup_revisions() を呼び出した後に、自身の コマンドラインオプションを解析することもできます。その後に prepare_revision_walk() をコールして初期化すると、get_revision() 関数にて ここのコミットを取得することができます。

リビジョンウォーカーの処理をより詳しく知りたい場合は、始めに cmd_log() の 実装を参照してください；git show v1.3.0~155^2~4 を実行し、その関数まで スクロールしてください(もはや setup_pager() を直接コールする必要がない 点に注意してください)。

現在では git log はビルトイン化されています(つまり、git コマンド内に含まれています)。 ビルトイン化されているソース部分は

時には１つのソースファイルに複数のビルトインが含まれていることがあります。 例えば、cmd_whatchanged() と cmd_log() はコードのかなりを共有しているため、 両方とも builtin-log.c 内に存在します。このような場合、コマンドは .c ファイルの名前で呼ばれず、Makefile 内の BUILT_INS 内に リストされている必要があります。

git log は 元のスクリプトがしていた内容よりも C の実装の方がより 複雑に見えますが、より高い柔軟性とパフォーマンス性を持っています。

ここまでで再び一息つくのにちょうど良い箇所です。

レッスン３はコードの観察です。(基本的な概念を学んだ後に) Git の構成を学ぶには これが一番良い方法です

興味のある内容を考えてください。たとえば "blob のオブジェクト名からどのように blob にアクセスするのだろう？"とか。 まず最初に、それを行う Git コマンドを見つけてください。この例では、 git show または git cat-file です。

明瞭にするため、git cat-file にしましょう。何故なら

builtin-cat-file.c を開き、cmd_cat_file() を探し出して、 何が行われているかを見てください。

明らかに細かな部分はスキップしましょう；ここで興味深い箇所は get_sha1() を読んでいる箇所です。ここではオブジェクト名である argv[2] を読み込み、もしそれが現在のリポジトリに存在するオブジェクトを参照している場合は その SHA-1 を変数 sha1 に代入します。

ここで興味深いのは次の２点です：

これらの両方をソースを通して確認できます。

さて、ここが核心です：

これが blob (実際のところ、blob だけでなくすべてのオブジェクト)を読む方法です。 この関数 read_object_with_reference() がどのように動くかを知る為には その部分のソースコードを git grep read_object_with | grep ":[a-z]" のように して見つけ出し、ソースを読むことです。

結果がどのように使用されるかを見つけるには、cmd_cat_file() 内を見ます：

時には機能の実装箇所を探し出すことができない場合があるかもしれません。 そのような場合には、git log の出力を探しだし、関連するコミットを git show すると手助けになるかもしれません。

例： git bundle に対するテストケースがあることは知っているが、 それがどこにあるかがわからない場合 (もちろん、git grep bundle t/ することも できますが、それではポイントを示すことになりません！)：

ページャ (less) 内で "bundle" を検索し、数行戻ると、 commit 18449ab0… にあるのがわかります。このオブジェクト名をコピーし コマンドラインにペーストします

ビンゴ！

次の例：スクリプトをビルトイン化するために必要な作業を調べるには：

ここまでに見てきたように、Git は Git 自身のソースを調べるときにも 最も役に立つツールなのです！

tar ボールから：

リモートのリポジトリから：

現在の HEAD (デフォルト)以外の場所から始まるブランチを作成するには、次のようにします：

新しいブランチの作成と切り替えを同時に行うには：

複製(clone)元のリポジトリのブランチを更新しテストするには：

他のリポジトリ上にあるブランチを取得(fetch)し、 そのブランチに対して名前を付けるには：

リポジトリの一覧を管理し、定期的にそこから変更を取得するには：

回帰点を探す：

誰の変更であるかを git に知らせる：

次のコミットに含めるファイルの内容を指定し、 コミットする：

コミットの準備と実行を一度に行う：

パッチをインポートし、エクスポートするには：

他の git リポジトリ内のブランチから変更を取得し、 現在のブランチにマージする：

現在のブランチにマージする前にローカルブランチに変更を格納する：

ローカルブランチ上でコミットした後に、リモートブランチに その内容を反映させる：

リモートブランチとローカルブランチの名前が両方とも "test" である場合：

よく使用するリモートリポジトリに対して略称を付ける：

破損していないか検査する：

リポジトリを圧縮し、使用していないゴミを削除する：