このマニュアルを読む際に実験するGitリポジトリがあると便利です。

取得する最良の方法は、git-clone[1]コマンドを使用して既存のリポジトリのコピーをダウンロードすることです。まだプロジェクトを考えていない場合は、いくつかの興味深い例を次に示します

大規模なプロジェクトの場合、最初のクローン作成には時間がかかる場合がありますが、クローン作成は1回だけですむはずです。

cloneコマンドは、プロジェクト（上記の例ではgitまたはlinux）の名前で新しいディレクトリを作成します。このディレクトリにcdすると、プロジェクトファイル（ワーキングツリーと呼ばれる）のコピーと、プロジェクトの履歴に関するすべての情報を含む.gitという名前の特別なトップレベルディレクトリが含まれていることがわかります。

Gitは、ファイルのコレクションの履歴を保存するためのツールとして考えるのが最適です。履歴は、プロジェクトの内容の相互に関連するスナップショットの圧縮されたコレクションとして保存します。Gitでは、そのような各バージョンをコミットと呼びます。

これらのスナップショットは必ずしも古いものから新しいものへと1列に並んでいるわけではありません。代わりに、作業はブランチと呼ばれる並行した開発ラインに沿って同時に進む場合があり、それらはマージと分岐を繰り返します。

単一のGitリポジトリで複数のブランチでの開発を追跡できます。これは、各ブランチの最新のコミットを参照するヘッドのリストを保持することによって行われます。git-branch[1]コマンドは、ブランチヘッドのリストを表示します

新しくクローンされたリポジトリには、「master」という名前の単一のブランチヘッドが含まれており、ワーキングディレクトリは、そのブランチヘッドが参照するプロジェクトの状態に初期化されています。

ほとんどのプロジェクトではタグも使用します。ヘッドと同様に、タグはプロジェクトの履歴への参照であり、git-tag[1]コマンドを使用して一覧表示できます

タグは常にプロジェクトの同じバージョンを指すことが期待されていますが、ヘッドは開発の進行に合わせて進むことが期待されています。

git-switch[1]を使用して、これらのバージョンのいずれかを指す新しいブランチヘッドを作成してチェックアウトします

ワーキングディレクトリは、プロジェクトがv2.6.13とタグ付けされたときのコンテンツを反映し、git-branch[1]は、現在チェックアウトされているブランチにアスタリスクが付いた2つのブランチを示します

バージョン2.6.17を表示したい場合は、代わりに次のコマンドを使用して、現在のブランチをv2.6.17を指すように変更できます

現在のブランチヘッドが履歴内の特定のポイントへの唯一の参照であった場合、そのブランチをリセットすると、以前指していた履歴を見つける方法がなくなる可能性があることに注意してください。したがって、このコマンドは注意して使用してください。

プロジェクトの履歴のすべての変更は、コミットで表されます。git-show[1]コマンドは、現在のブランチで最新のコミットを表示します

ご覧のとおり、コミットは誰が最新の変更を行ったか、何を行ったか、そしてその理由を示しています。

すべてのコミットには、40桁の16進数のIDがあり、「オブジェクト名」または「SHA-1 ID」と呼ばれることもあり、git show出力の最初の行に表示されます。通常、タグやブランチ名などの短い名前でコミットを参照できますが、この長い名前も役に立ちます。最も重要なことは、これはこのコミットのグローバルに一意の名前であることです。したがって、オブジェクト名を他の人に（たとえば、メールで）伝えると、その名前はあなたのリポジトリと同じように、そのリポジトリで同じコミットを参照することが保証されます（そのリポジトリにそのコミットがまったく含まれていると仮定した場合）。オブジェクト名はコミットの内容のハッシュとして計算されるため、名前も変更せずにコミットを変更することはできないことが保証されています。

実際、Gitの概念では、ファイルデータやディレクトリコンテンツを含むGit履歴に保存されているすべてのものは、コンテンツのハッシュである名前を持つオブジェクトに保存されることがわかります。

ブランチの作成、削除、変更は迅速かつ簡単に行えます。以下にコマンドの概要を示します。

特殊なシンボル「HEAD」は、常に現在のブランチを参照するために使用できます。実際、Gitは、どのブランチが現在のものかを記憶するために、.gitディレクトリにあるHEADという名前のファイルを使用します。

通常、git switch コマンドはブランチヘッドを期待しますが、--detach オプションを指定して呼び出すと、任意のコミットも受け入れます。たとえば、タグで参照されるコミットをチェックアウトできます。

この場合、HEADはブランチではなくコミットのSHA-1を参照し、git branchは、もはやブランチ上にいないことを示します。

この場合、HEADは「デタッチ」されていると言います。

これは、新しいブランチの名前を作成することなく、特定のバージョンを簡単にチェックアウトする方法です。必要に応じて、後でこのバージョンの新しいブランチ（またはタグ）を作成することもできます。

クローン時に作成された「master」ブランチは、クローン元のリポジトリのHEADのコピーです。ただし、そのリポジトリには他のブランチもあった可能性があり、ローカルリポジトリは、これらの各リモートブランチを追跡するブランチ（リモート追跡ブランチと呼ばれます）を保持しており、git-branch[1] の -r オプションを使用して表示できます。

この例では、「origin」はリモートリポジトリ、または略して「リモート」と呼ばれます。このリポジトリのブランチは、私たちの視点から「リモートブランチ」と呼ばれます。上記のリモート追跡ブランチは、クローン時のリモートブランチに基づいて作成され、git fetch（したがってgit pull）および git push によって更新されます。詳細については、git fetch を使用したリポジトリの更新を参照してください。

タグの場合と同じように、これらのリモート追跡ブランチのいずれかをベースにして、独自のブランチを作成することもできます。

origin/todo を直接チェックアウトして、それを調べたり、1回限りのパッチを作成したりすることもできます。デタッチされたHEAD を参照してください。

「origin」という名前は、クローン元のリポジトリを参照するためにGitがデフォルトで使用する名前であることに注意してください。

ブランチ、リモート追跡ブランチ、およびタグはすべてコミットへの参照です。すべての参照は、refs で始まるスラッシュ区切りのパス名で名前が付けられます。これまで使用してきた名前は、実際には省略形です。

たとえば、同じ名前のタグとブランチが存在する場合は、完全な名前が役立つ場合があります。

（新しく作成された参照は、実際には.git/refs ディレクトリに、その名前で指定されたパスの下に格納されます。ただし、効率上の理由から、単一のファイルにまとめてパックすることもできます。 git-pack-refs[1] を参照してください。）

もう1つの便利なショートカットとして、リポジトリの「HEAD」は、そのリポジトリの名前だけを使用して参照できます。したがって、たとえば、「origin」は通常、リポジトリ「origin」のHEADブランチのショートカットです。

Gitが参照をチェックするパスの完全なリスト、および同じ省略形名を持つ複数の参照がある場合にどれを選択するかを決定するために使用する順序については、gitrevisions[7] の「SPECIFYING REVISIONS」セクションを参照してください。

リポジトリをクローンして独自の変更をいくつかコミットした後、元のリポジトリに更新がないか確認したい場合があります。

git-fetch コマンドを引数なしで実行すると、すべてのリモート追跡ブランチが元のリポジトリで見つかった最新バージョンに更新されます。クローン時に作成された「master」ブランチでさえ、あなた自身のブランチには触れません。

git-remote[1] を使用して、クローン元のリポジトリ以外のリポジトリのブランチを追跡することもできます。

新しいリモート追跡ブランチは、git remote add で指定した省略形名、この場合は staging で保存されます。

後で git fetch <リモート> を実行すると、名前付きの <リモート> のリモート追跡ブランチが更新されます。

.git/config ファイルを調べると、Gitが新しいスタンザを追加したことがわかります。

これにより、Gitはリモートのブランチを追跡します。テキストエディターで .git/config を編集して、これらの設定オプションを変更または削除できます。（詳細については、git-config[1] の「CONFIGURATION FILE」セクションを参照してください。）

プロジェクトのバージョン2.6.18は動作したが、「master」のバージョンがクラッシュするとします。このような回帰の原因を見つけるための最良の方法は、プロジェクトの履歴を徹底的に検索して、問題を発生させた特定のコミットを見つけることです。git-bisect[1] コマンドは、これに役立ちます。

この時点で git branch を実行すると、Gitが一時的に「（ブランチなし）」に移動したことがわかります。HEADはブランチから切り離され、「master」から到達可能だがv2.6.18からは到達できないコミット（コミットID 65934）を直接指しています。コンパイルしてテストし、クラッシュするかどうかを確認します。クラッシュすると仮定します。次に

古いバージョンをチェックアウトします。このように続け、各段階でGitに、与えられたバージョンが良いか悪いかを伝え、テストする残りのリビジョンの数が毎回ほぼ半分に減っていることに注意してください。

約13回のテスト（この場合）の後、犯人のコミットのコミットIDが出力されます。次に、git-show[1] でコミットを調べて、誰が書いたかを確認し、コミットIDを使用してバグレポートを送信できます。最後に、実行します

前にいたブランチに戻ります。

git bisect が各時点でチェックアウトするバージョンは単なる提案であり、良いアイデアだと思われる場合は、別のバージョンを試すことができます。たとえば、関連のないものを壊したコミットにたどり着くことがあります。実行します

これによりgitkが実行され、「bisect」というマーカーが選択したコミットに付けられます。近くにある安全そうなコミットを選択し、そのコミットIDをメモして、次のようにチェックアウトします。

次にテストし、必要に応じて bisect good または bisect bad を実行して続行します。

git bisect visualize を実行してから git reset --hard fb47ddb2db を実行する代わりに、Gitに現在のコミットをスキップしたいと伝えるだけでよい場合があります。

ただし、この場合、Gitは最終的に、いくつかの最初にスキップされたコミットと後で発生した悪いコミットとの間の最初の悪いコミットを特定できない可能性があります。

優れたコミットと悪いコミットを区別できるテストスクリプトがある場合は、二分探索プロセスを自動化する方法もあります。これおよびその他の git bisect 機能の詳細については、git-bisect[1] を参照してください。

これまでにコミットに名前を付ける方法をいくつか見てきました。

他にもたくさんあります。リビジョンに名前を付ける方法の完全なリストについては、gitrevisions[7] のマニュアルページの「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] コマンドは、コミットのリストを表示できます。単独で使用すると、親コミットから到達可能なすべてのコミットが表示されます。ただし、より具体的なリクエストも行うことができます。

もちろん、これらをすべて組み合わせることもできます。次の例は、Makefile または fs 配下のファイルに変更を加えた v2.5 以降のコミットを検索します。

git log にパッチを表示させることもできます。

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

git log は最新のコミットから開始して親をたどって遡ることに注意してください。ただし、Git の履歴には複数の独立した開発ラインが含まれる可能性があるため、コミットがリストされる特定の順序は多少恣意的になる場合があります。

git-diff[1] を使用して、任意の 2 つのバージョン間の差分を生成できます。

これにより、2 つのブランチの先端間の差分が生成されます。共通の祖先からの差分を検出する場合は、2 つのドットの代わりに 3 つのドットを使用できます。

代わりにパッチのセットが必要な場合は、git-format-patch[1] を使用できます。

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

適切なリビジョンを最初にチェックアウトするだけで、常に古いバージョンのファイルを表示できます。しかし、何もチェックアウトせずに単一のファイルの古いバージョンを表示できる方が便利な場合があります。このコマンドはそれを実現します。

コロンの前にはコミットを指す任意の名前を指定でき、後には Git で追跡されているファイルへの任意のパスを指定できます。

コミットを作成する前に、Git に自己紹介する必要があります。最も簡単な方法は git-config[1] を使用することです。

これにより、ホームディレクトリにある .gitconfig という名前のファイルに以下が追加されます。

構成ファイルの詳細については、git-config[1] の「構成ファイル」セクションを参照してください。ファイルはプレーンテキストなので、お気に入りのエディタで編集することもできます。

ゼロから新しいリポジトリを作成するのは非常に簡単です。

初期コンテンツ (たとえば、tarball) がある場合は、

新しいコミットを作成するには、3 つの手順が必要です。

実際には、ステップ 1 と 2 を何度でも繰り返すことができます。ステップ 3 でコミットしたいものを追跡するために、Git は「インデックス」と呼ばれる特別なステージング領域にツリーのコンテンツのスナップショットを保持します。

最初は、インデックスの内容は HEAD の内容と同じになります。したがって、HEAD とインデックスの差分を表示するコマンド git diff --cached では、その時点では出力は生成されないはずです。

インデックスの変更は簡単です。

新しいファイルまたは変更されたファイルの内容でインデックスを更新するには、次を使用します。

インデックスとワーキングツリーからファイルを削除するには、次を使用します。

各ステップの後で、以下を確認できます。

常に HEAD とインデックスファイルの差分を表示します。これは、今コミットを作成した場合にコミットされる内容です。

ワーキングツリーとインデックスファイルの差分を表示します。

git add は常にファイルの現在の内容のみをインデックスに追加することに注意してください。同じファイルにさらに変更を加えた場合は、ファイルに対して再度 git add を実行しない限り、無視されます。

準備ができたら、次を実行します。

Git はコミットメッセージの入力を求め、新しいコミットを作成します。次のコマンドで、期待どおりになっていることを確認してください。

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

変更または削除したファイルをインデックスに追加し、コミットを作成する操作をすべて1ステップで実行できます。

コミットしようとしている内容を把握するために役立つコマンドがいくつかあります。

また、git-gui[1] を使用して、コミットの作成、インデックスと作業ツリーのファイルの変更内容の確認、インデックスに含める diff の範囲を個別に選択できます（diff の範囲を右クリックして「コミット用に Hunk をステージ」を選択）。

必須ではありませんが、コミットメッセージは、変更内容を要約した短い（50文字以内）1行で始め、その後に空白行、さらに詳しい説明を記述するのが良い習慣です。コミットメッセージの最初の空白行までのテキストはコミットタイトルとして扱われ、Git 全体で使用されます。例えば、git-format-patch[1] はコミットをメールに変換しますが、その際、タイトルを Subject 行に、コミットの残りの部分を本文に使用します。

プロジェクトでは、Git で追跡したくないファイルが生成されることがよくあります。これには通常、ビルドプロセスで生成されたファイルや、エディタが作成する一時バックアップファイルなどが含まれます。もちろん、ファイルを Git で追跡しないのは、単にそれらのファイルに対して git add を呼び出さないだけのことです。しかし、これらの追跡されていないファイルが散らかっていると、すぐに面倒になります。例えば、git add . が実質的に使い物にならなくなり、git status の出力に常に表示され続けることになります。

作業ディレクトリのトップレベルに .gitignore というファイルを作成し、以下のような内容を記述することで、Git に特定のファイルを無視させることができます。

構文の詳細については、gitignore[5] を参照してください。.gitignore ファイルは作業ツリー内の他のディレクトリにも配置でき、それらのディレクトリとサブディレクトリに適用されます。.gitignore ファイルは他のファイルと同様にリポジトリに追加できます（通常どおり git add .gitignore と git commit を実行します）。これは、除外パターン（ビルド出力ファイルに一致するパターンなど）が、リポジトリをクローンする他のユーザーにとっても意味がある場合に便利です。

除外パターンを特定のプロジェクトのリポジトリのみに適用したい場合（すべてのリポジトリではなく）、代わりにリポジトリ内の .git/info/exclude というファイル、または core.excludesFile 設定変数で指定された任意のファイルに記述できます。一部の Git コマンドでは、コマンドラインで直接除外パターンを指定することもできます。詳細については、gitignore[5] を参照してください。

git-merge[1] を使用して、開発の 2 つの分岐を再結合できます。

これにより、ブランチ branchname での開発が現在のブランチにマージされます。

マージは、branchname で行われた変更と、現在のブランチの最新コミットまでに行われた変更を、それらの履歴が分岐した時点から結合することで作成されます。この結合がクリーンに行われた場合、作業ツリーはマージの結果で上書きされ、結合でコンフリクトが発生した場合は、半分マージされた結果で上書きされます。そのため、マージの影響を受けるファイルと同じファイルに変更がコミットされていない場合、Git は処理を拒否します。ほとんどの場合、マージを行う前に変更をコミットする必要があります。コミットしない場合は、git-stash[1] を使用して、マージ中にこれらの変更を一時的に退避させ、後で再適用できます。

変更内容が十分に独立している場合、Git は自動的にマージを完了し、結果をコミットします（または、fast-forward の場合は既存のコミットを再利用します。下記参照）。一方、コンフリクトが発生した場合（例えば、リモートブランチとローカルブランチで同じファイルが異なる方法で変更された場合）、警告が表示されます。出力は次のようになる可能性があります。

コンフリクトマーカーが問題のあるファイルに残されるため、手動でコンフリクトを解決した後、内容をインデックスに追加して Git コミットを実行できます。これは、新しいファイルを作成する場合と同じです。

gitk を使用して結果のコミットを調べると、2 つの親があることがわかります。1 つは現在のブランチの先頭を指し、もう 1 つはもう一方のブランチの先頭を指します。

マージが自動的に解決されない場合、Git はインデックスと作業ツリーを、マージを解決するために必要なすべての情報を提供する特別な状態にします。

コンフリクトのあるファイルはインデックス内で特別にマークされるため、問題を解決してインデックスを更新するまで、git-commit[1] は失敗します。

また、git-status[1] はこれらのファイルを「unmerged」と表示し、コンフリクトのあるファイルには次のようなコンフリクトマーカーが追加されます。

必要なのは、ファイルを編集してコンフリクトを解決し、次のコマンドを実行することだけです。

コミットメッセージには、マージに関する情報が既に入力されていることに注意してください。通常、このデフォルトメッセージをそのまま使用できますが、必要に応じて独自のコメントを追加することもできます。

上記は、単純なマージを解決するために知っておくべきすべてのことです。しかし、Git はコンフリクトを解決するためのより多くの情報も提供します。

行き詰まって、すべてをあきらめて混乱を解消したい場合は、次のコマンドを使用して、マージ前の状態に戻ることができます。

または、削除したいマージを既にコミットしている場合は、

ただし、この最後のコマンドは、場合によっては危険な可能性があります。コミットが他のブランチにマージされている可能性がある場合は、既にコミットしたコミットを削除しないでください。そうすると、その後のマージが混乱する可能性があります。

上記で言及されていない特別なケースが1つあり、これは異なる方法で処理されます。通常、マージでは、2つの親を持つマージコミットになります。1つはマージされた開発の2つのラインのそれぞれを指します。

ただし、現在のブランチがもう一方のブランチの祖先である場合（つまり、現在のブランチに存在するすべてのコミットが既に他のブランチに含まれている場合）、Git は「fast-forward」を実行します。現在のブランチのヘッドは、新しいコミットを作成せずに、マージされたブランチのヘッドを指すように前進します。

作業ツリーを混乱させてしまい、まだ間違いをコミットしていない場合は、次のコマンドを使用して、作業ツリー全体を最後にコミットされた状態に戻すことができます。

後でコミットを後悔した場合、問題を修正するには、根本的に異なる 2 つの方法があります。

大規模なリポジトリでは、Gitは履歴情報がディスクやメモリ上で過剰な容量を占有しないように圧縮に依存しています。一部のGitコマンドはgit-gc[1]を自動的に実行する場合があるため、手動で実行することを気にする必要はありません。ただし、大規模なリポジトリの圧縮には時間がかかる場合があるため、都合の悪いときに自動圧縮が開始されるのを避けるために、明示的にgcを呼び出すことをお勧めします。

リポジトリをクローンし、いくつかの変更をコミットした後、元のリポジトリで更新を確認し、それらを自分の作業にマージしたい場合があります。

git-fetch[1]を使用してリモート追跡ブランチを最新の状態に保つ方法と、2つのブランチをマージする方法をすでに見てきました。したがって、元のリポジトリのmasterブランチからの変更をマージするには、次のようにします。

ただし、git-pull[1]コマンドを使用すると、これを1つのステップで実行できます。

実際、masterをチェックアウトしている場合、このブランチはgit cloneによって、originリポジトリのHEADブランチから変更を取得するように構成されています。したがって、多くの場合、上記の処理は単純な

で実行できます。このコマンドは、リモートブランチからリモート追跡ブランチorigin/*に変更をフェッチし、デフォルトブランチを現在のブランチにマージします。

一般的に、リモート追跡ブランチから作成されたブランチは、デフォルトでそのブランチからプルします。これらのデフォルトを制御する方法については、git-config[1]のbranch.<name>.remoteおよびbranch.<name>.mergeオプションの説明と、git-checkout[1]の--trackオプションの説明を参照してください。

キー入力回数を減らすことに加えて、git pullは、プルしたブランチとリポジトリを文書化したデフォルトのコミットメッセージを生成することで役立ちます。

（ただし、fast-forwardの場合、このようなコミットは作成されないことに注意してください。代わりに、ブランチはアップストリームブランチの最新のコミットを指すように更新されるだけです。）

git pullコマンドには、「リモート」リポジトリとして.を指定することもできます。この場合、現在のリポジトリからブランチをマージするだけなので、次のコマンド

はほぼ同等です。

変更点がわずかな場合は、メールでパッチとして送信するのが最も簡単な方法かもしれません。

まず、git-format-patch[1]を使用します。たとえば、

は、現在のブランチにはあるがorigin/HEADにはない各パッチについて、番号付きの一連のファイルを現在のディレクトリに生成します。

git format-patchには、最初の「カバーレター」を含めることができます。コミットメッセージの後、ただしパッチ自体の前にある、format-patchが配置する3つのダッシュ行の後に、個々のパッチに関する注釈を挿入できます。git notesを使用してカバーレターの資料を追跡する場合は、git format-patch --notesを使用すると、同様の方法でコミットのノートが含められます。

その後、これらをメールクライアントにインポートして、手動で送信できます。ただし、一度に大量に送信する必要がある場合は、git-send-email[1]スクリプトを使用してプロセスを自動化することをお勧めします。パッチを送信するための要件を決定するために、最初にプロジェクトのメーリングリストに相談してください。

Gitには、このような電子メールで送信された一連のパッチをインポートするためのgit-am[1]（amは「apply mailbox」の略）と呼ばれるツールも用意されています。すべてのパッチを含むメッセージを順番に単一のメールボックスファイル（たとえば、patches.mbox）に保存し、次を実行します。

Gitは各パッチを順番に適用します。競合が見つかった場合は停止し、「マージの解決」の説明に従って競合を修正できます。（-3オプションは、Gitにマージを実行するように指示します。ツリーとインデックスをそのままにして中止するだけでよい場合は、そのオプションを省略できます。）

インデックスが競合解決の結果で更新されたら、新しいコミットを作成する代わりに、次を実行します。

Gitがコミットを作成し、メールボックスから残りのパッチの適用を続行します。

最終結果は、元のメールボックスの各パッチに対して1つずつの一連のコミットになり、各パッチを含むメッセージから作成者とコミットログメッセージが取得されます。

プロジェクトに変更を送信する別の方法は、git-pull[1]を使用して、プロジェクトのメンテナーに自分のリポジトリから変更をプルするように指示することです。「git pullで更新を取得する」セクションでは、これを「メイン」リポジトリから更新を取得する方法として説明しましたが、反対方向にも同様に機能します。

あなたとメンテナーの両方が同じマシン上にアカウントを持っている場合は、お互いのリポジトリから直接変更をプルできます。リポジトリURLを引数として受け入れるコマンドは、ローカルディレクトリ名も受け入れます。

またはssh URL

開発者が少ないプロジェクトや、いくつかのプライベートリポジトリを同期する場合、これは必要なすべてである可能性があります。

ただし、これを行う一般的な方法は、変更をプルするための別のパブリックリポジトリ（通常は別のホスト上）を維持することです。これは通常より便利であり、プライベートな作業中の作業を公開されている作業から明確に分離できます。

個人的なリポジトリで日々の作業を継続しますが、定期的に個人的なリポジトリからパブリックリポジトリに変更を「プッシュ」し、他の開発者がそのリポジトリからプルできるようにします。したがって、パブリックリポジトリを持つ別の開発者がいる場合の変更の流れは次のようになります。

これを行う方法については、次のセクションで説明します。

履歴が切り捨てられた浅いクローンは、プロジェクトの最近の履歴のみに関心があり、アップストリームから完全な履歴を取得するのに費用がかかる場合に役立ちます。

浅いクローンは、git-clone[1] --depthスイッチを指定して作成されます。深さは、git-fetch[1] --depthスイッチで後で変更したり、--unshallowで完全な履歴を復元したりできます。

浅いクローン内でのマージは、マージベースが最近の履歴にある限り機能します。それ以外の場合は、関連性のない履歴をマージするようなもので、大きな競合が発生する可能性があります。この制限により、このようなリポジトリは、マージベースのワークフローでの使用には適さない可能性があります。

あなたが大規模プロジェクトのコントリビューターであり、複雑な機能を追加し、他の開発者が変更を読みやすく、正当性を検証し、各変更を加えた理由を理解しやすい方法で提示したいとします。

すべての変更を単一のパッチ（またはコミット）として提示すると、一度にすべてを理解するには量が多すぎると感じるかもしれません。

間違い、修正、行き詰まりを含めた作業の全履歴を提示すると、彼らは圧倒されるかもしれません。

したがって、理想的なのは通常、次のようなパッチのシリーズを作成することです。

これを行うのに役立つツールをいくつか紹介し、その使用方法を説明し、履歴を書き換えることによって発生する可能性のある問題の一部を説明します。

リモート追跡ブランチorigin上にブランチmyworkを作成し、その上にいくつかのコミットを作成すると仮定します

myworkにマージは実行していないため、originの上のパッチの単純な線形シーケンスにすぎません

上流プロジェクトでより興味深い作業が行われ、originが進んでいます

この時点で、pullを使用して変更をマージし直すことができます。結果は、次のような新しいマージコミットを作成します

ただし、myworkの履歴をマージのない単純なコミットのシリーズとして維持したい場合は、代わりにgit-rebase[1]を使用することを選択できます

これにより、myworkから各コミットが削除され、（.git/rebase-applyという名前のディレクトリに）パッチとして一時的に保存され、myworkがoriginの最新バージョンを指すように更新されてから、保存された各パッチが新しいmyworkに適用されます。結果は次のようになります

その過程で、競合が見つかる可能性があります。その場合、それは停止し、あなたが競合を修正できるようにします。競合を修正した後、git addを使用してインデックスをそれらのコンテンツで更新し、git commitを実行する代わりに、次を実行します

すると、Gitは残りのパッチの適用を継続します。

いつでも、--abortオプションを使用してこのプロセスを中止し、リベースを開始する前の状態にmyworkを戻すことができます

ブランチで多数のコミットを並べ替えたり編集したりする必要がある場合は、git rebase -iを使用すると、コミットを並べ替えたり、まとめたり、リベース中に個別に編集するようにマークしたりできるため、簡単になる場合があります。詳細については、インタラクティブなリベースの使用、および代替案についてはパッチシリーズの並べ替えまたは選択を参照してください。

履歴を書き換えて間違いを修正するで見たように、次のコマンドを使用して、最新のコミットを置き換えることができます。

これにより、古いコミットが変更を組み込んだ新しいコミットで置き換えられ、最初に古いコミットメッセージを編集する機会が得られます。これは、最後のコミットのタイプミスを修正したり、適切にステージングされていないコミットのパッチの内容を調整したりするのに役立ちます。

履歴の奥深くからコミットを修正する必要がある場合は、インタラクティブなリベースのedit命令を使用できます。

場合によっては、履歴の奥深くにあるコミットを編集したい場合があります。1つのアプローチは、git format-patchを使用して一連のパッチを作成し、その後、パッチ前の状態にリセットすることです

次に、必要に応じてパッチを変更、並べ替え、削除してから、git-am[1]で再度適用します

インタラクティブなリベースを使用してパッチシリーズを編集することもできます。これは、format-patchを使用したパッチシリーズの並べ替えと同じであるため、最も気に入ったインターフェースを使用してください。

現在のHEADを、そのまま保持したい最後のコミットに対してリベースします。たとえば、最後の5つのコミットを並べ替えたい場合は、次を使用します

これにより、リベースを実行するために実行される手順のリストがエディターで開きます。

コメントで説明されているように、リストを編集することで、コミットの並べ替え、それらの結合、コミットメッセージの編集などができます。満足したら、リストを保存してエディターを閉じると、リベースが開始されます。

リベースは、pickがeditに置き換えられた場所、またはリスト内のステップが機械的に競合を解決できず、あなたの助けが必要な場合に停止します。編集および/または競合の解決が完了したら、git rebase --continueで続行できます。物事が複雑になりすぎると判断した場合は、常にgit rebase --abortで中断できます。リベースが完了した後でも、reflogを使用して元のブランチを復元できます。

手順と追加のヒントの詳細については、git-rebase[1]の「インタラクティブモード」セクションを参照してください。

パッチシリーズを維持する目的で、StGitなど、他にも多くのツールがあります。これらは、このマニュアルの範囲外です。

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

次に、最後の3つのコミットを変更すると仮定します

この履歴全体を1つのリポジトリでまとめて調べると、次のようになります

Gitには、新しいヘッドが古いヘッドの更新バージョンであることを知る方法はありません。この状況は、2人の開発者が古いヘッドと新しいヘッドで並行して独立して作業を行った場合とまったく同じように扱います。この時点で、誰かが新しいヘッドを自分のブランチにマージしようとすると、Gitは古い開発ラインと新しい開発ラインの2つをマージしようとし、古いものを新しいものに置き換えようとしません。結果は予期しないものになる可能性があります。

履歴が書き換えられたブランチを公開することを選択できます。他の人がそれらのブランチをフェッチして調べたりテストしたりできると役立つかもしれませんが、そのようなブランチを自分の作業にプルしようとすべきではありません。

適切なマージをサポートする真の分散開発の場合、公開されたブランチを書き換えるべきではありません。

git-bisect[1]コマンドは、マージコミットを含む履歴を正しく処理します。ただし、検出されるコミットがマージコミットである場合、そのコミットがなぜ問題を引き起こしたのかを理解するために、ユーザーは通常よりも苦労する必要がある場合があります。

この履歴を想像してください

上の開発ラインでは、Zに存在する関数の1つの意味がコミットXで変更されたと仮定します。ZからAにつながるコミットは、関数の実装と、Zに存在するすべての呼び出しサイト、およびそれらが追加する新しい呼び出しサイトの両方を、一貫性があるように変更します。Aにはバグはありません。

その間に、下の開発ラインでは、誰かがコミットYでその関数の新しい呼び出しサイトを追加したと仮定します。ZからBにつながるすべてのコミットは、その関数の古いセマンティクスを前提としており、呼び出し側と呼び出し先は互いに一貫性があります。Bにもバグはありません。

さらに、2つの開発ラインがCでクリーンにマージされるため、競合の解決は必要ないと仮定します。

それにもかかわらず、Cのコードは壊れています。下の開発ラインで追加された呼び出し元が、上の開発ラインで導入された新しいセマンティクスに変換されていないためです。したがって、Dが悪いこと、Zが良いこと、およびgit-bisect[1]がCを原因として識別することだけがわかっている場合、問題がこのセマンティクスの変更によるものであることをどのように理解するのでしょうか？

git bisectの結果が非マージコミットの場合、通常は、そのコミットを調べるだけで問題を検出できるはずです。開発者は、変更を自己完結型の小さなコミットに分割することで、これを簡単にすることができます。ただし、上記の場合、問題は単一のコミットの調査からは明らかではないため、役立ちません。代わりに、開発のグローバルなビューが必要です。さらに悪いことに、問題のある関数のセマンティクスの変更は、上の開発ラインの変更の一部にすぎない可能性があります。

一方、Cでマージする代わりに、ZからBの間の履歴をAの上にリベースした場合、この線形履歴が得られたはずです

ZとD*の間でバイセクトすると、単一の犯人コミットY*がヒットし、Y*が壊れていた理由を理解するのがおそらく簡単になります。

部分的にはこのため、経験豊富な多くのGitユーザーは、他の点ではマージが多いプロジェクトで作業している場合でも、公開する前に最新の上流バージョンに対してリベースすることにより、履歴を線形に保ちます。

git-remote[1] を使用する代わりに、一度に1つのブランチだけを更新し、任意の名前でローカルに保存することもできます。

最初の引数 origin は、最初にクローンしたリポジトリからフェッチするように Git に指示するだけです。2番目の引数は、リモートリポジトリから todo という名前のブランチをフェッチし、refs/heads/my-todo-work という名前でローカルに保存するように Git に指示します。

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

は、example-master という名前の新しいブランチを作成し、指定されたURLにあるリポジトリの master という名前のブランチをそこに保存します。すでに example-master という名前のブランチがある場合、example.comのmasterブランチによって指定されたコミットに高速巻き戻しを試みます。より詳しく説明すると、

前の例では、既存のブランチを更新するとき、git fetch は、リモートブランチの最新のコミットが、ブランチのコピーの最新のコミットの子孫であることを確認してから、ブランチのコピーを新しいコミットを指すように更新します。Gitは、このプロセスを高速巻き戻しと呼びます。

高速巻き戻しは、次のようになります。

場合によっては、新しいヘッドが実際には古いヘッドの子孫ではないことがあります。例えば、開発者が重大なミスを犯したことに気づき、バックトラックすることにした場合、次のような状況になります。

この場合、git fetch は失敗し、警告を出力します。

その場合でも、次のセクションで説明するように、Gitに新しいヘッドへの更新を強制できます。ただし、上記の状況では、a と b というラベルの付いたコミットを失う可能性があることに注意してください。ただし、それらを指す独自の参照をすでに作成している場合は除きます。

ブランチの新しいヘッドが古いヘッドの子孫ではないために git fetch が失敗した場合、次のように更新を強制できます。

+ 符号の追加に注意してください。または、-f フラグを使用して、フェッチされたすべてのブランチの更新を強制することもできます。例：

前のセクションで見たように、example/master の古いバージョンが指していたコミットは失われる可能性があることに注意してください。

上記で説明したように、origin は、最初にクローンしたリポジトリを参照するためのショートカットにすぎません。この情報は、git-config[1]を使用して確認できる Git 構成変数に格納されています。

頻繁に使用する他のリポジトリがある場合は、同様の構成オプションを作成して、入力の手間を省くことができます。例えば、

は、.git/configに以下を追加します。

また、上記の構成は、git-remote[1]を使用する代わりに、ファイル .git/config を直接編集することによって実行できることにも注意してください。

リモートを設定した後、次の3つのコマンドは同じことを実行します。

上記の構成オプションの詳細についてはgit-config[1]を、refspec構文の詳細についてはgit-fetch[1]を参照してください。

履歴の理解：コミットですでに見たように、すべてのコミットは40桁の「オブジェクト名」で保存されます。実際、プロジェクトの履歴を表すために必要なすべての情報は、このような名前を持つオブジェクトに保存されます。各場合、名前はオブジェクトの内容のSHA-1ハッシュを取得することによって計算されます。SHA-1ハッシュは、暗号化ハッシュ関数です。私たちにとってそれが意味することは、同じ名前を持つ2つの異なるオブジェクトを見つけることは不可能だということです。これには、いくつかの利点があります。とりわけ

（オブジェクトのフォーマットとSHA-1計算の詳細については、オブジェクトストレージ形式を参照してください。）

オブジェクトには、「blob」、「tree」、「commit」、「tag」の4つの異なるタイプがあります。

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

インデックスは、パス名のソートされたリストを含むバイナリファイル（通常は `.git/index` に保持されます）であり、それぞれにアクセス許可とブロブオブジェクトの SHA-1 が含まれています。 git-ls-files[1]を使用すると、インデックスの内容を表示できます。

古いドキュメントでは、インデックスが「現在のディレクトリキャッシュ」または単に「キャッシュ」と呼ばれている場合があります。これには3つの重要な特性があります。

したがって、インデックスは一種の一時的なステージング領域であり、作業中のツリーで満たされています。

インデックスを完全に吹き飛ばした場合でも、それが記述したツリーの名前を持っている限り、一般に情報は失われていません。

常に、サブモジュールの変更を公開してから、それを参照するスーパープロジェクトの変更を公開してください。サブモジュールの変更の公開を忘れると、他のユーザーはリポジトリをクローンできなくなります。

古いGitバージョンでは、サブモジュール内の新しいファイルまたは変更されたファイルをコミットするのを簡単に忘れる可能性があり、サブモジュールの変更をプッシュしない場合と同様の問題が静かに発生していました。Git 1.7.0 以降では、スーパープロジェクトの git status と git diff の両方で、新しいファイルまたは変更されたファイルが含まれている場合、サブモジュールが変更済みとして表示されるため、このような状態の誤ったコミットを防止できます。また、git diff はパッチ出力を生成するとき、または --submodule オプションで使用するとき、作業ツリー側で -dirty を追加します。

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

最初にブランチをチェックアウトせずにサブモジュール内で変更を加え、コミットした場合、git submodule update を実行するのは安全ではありません。それらは静かに上書きされます。

サブモジュールの作業ツリーにコミットされていない変更がある場合、git submodule update はそれらを上書きしません。代わりに、ダーティなブランチから切り替えることができないという通常の警告が表示されます。

git-cat-file[1] コマンドは、任意のオブジェクトの内容を表示できますが、通常はより高レベルの git-show[1] の方が便利です。

git-commit-tree[1] コマンドを使用すると、任意の親とツリーを持つコミットを構築できます。

ツリーは git-write-tree[1] で作成でき、そのデータには git-ls-tree[1] でアクセスできます。2つのツリーは git-diff-tree[1] で比較できます。

タグは git-mktag[1] で作成され、署名は git-verify-tag[1] で検証できますが、通常は両方に git-tag[1] を使用する方が簡単です。

git-commit[1] や git-restore[1] などの高レベル操作は、作業ツリー、インデックス、およびオブジェクトデータベースの間でデータを移動することで機能します。Gitは、これらの各ステップを個別に実行する低レベルの操作を提供します。

一般的に、すべてのGit操作はインデックスファイルで動作します。一部の操作はインデックスファイルのみで動作しますが（インデックスの現在の状態を表示）、ほとんどの操作はインデックスファイルとデータベースまたは作業ディレクトリの間でデータを移動します。したがって、4つの主な組み合わせがあります。

オブジェクトデータベースとインデックスで表されるデータは、さまざまなヘルパーツールで検査できます。すべてのオブジェクトについて、git-cat-file[1] を使用してオブジェクトに関する詳細を調べることができます。

オブジェクトの型を示します。型がわかれば（通常、オブジェクトが見つかる場所で暗黙的にわかります）、以下を使用できます。

その内容を表示します。注意！ツリーはバイナリコンテンツを持ちます。そのため、バイナリコンテンツをより読みやすい形式に変換するgit ls-treeという特別なヘルパーがあります。

特に「commit」オブジェクトを見ることは有益です。これらは小さく、かなり自明な傾向があるからです。特に、.git/HEADにトップコミット名を置くという慣習に従うと、以下を実行できます。

トップコミットが何だったかを確認できます。

Gitは3方向マージを実行するのに役立ちます。これは、マージ手順を数回繰り返すことで、多方向マージに使用できます。通常は、1つの3方向マージ（2つの履歴の行を調整する）のみを行い、結果をコミットしますが、必要であれば、複数のブランチを一度にマージできます。

3方向マージを実行するには、マージする2つのコミットから始め、それらの最も近い共通の親（3番目のコミット）を見つけ、これらの3つのコミットに対応するツリーを比較します。

マージの「ベース」を取得するには、2つのコミットの共通の親を検索します。

これにより、両方が基づいているコミットの名前が出力されます。次に、これらのコミットのツリーオブジェクトを検索する必要があります。これは以下で簡単に行えます。

ツリーオブジェクトの情報は常にコミットオブジェクトの最初の行にあるからです。

マージする3つのツリー（1つの「オリジナル」ツリー、つまり共通ツリー、および2つの「結果」ツリー、つまりマージするブランチ）がわかったら、インデックスに「マージ」を読み込みます。これにより、古いインデックスの内容を破棄する必要がある場合は不平を言うため、それらをコミットしていることを確認する必要があります。実際には、通常、常に最後のコミットに対してマージを行います（したがって、現在のインデックスにあるものと一致する必要があります）。

マージを実行するには、以下を実行します。

これにより、すべての簡単なマージ操作がインデックスファイル内で直接実行され、git write-treeで結果を書き出すことができます。

残念ながら、多くのマージは簡単ではありません。ファイルが追加、移動、削除された場合、または両方のブランチが同じファイルを変更した場合、インデックスツリーには「マージエントリ」が含まれたままになります。このようなインデックスツリーはツリーオブジェクトに書き出すことができません。結果を書き出す前に、他のツールを使用して、そのようなマージの競合を解決する必要があります。

git ls-files --unmergedコマンドを使用して、このようなインデックスの状態を調べることができます。例：

git ls-files --unmergedの出力の各行は、ブロブモードビット、ブロブSHA-1、ステージ番号、およびファイル名で始まります。ステージ番号は、どのツリーから来たかをGitが示す方法です。ステージ1は$origツリーに対応し、ステージ2はHEADツリーに対応し、ステージ3は$targetツリーに対応します。

以前に、簡単なマージはgit read-tree -m内で実行されると述べました。たとえば、ファイルが$origからHEADまたは$targetに変更されなかった場合、またはファイルが$origからHEADおよび$origから$targetに同じ方法で変更された場合、明らかに最終結果はHEADにあるものです。上記の例が示すのは、ファイルhello.cが$origからHEADに、そして$origから$targetに異なる方法で変更されたということです。お気に入りの3方向マージプログラム（例：diff3、merge、またはGit独自のmerge-file）を、これらの3つのステージからのブロブオブジェクトに対して、次のように実行することで、これを解決できます。

これにより、マージの結果はhello.c~2ファイルに残り、競合がある場合は競合マーカーも残ります。マージの結果が理にかなっていることを確認した後、このファイルの最終的なマージ結果をGitに伝えることができます。

パスが「unmerged」状態の場合、そのパスに対してgit update-indexを実行すると、Gitにパスが解決済みとしてマークするように指示します。

上記は、Gitマージの最低レベルでの説明であり、概念的に何が起こっているかを理解するのに役立ちます。実際には、Git自体でさえ、このためにgit cat-fileを3回実行することはありません。ステージを一時ファイルに抽出し、その上で「マージ」スクリプトを呼び出すgit merge-indexプログラムがあります。

そして、それが上位レベルのgit merge -s resolveが実装されているものです。

すべてのオブジェクトには、オブジェクトの形式（つまり、その使用方法や、他のオブジェクトを参照する方法）を識別する静的に決定された「型」があります。現在、4つの異なるオブジェクト型があります。「blob」、「tree」、「commit」、および「tag」です。

オブジェクト型に関係なく、すべてのオブジェクトは次の特性を共有します。それらはすべてzlibでデフレートされ、型を指定するだけでなく、オブジェクト内のデータに関するサイズ情報も提供するヘッダーを持っています。オブジェクトの名前付けに使用されるSHA-1ハッシュは、元のデータにこのヘッダーを加えたもののハッシュであるため、sha1sum ファイルは、ファイルのオブジェクト名と一致しないことに注意してください（Gitの初期バージョンは少し異なるハッシュを行いましたが、結論は同じです）。

以下は、これらのハッシュを手動で生成する方法を示す簡単な例です。

単純なコンテンツを含む小さなテキストファイルを想定しましょう。

これで、Gitがこのファイルに使用するハッシュを手動で生成できます。

この手動で作成されたハッシュは、もちろんヘッダーの追加を隠すgit hash-objectを使用して検証できます。

その結果、オブジェクトの一般的な整合性は、オブジェクトの内容や型とは関係なく、常に独立してテストできます。すべてのオブジェクトは、（a）ハッシュがファイルの内容と一致すること、および（b）オブジェクトが<スペースなしのASCII型> + <スペース> + <ASCIIの10進数サイズ> + <バイト\0> + <バイナリオブジェクトデータ>のシーケンスを形成するバイトストリームに正常にインフレートされることを検証することで検証できます。

構造化されたオブジェクトは、構造と他のオブジェクトへの接続をさらに検証できます。これは通常、すべてのオブジェクトの完全な依存関係グラフを生成し、内部整合性（ハッシュによる表面的な整合性の検証に加えて）を検証するgit fsckプログラムで行われます。

新しい開発者がGitのソースコードを理解するのは必ずしも簡単ではありません。このセクションでは、どこから始めるかを示すために少しガイダンスを提供します。

始めるのに適した場所は、初期コミットの内容です。以下を使用します。

最初のリビジョンは、今日のGitが持つほとんどすべての基盤を築きます（いくつかの場所では詳細が異なる場合もあります）が、一度に読んで理解できるほど小さいです。

用語は、そのリビジョン以降に変更されていることに注意してください。たとえば、そのリビジョンのREADMEでは、「changeset」という単語を、現在コミットと呼んでいるものを説明するために使用しています。

また、現在は「キャッシュ」とは呼ばず、「インデックス」と呼びます。ただし、ファイルは依然としてread-cache.hと呼ばれます。

その最初のコミットのアイデアを理解したら、より最近のバージョンをチェックアウトして、read-cache-ll.h、object.h、およびcommit.hをざっと見てください。

初期の頃、Gitは（UNIXの伝統では）非常に単純なプログラムの集まりであり、スクリプトで使用し、あるプログラムの出力を別のプログラムにパイプしました。これは、新しいことをテストするのが簡単であったため、初期開発に適していることがわかりました。ただし、最近、これらのパーツの多くは組み込みになり、コアの一部は、パフォーマンス、移植性の理由、およびコードの重複を避けるために「ライブラリ化」つまりlibgit.aに入れられました。

今のところ、インデックスが何であるか（そしてread-cache-ll.hに対応するデータ構造を見つける）、そして共通の構造をstruct objectから継承するオブジェクト型（ブロブ、ツリー、コミット、タグ）がほんの一握りしかないこと（したがって、たとえば(struct object *)commitを&commit->objectと同じようにキャストして、オブジェクト名とフラグを取得できること）がわかります。

ここで、この情報を消化するために休憩するのに良い機会です。

次のステップ：オブジェクトの命名に慣れること。 コミットの命名をお読みください。オブジェクトを命名する方法は多数あります（リビジョンだけではありません！）。これらはすべてsha1_name.cで処理されます。関数get_sha1()をざっと見てください。特殊な処理の多くは、get_sha1_basic()のような関数によって行われます。

これは、Gitの最もライブラリ化された部分、つまりリビジョンウォーカーの調子を整えるためのものです。

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

これはどういう意味ですか？

git rev-listはリビジョンウォーカーの元のバージョンであり、常にリビジョンのリストをstdoutに出力しました。これは現在でも機能しており、ほとんどの新しいGitコマンドがgit rev-listを使用するスクリプトとして開始されるため、必要です。

git rev-parseは以前ほど重要ではなくなりました。スクリプトによって呼び出された異なる配管コマンドに関連するオプションをフィルタリングするためにのみ使用されていました。

git rev-listが行っていたことのほとんどは、revision.cとrevision.hに含まれています。これは、rev_infoという名前の構造体でオプションをラップします。これにより、リビジョンがどのように、何をウォークするかなどを制御します。

元々 git rev-parse が行っていた処理は、現在では setup_revisions() 関数が担っており、この関数がリビジョンとリビジョンウォーカーの共通コマンドラインオプションを解析します。この情報は、後で使用するために rev_info 構造体に格納されます。setup_revisions() を呼び出した後、独自のコマンドラインオプション解析を行うことができます。その後、初期化のために prepare_revision_walk() を呼び出す必要があり、それから get_revision() 関数を使用してコミットを1つずつ取得できます。

リビジョンウォーキングのプロセスについてさらに詳しく知りたい場合は、cmd_log() の最初の実装を見てください。git show v1.3.0~155^2~4 を呼び出して、その関数までスクロールしてください（setup_pager() を直接呼び出す必要はなくなりました）。

現在、git log は組み込みコマンドであり、これは git コマンドに *含まれている* ことを意味します。組み込みコマンドのソース側は、

複数の組み込みコマンドが1つのソースファイルに含まれている場合があります。たとえば、cmd_whatchanged() と cmd_log() はどちらも builtin/log.c に存在します。これは、それらがかなりの量のコードを共有しているためです。その場合、自身が存在する .c ファイルと同じ名前ではないコマンドは、Makefile の BUILT_INS にリストする必要があります。

git log は、元のスクリプトよりもC言語で記述する方が複雑に見えますが、それによって柔軟性とパフォーマンスが大幅に向上します。

ここでも、一旦立ち止まる良い機会です。

レッスン3は、「コードを勉強すること」です。本当に、Gitの組織について学ぶ最良の方法です（基本的な概念を理解した後）。

そこで、「オブジェクト名だけを知って、どうすればblobにアクセスできるのだろうか？」など、興味のあることを考えてみましょう。最初のステップは、それを行うことができるGitコマンドを見つけることです。この例では、git show または git cat-file のどちらかです。

明確にするために、git cat-file に絞りましょう。なぜなら、

したがって、builtin/cat-file.c を見て、cmd_cat_file() を検索し、それが何をするかを確認してください。

明らかな詳細は省略します。ここで本当に興味深いのは、get_sha1() の呼び出しです。これは argv[2] をオブジェクト名として解釈しようとし、それが現在のリポジトリに存在するオブジェクトを参照している場合、結果の SHA-1 を変数 sha1 に書き込みます。

ここで2つの点が興味深いです。

これらの両方のケースがコード全体で見られます。

さて、本題に入りましょう。

これが、blob（実際にはblobだけでなく、任意の型のオブジェクト）を読み取る方法です。read_object_with_reference() 関数が実際にどのように動作するかを知るには、そのソースコードを見つけ（Gitリポジトリで git grep read_object_with | grep ":[a-z]" のようなコマンドを実行します）、ソースを読んでください。

結果をどのように使用できるかを知るには、cmd_cat_file() を読み進めてください。

機能を探す場所がわからない場合があります。そのような場合は、git log の出力を検索してから、対応するコミットを git show で表示すると役立ちます。

例：git bundle のテストケースがあったことは知っているが、どこにあったか覚えていない場合（そうです、git grep bundle t/ もできますが、それではポイントを説明できません！）。

ページャー（less）で「bundle」を検索し、数行戻ると、コミット 18449ab0 にあることがわかります。このオブジェクト名をコピーしてコマンドラインに貼り付けるだけです。

はい、おしまい。

別の例：スクリプトを組み込みコマンドにするために何をすべきかを調べてください。

ほら、Gitは実際にはGit自身のソースコードについて調べるための最適なツールなのです！

tarballから

リモートリポジトリから

新しいブランチを現在のHEAD（デフォルト）に基づいて作成する代わりに、以下を使用します。

同時に新しいブランチを作成して切り替える

クローンしたリポジトリからブランチを更新および調査する

別のリポジトリからブランチをフェッチし、自分のリポジトリで新しい名前を付ける

定期的に作業するリポジトリのリストを保持する

リグレッションを検索する

Gitが誰を非難するかを確実に把握する

次のコミットに含めるファイルの内容を選択し、コミットを作成する

または、1ステップでコミットを準備して作成する

パッチのインポートまたはエクスポート

異なるGitリポジトリのブランチを取得し、現在のブランチにマージする

現在のブランチにマージする前に、取得したブランチをローカルブランチに保存する

ローカルブランチでコミットを作成した後、リモートブランチを自分のコミットで更新する

リモートブランチとローカルブランチの両方が "test" という名前の場合

頻繁に使用するリモートリポジトリのショートカットバージョン

破損のチェック

再圧縮、未使用の不要なものを削除

これは作業中です。

基本的な要件

必ずしも間のすべてを読まなくても、重要なトピックにたどり着くことができるような、明確な章の依存関係グラフを作成する方法を考えてください。

Documentation/をスキャンして、他に抜け落ちているものがないか確認します。特に

メールアーカイブをスキャンして、他に抜け落ちているものがないか確認します

このマニュアルが提供する以上の背景知識を前提とするものがないか、マニュアルページをスキャンします。

もっと良い例を追加します。クックブックの例だけのセクション全体が良いかもしれません。「高度な例」セクションを章末の標準セクションにすることもできますか？

必要に応じて、用語集への相互参照を含めます。

CVS、Subversion、およびリリースtarballのインポートだけを含む、他のバージョン管理システムとの連携に関するセクションを追加します。

配管の使用とスクリプトの作成に関する章を書きます。

代替、clone -referenceなど。

リポジトリの破損からの復旧について。以下を参照してください：https://lore.kernel.org/git/Pine.LNX.4.64.0702272039540.12485@woody.linux-foundation.org/ https://lore.kernel.org/git/Pine.LNX.4.64.0702141033400.3604@woody.linux-foundation.org/