このマニュアルを読みながら実験するために、Gitリポジトリがあると便利です。

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

大規模なプロジェクトの場合、最初のクローンには時間がかかる場合がありますが、クローンは一度だけ行う必要があります。

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

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

これらのスナップショットは、必ずしもすべてが最も古いものから最も新しいものまで単一の線上に配置されているわけではありません。代わりに、ブランチと呼ばれる並行開発ラインに沿って作業が同時に進行し、マージと分岐が行われる場合があります。

単一の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のコピーです。ただし、そのリポジトリには他のブランチがあった可能性もあり、ローカルリポジトリはそれらのリモートブランチのそれぞれを追跡するブランチ、つまりリモート追跡ブランチを保持しており、-rオプションを付けてgit-branch[1]を使用することで表示できます。

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

タグの場合と同様に、これらのリモート追跡ブランチのいずれかを独自のブランチで構築したい場合があります。

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

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

ブランチ、リモート追跡ブランチ、タグはすべてコミットへの参照です。すべての参照はrefsで始まるスラッシュ区切りのパス名で命名されています。これまでに使用してきた名前は実際には短縮形です。

フルネームは、たとえば、同じ名前のタグとブランチが共存する場合など、時々役立ちます。

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

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

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

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

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

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

新しいリモート追跡ブランチは、git remote addに指定した短縮名（この場合はstaging）の下に保存されます。

後で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が与えるバージョンが良いか悪いかを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] manページの「SPECIFYING REVISIONS」セクションを参照してください。いくつかの例を挙げます。

マージコミットには複数の親がある場合があることを思い出してください。デフォルトでは、^と~はコミットにリストされている最初の親に従いますが、選択することもできます。

HEADに加えて、コミットには他にもいくつかの特殊な名前があります。

マージ（後述）や、現在チェックアウトされているコミットを変更するgit resetなどの操作は、通常、現在の操作前のHEADの値をORIG_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]を使用して、任意の2つのバージョン間の差分を生成できます。

これにより、2つのブランチの先端間の差分が生成されます。共通の祖先からテストまでの差分を見つけたい場合は、2つの点ではなく3つの点を使用できます。

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

は、testから到達可能だがmasterからは到達可能ではない各コミットのパッチを含むファイルを現在のディレクトリに生成します。

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

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

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

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

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

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

初期コンテンツがある場合（例えば、tarball）、

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

実際には、ステップ1と2を好きなだけ交互に繰り返すことができます。ステップ3でコミットしたい内容を追跡するために、Gitは「インデックス」と呼ばれる特別なステージングエリアにツリーのコンテンツのスナップショットを保持しています。

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

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

新規または変更されたファイルの内容でインデックスを更新するには、

インデックスおよびワーキングツリーからファイルを削除するには、

各ステップの後、次のことを確認できます。

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

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

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

準備ができたら、単に

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

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

は、変更または削除されたすべてのファイルをインデックスに更新し、コミットを作成します。これらすべてを一度に行います。

コミットしようとしているものを追跡するのに役立つコマンドがいくつかあります。

git-gui[1]を使用して、コミットを作成したり、インデックスおよびワーキングツリーファイルの変更を表示したり、個々の差分ハンクをインデックスに含めるために選択したり（差分ハンクを右クリックして「Stage Hunk For Commit」を選択する）こともできます。

必須ではありませんが、コミットメッセージは、変更の概要をまとめた短い（50文字以内）1行で始め、その後に空行を挟んで、より詳細な説明を続けるのが良い習慣です。コミットメッセージの最初の空行までのテキストはコミットのタイトルとして扱われ、そのタイトルはGit全体で使用されます。たとえば、git-format-patch[1]はコミットを電子メールに変換し、件名行にタイトルを、残りのコミットを本文に使用します。

プロジェクトでは、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は自動的にマージを完了し、結果をコミットします（または、早送りの場合、既存のコミットを再利用します。以下を参照）。一方、競合がある場合、たとえば、リモートブランチとローカルブランチで同じファイルが2つの異なる方法で変更された場合、警告が表示されます。出力は次のようになります。

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

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

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

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

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

競合を解決するためにファイルを編集し、その後、次のコマンドを実行するだけです。

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

上記は、単純なマージを解決するために知っておくべきすべてのことです。しかし、Gitは競合の解決に役立つさらに多くの情報を提供します。

行き詰まってしまい、この混乱をすべて諦めて破棄することにした場合は、いつでも次のコマンドでマージ前の状態に戻ることができます。

または、破棄したいマージをすでにコミットしている場合、

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

上記で述べられていない特別なケースが1つあり、それは異なって扱われます。通常、マージは2つの親を持つマージコミットを生成します。各親はマージされた2つの開発ラインのいずれかを指します。

しかし、現在のブランチが他のブランチの祖先である場合、つまり、現在のブランチに存在するすべてのコミットがすでに他のブランチに含まれている場合、Gitは単に「早送り」を実行します。現在のブランチのヘッドは、新しいコミットが作成されることなく、マージされたブランチのヘッドを指すように前方に移動します。

ワーキングツリーを台無しにしてしまったが、まだ間違いをコミットしていない場合は、次のコマンドでワーキングツリー全体を最後のコミットされた状態に戻すことができます。

後でコミットしなければよかったと思うコミットをしてしまった場合、問題を修正するには根本的に異なる2つの方法があります。

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

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

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

ただし、git-pull[1]コマンドはこれを1つのステップで行う方法を提供します。

実際、masterをチェックアウトしている場合、このブランチはgit cloneによって、オリジンリポジトリのHEADブランチから変更を取得するように構成されています。したがって、多くの場合、単純に次のコマンドで上記の操作を実行できます。

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

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

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

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

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

はほぼ同等です。

変更が少ない場合、それらを提出する最も簡単な方法は、電子メールでパッチとして送信することかもしれません。

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

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

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つのコミットのシリーズとなり、作成者とコミットログメッセージはそれぞれ各パッチを含むメッセージから取得されます。

プロジェクトに変更を提出するもう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命令を使用できます。

履歴の深い部分にあるコミットを編集したい場合があります。一つの方法は、git format-patchを使用して一連のパッチを作成し、その後、パッチの前の状態にリセットすることです。

その後、git-am[1]で再度適用する前に、必要に応じてパッチを修正、並べ替え、または削除します。

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

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

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

コメントで説明されているように、リストを編集することでコミットの順序を変更したり、それらをまとめたり、コミットメッセージを編集したりできます。満足したら、リストを保存してエディタを閉じると、リベースが開始されます。

リベースは、pickがeditに置き換えられた箇所、またはリストのステップが機械的に競合を解決できず、あなたの助けが必要な箇所で停止します。編集や競合の解決が完了したら、git rebase --continueで続行できます。状況が複雑になりすぎていると感じた場合は、いつでもgit rebase --abortで中止できます。リベースが完了した後でも、reflogを使用すれば元のブランチを回復できます。

手順と追加のヒントの詳細については、git-rebase[1]の「INTERACTIVE MODE」セクションを参照してください。

StGitなど、パッチシリーズの管理を目的とした多くのツールがあります。これらはこのマニュアルの範囲外です。

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

次に、最後の3つのコミットを修正したとします。

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

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

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

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

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

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

開発の上流ラインで、Zに存在する関数の意味がコミット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番目の引数は、Gitにリモートリポジトリからtodoという名前のブランチをフェッチし、それをrefs/heads/my-todo-workという名前でローカルに保存するように指示します。

他のリポジトリからブランチをフェッチすることもできます。したがって、

は、example-masterという新しいブランチを作成し、指定されたURLのリポジトリからmasterというブランチをそこに格納します。既にexample-masterというブランチがある場合、example.comのmasterブランチで指定されたコミットにfast-forwardしようとします。より詳しく説明すると、

前の例では、既存のブランチを更新する際に、git fetchは、リモートブランチの最新コミットが、ブランチのコピーを新しいコミットを指すように更新する前に、そのブランチのコピーの最新コミットの子孫であることを確認します。Gitはこのプロセスをfast-forwardと呼びます。

fast-forwardは次のようなものです。

場合によっては、新しいヘッドが実際に古いヘッドの子孫ではないことがあります。例えば、開発者が重大な間違いを犯したことに気づき、巻き戻すことを決定し、次のような状況になった場合です。

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

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

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

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

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

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

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

は、.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 があり、バイナリコンテンツをより読みやすい形式に変換します。

「コミット」オブジェクトは小さく、かなり自己説明的な傾向があるため、特に参考になります。具体的には、.git/HEAD に一番上のコミット名を持つ慣習に従っていれば、次のことができます。

一番上のコミットが何であったかを確認するには。

Gitはスリーウェイマージの実行を支援し、それはマージ手順を数回繰り返すことで多方向マージにも使用できます。通常は、1回のスリーウェイマージ（2つの履歴線を調整する）を行って結果をコミットしますが、必要であれば、複数のブランチを一度にマージできます。

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

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

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

ツリーオブジェクト情報は常にコミットオブジェクトの最初の行に記載されているため。

マージする3つのツリー (「元の」ツリー、つまり共通のツリー、および2つの「結果」ツリー、つまりマージしたいブランチ) がわかったら、「マージ」読み込みをインデックスに実行します。これにより、古いインデックスの内容を破棄する必要がある場合に警告が表示されるため、それらをコミット済みであることを確認する必要があります。実際、通常は常に最後のコミットに対してマージを実行します (そのため、現在のインデックスにあるものと一致するはずです)。

マージを実行するには

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

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

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

git ls-files --unmerged の各行は、blobモードビット、blob 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つのステージのblobオブジェクトに対して自分で実行することで解決できます。以下のように。

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

パスが「未マージ」状態にある場合、そのパスに対して 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 file はfile のオブジェクト名と一致しません（Gitの初期バージョンはわずかに異なるハッシュ化を行っていましたが、結論は同じです）。

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

いくつかの単純なコンテンツを持つ小さなテキストファイルを想定しましょう。

このファイルにGitが使用するハッシュを手動で生成できるようになりました。

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

その結果、オブジェクトの一般的な整合性は、オブジェクトの内容や種類に関係なく常にテストできます。すべてのオブジェクトは、(a) ハッシュがファイルの内容と一致すること、および (b) オブジェクトが正常に展開されて <ascii-type-without-space> + <space> + <ascii-decimal-size> + <byte\0> + <binary-object-data> のシーケンスを形成するバイトストリームになることを検証することで検証できます。

構造化されたオブジェクトは、その構造と他のオブジェクトへの接続性をさらに検証することができます。これは通常、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 はリビジョンウォーカーのオリジナルバージョンで、常にリビジョンのリストを標準出力に表示していました。ほとんどの新しい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言語では元のスクリプトよりも複雑に見えますが、これによりはるかに高い柔軟性とパフォーマンスが得られます。

ここでも、一旦休憩するのに良いタイミングです。

レッスン３：コードを勉強する。本当に、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が誰を非難すべきかを知っていることを確認する

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

または、コミットを一度に準備して作成する

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

別のGitリポジトリのブランチをフェッチし、現在のブランチにマージします。

フェッチしたブランチをローカルブランチに保存してから、現在のブランチにマージする

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

リモートブランチとローカルブランチがどちらも「test」という名前の場合

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

破損がないか確認する

再圧縮、不要なごみの削除

これは進行中の作業です。

基本的な要件

人々が途中のすべてを読む必要なく重要なトピックにたどり着けるような、明確な章の依存関係グラフを作成する方法を考えること。

Documentation/ をスキャンして、抜け落ちた他のものを探す。特に、

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

このマニュアルが提供する以上の背景知識を仮定している man ページがないか確認する。

さらに良い例を追加する。クックブック形式の例だけのセクション全体が良いかもしれません。おそらく「高度な例」セクションを標準的な章の終わりに置くのはどうでしょう？

適切な箇所に用語集への相互参照を含める。

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

プラミングの使用とスクリプトの書き方に関する章を書く。

代替、クローン -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/