このマニュアルを読むときに、Gitリポジトリを試してみると便利です。

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

        # Git itself (approx. 40MB download):
$ git clone git://git.kernel.org/pub/scm/git/git.git
        # the Linux kernel (approx. 640MB download):
$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

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

cloneコマンドは、プロジェクトにちなんで名付けられた新しいディレクトリを作成します(上記の例では git または linux)。このディレクトリにcdすると、 working tree と呼ばれるプロジェクトファイルのコピーと、プロジェクトの歴史について全ての情報を含む .git という名前の特別なトップレベルディレクトリが含まれていることがわかります。

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

これらのスナップショットは、必ずしもすべてが古いものから新しいものへと一列に配置されているわけではなく、作業は、 branches と呼ばれる並行する開発ラインに沿って同時に進行する場合があります。これは、マージおよび分岐する場合があります。

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

$ git branch
* master

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

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

$ git tag -l
v2.6.11
v2.6.11-tree
v2.6.12
v2.6.12-rc2
v2.6.12-rc3
v2.6.12-rc4
v2.6.12-rc5
v2.6.12-rc6
v2.6.13
...

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

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

$ git switch -c new v2.6.13

作業ディレクトリは、v2.6.13 のタグが付けられたときにプロジェクトが持っていた内容を反映し、 git-branch(1) は2つのブランチを表示し、アスタリスクは現在チェックアウトされているブランチを示します。

$ git branch
  master
* new

あなたがバージョン 2.6.17 を使用することにした場合は、以下のようにして、代わりに v2.6.17 を指すように現在のブランチを変更できます。

$ git reset --hard v2.6.17

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

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

$ git show
commit 17cf781661e6d38f737f15f53ab552f1e95960d7
Author: Linus Torvalds <torvalds@ppc970.osdl.org.(none)>
Date:   Tue Apr 19 14:11:06 2005 -0700

    Remove duplicate getenv(DB_ENVIRONMENT) call

    Noted by Tony Luck.

diff --git a/init-db.c b/init-db.c
index 65898fa..b002dc6 100644
--- a/init-db.c
+++ b/init-db.c
@@ -7,7 +7,7 @@

 int main(int argc, char **argv)
 {
-       char *sha1_dir = getenv(DB_ENVIRONMENT), *path;
+       char *sha1_dir, *path;
        int len, i;

        if (mkdir(".git", 0755) < 0) {

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

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

実際、 Chapter 7, Gitの概念 では、ファイルデータやディレクトリの内容など、Gitの履歴に保存されているすべてのものが、その内容のハッシュである名前が付いたオブジェクトに保存されていることがわかります。

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

ブランチの作成、削除、および変更は、素早く・簡単です。コマンドの概要は以下のとおりです:

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

$ cat .git/HEAD
ref: refs/heads/master

git switch コマンドは通常、ブランチヘッドを想定していますが、 --detach を伴って呼び出されると任意のコミットも受け入れます。たとえば、タグによって参照されるコミットをチェックアウトできます:

$ git switch --detach v2.6.17
Note: checking out 'v2.6.17'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another switch.
(あなたは「切り離されたHEAD」状態にあります。あなたは周りを見回し、
実験的な変更を加えてコミットすることができます。また、別のswitchを実行することで、
他のブランチに影響を与えることなく、この状態で行ったコミットを破棄できます。)

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command again. Example:
(作成したコミットを保持するために新しいブランチを作成する場合は、
switchコマンドで `-c` を再度使用して、(現在または後で)作成できます。例:)

  git switch -c new_branch_name

HEAD is now at 427abfa Linux v2.6.17

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

$ cat .git/HEAD
427abfa28afedffadfca9dd8b067eb6d36bac53f
$ git branch
* (detached from v2.6.17)
  master

この場合、HEADは「切り離されている」(detached)と言います。

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

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

$ git branch -r
  origin/HEAD
  origin/html
  origin/maint
  origin/man
  origin/master
  origin/next
  origin/seen
  origin/todo

この例では、「origin」はリモートリポジトリ、または略して「リモート」(remote)と呼ばれます。このリポジトリのブランチは、私たちの観点からは「リモートブランチ」と呼ばれます。上記のリモート追跡ブランチは、クローン時にリモートブランチに基づいて作成され、 git fetch (つまり git pull でも)と git push によって更新されます。 詳細については、 the section called “Updating a repository with git fetch” を参照してください。

タグの場合と同じように、これらのリモート追跡ブランチの1つをあなた独自のブランチに構築することをお勧めします:

$ git switch -c my-todo-copy origin/todo

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

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

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

フルネームでの指定は、たとえば、同じ名前のタグとブランチが存在する場合に役立つことがあります。

(新しく作成されたrefは、実際にはその名前で指定されたパスで .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://git.kernel.org/.../gregkh/staging.git
$ git fetch staging
...
From git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging
 * [new branch]      master     -> staging/master
 * [new branch]      staging-linus -> staging/staging-linus
 * [new branch]      staging-next -> staging/staging-next

新しいリモート追跡ブランチは、 git remote add にて、今回は staging と名付けた省略名で保存されます:

$ git branch -r
  origin/HEAD -> origin/master
  origin/master
  staging/master
  staging/staging-linus
  staging/staging-next

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

ファイル .git/config を調べると、Gitが新しい一節を追加したことがわかります:

$ cat .git/config
...
[remote "staging"]
        url = git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
        fetch = +refs/heads/*:refs/remotes/staging/*
...

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

あなたのプロジェクトのバージョン2.6.18は機能していしたが、「master」のバージョンがクラッシュしたとします。このようなデグレの原因を見つける最良の方法は、プロジェクトの履歴を総当たりで検索して、問題の原因となった特定のコミットを見つけることです。 git-bisect(1) コマンドは、あなたがこれを行う助けとなります:

$ git bisect start
$ git bisect good v2.6.18
$ git bisect bad master
Bisecting: 3537 revisions left to test after this
[65934a9a028b88e83e2b0f8b36618fe503349f8e] BLOCK: Make USB storage depend on SCSI rather than selecting it [try #6]

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

$ git bisect bad
Bisecting: 1769 revisions left to test after this
[7eff82c8b1511017ae605f0c99ac275a7e21b867] i2c-core: Drop useless bitmaskings

より古いバージョンをチェックアウトします。このように作業を続けて、各ステップで提供されるバージョンが良いか悪いかをGitに伝え、テストするために残されたリビジョンの数が毎回約半分に削減されることに注目してください。

(今回は)約13回のテストの後、有罪コミット(guilty commit)のコミットIDが出力されました。あなたは、次に、 git-show(1) を使用してコミットを調べ、誰がコミットを作成したかを調べ、コミットIDを使用してバグレポートをメールで送信できます。そして最後に、あなたは以下を実行します:

$ git bisect reset

そうすると、あなたが以前にいたブランチに戻ります。

注意: git bisect が各時点でチェックアウトするバージョンは単なる提案であり、そっちの方が良い考えであると思った場合は、別のバージョンを自由に試すことができることに注意してください。 たとえば、関係のない何かを壊したコミットにたどり着くことがあったりします。このようにしたいときは、以下のようにします。

$ git bisect visualize

これはgitkを実行し、選択したコミットに「bisect」というマーカーでラベルを付けます。近くで安全に見えるコミットを選択し、そのコミットIDをメモして、以下のコマンドでチェックアウトします:

$ git reset --hard fb47ddb2db

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

git bisect visualize と git reset --hard fb47ddb2db を行う代わりに、現在のコミットをスキップすることをGitに伝えたい場合があります:

$ git bisect skip

ただし、この場合、Gitは、最初にスキップされたコミットとその後の不正なコミットの間で、最初の不正なコミットを最終的に判断できない可能性があります。

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

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

その他いろいろ: リビジョンに名前を付ける方法の完全なリストについては、 gitrevisions(7) のマニュアルページの「SPECIFYING REVISIONS」セクションを参照してください。 例をいくつか:

$ git show fb47ddb2 # オブジェクト名の最初の数文字は、
                    # 通常、一意に指定するのに十分です。
$ git show HEAD^    # HEADコミットの親
$ git show HEAD^^   # 祖父母(grandparent;親の親)
$ git show HEAD~4   # 曽祖父母(great-great-grandparent)

マージコミットには複数の親が存在する可能性があることを思い出してください。 デフォルトでは、 ^ と ~ はそのコミットにリストされている最初の親を辿りますが、以下のように選択することもできます:

$ git show HEAD^1   # HEADの(複数ある)親のうち1番目の親
$ git show HEAD^2   # HEADの複数ある親のうち2番目の親

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

マージ(後で説明します)、および現在チェックアウトされているコミットを変更する git reset などの操作では、通常、 ORIG_HEAD を、「現在の操作の前にHEADが持っていた値」に設定します。

git fetch 操作は、常に、最後にフェッチされたブランチのヘッドをFETCH_HEADに格納します。 たとえば、以下のように、操作のターゲットとしてローカルブランチを指定せずに git fetch を実行した場合

$ git fetch git://example.com/proj.git theirbranch

フェッチされたコミットは、引き続きFETCH_HEADから利用できます。

マージについて説明すると、現在のブランチにマージしている他のブランチを指す特別な名前MERGE_HEADもあります。

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

$ git rev-parse origin
e05db0fd4f31dde7005f075a84f96b360d05984b

特定のコミットを参照するタグを作成することもできます。以下を実行すると

$ git tag stable-1 1b2e1d63ff

あなたは stable-1 を使用して、コミット 1b2e1d63ff を参照できます。

これにより、「軽量」タグ(lightweight tag)が作成されます。タグにコメントを含め、場合によっては暗号で署名する場合は、代わりにタグオブジェクトを作成する必要があります。詳細については、 git-tag(1) のマニュアルページを参照してください。

git-log(1) コマンドは、コミットのリストを表示できます。それ自体で、親コミットから到達可能なすべてのコミットが表示されますが、より具体的なリクエストを行うこともできます。

$ git log v2.5..        # commits since (not reachable from) v2.5
$ git log test..master  # commits reachable from master but not test
$ git log master..test  # ...reachable from test but not master
$ git log master...test # ...reachable from either test or master,
                        #    but not both
$ git log --since="2 weeks ago" # commits from the last 2 weeks
$ git log Makefile      # commits which modify Makefile
$ git log fs/           # ... which modify any file under fs/
$ git log -S'foo()'     # commits which add or remove any file data
                        # matching the string 'foo()'

そしてもちろん、これらすべてを組み合わせることができます。 以下は、 Makefile または fs ディレクトリより下の任意のファイル、を触った v2.5 以降のコミットを検索します:

$ git log v2.5.. Makefile fs/

パッチを表示するようにgit logに依頼することもできます:

$ git log -p

その他の表示オプションについては、 git-log(1) のマニュアルページの --pretty オプションを参照してください。

git log は最新のコミットから始まり、親を介して逆方向に機能することに注意してください。 ただし、Gitの履歴には複数の独立した開発ラインが含まれる可能性があるため、コミットがリストされる順序は多少前後する可能性があります。

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

$ git diff master..test

これにより、2つのブランチの先端の間にdiffが生じます。共通の祖先からのdiffを見つけてテストしたい場合は、2つではなく3つのドットを使用できます:

$ git diff master...test

しばしば、あなたが必要なのは差分の代わりにパッチのセットである場合があります。これには、 git-format-patch(1) を使用できます。

$ git format-patch master..test

これは、masterからではなく、testから到達可能な各コミットのパッチを含むファイルを生成します。

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

$ git show v2.5:fs/locks.c

コロン(:)の前にはコミットを指定するものがあり、その後にはGitによって追跡されているファイルへのパスがあります。

コミットを作成する前に、あなた自身をGitに紹介すべきです。これを行う最も簡単な方法は、 git-config(1) を使用することです:

$ git config --global user.name 'Your Name Comes Here'
$ git config --global user.email 'you@yourdomain.example.com'

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

[user]
        name = Your Name Comes Here
        email = you@yourdomain.example.com

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

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

$ mkdir project
$ cd project
$ git init

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

$ tar xzvf project.tar.gz
$ cd project
$ git init
$ git add . # include everything below ./ in the first commit:
$ git commit

新しいコミットの以下の3つのステップがあります:

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

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

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

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

$ git add path/to/file

インデックスと作業ツリーからファイルを削除するには、以下を使用します

$ git rm path/to/file

各ステップの後、あなたは以下のようにして確認できます

$ git diff --cached

常にHEADとインデックスファイルの違い示します(つまり、今、この時点でコミットを作成した場合、何がコミットされる事になるのかを知る事ができます)

$ git diff

これは、作業ツリーとインデックスファイルの違いを示しています。

注意: git add は常に、ファイルのその時点での内容をインデックスに追加するだけであることに注意してください。同じファイルに対して git add を再度実行しない限り、そのファイルへのその後の編集変更は無視されます。

準備ができたら、あとは実行するだけです

$ git commit

Gitはコミットメッセージの入力を求め、新しいコミットを作成します。以下のようにして、それがあなたが期待したもののように見えることをチェックしてください

$ git show

特別な省略形として、以下があります

$ git commit -a

これは、変更または削除したファイルでインデックスを更新し、コミットを作成します。それらを1ステップで実行します。

あなたの行ったコミットを追跡するために、いくつかのコマンドが役立ちます

$ git diff --cached # HEADとインデックス間の差異。
                    # 今、コミットを実行したら何がコミットされるかを知る。
$ git diff          # インデックスファイルと作業ディレクトリの違い。
                    # 今、コミットを実行したら、
                    # 何がそのコミットに「含まれない」かを知る。
$ git diff HEAD     # HEADと作業ツリーの違い。
                    # 今、 `commit -a` を実行したら何がコミットされるかを知る。
$ git status        # 上記のファイルごとの簡単な要約。

git-gui(1) を使用して、コミットを作成し、インデックスと作業ツリーファイルの変更を表示し、インデックスに含めるdiffハンクを個別に選択することもできます(diffハンクを右クリックして「Stage Hunk For Commit」を選択します)。

必須ではありませんが、変更を要約した1行の短い行(50文字未満)でコミットメッセージを開始し、その後に空行を続け、さらに詳細な説明を続けることをお勧めします。 コミットメッセージの最初の空行までのテキストはコミットタイトルとして扱われ、そのタイトルはGit全体で使用されます。たとえば、 git-format-patch(1) はコミットを電子メールに変換し、コミットタイトルを件名に使用し、コミットタイトル以降を本文として使用します。

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

あなたは、作業ディレクトリの最上位に .gitignore というファイルを作成し、以下のような内容で特定のファイルを無視するようにGitに指示できます:

# '＃'で始まる行はコメントと見なされます。
# foo.txtという名前のファイルはすべて無視してください。
foo.txt
# (生成された) htmlファイルを無視します。
*.html
# 但し、手作業で管理されているfoo.htmlを除きます(無視しません)。
!foo.html
# オブジェクト(*.o)とアーカイブ(*.a)を無視します。
*.[oa]

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

除外パターンが(特定のプロジェクトのすべてのリポジトリではなく、)特定のリポジトリにのみ影響するようにする場合は、代わりに、リポジトリ内の .git/info/exclude という名前のファイル、または core.excludesFile 構成変数で指定されたファイルに除外パターンを配置できます。一部のGitコマンドは、コマンドラインで直接除外パターンを指定することもできます。詳細については、 gitignore(5) を参照してください。

git-merge(1)を使用して、2つに分岐したブランチを再結合できます:

$ git merge branchname

ブランチ branchname を現在のブランチにマージします。

マージは、 branchname で行われた変更と、履歴が分岐してから現在のブランチで最新のコミットまでに行われた変更とを組み合わせることによって行われます。作業ツリーは、この結合がクリーンに実行された場合はマージの結果によって上書きされ、この結合が競合を引き起こした場合は半マージ(half-merged)された結果によって上書きされます。したがって、マージの影響を受けたファイルと同じファイルに変更を加えたコミットされていない変更がある場合、Gitは続行を拒否します。ほとんどの場合、マージする前に変更をコミットする必要があります。コミットしない場合は、 git-stash(1) を使用すると、マージ中にこれらの変更を一旦取り除いて、後で再適用できます。

変更が十分に独立している場合、Gitは自動的にマージを完了し、結果をコミットします(または、fast-forwardの場合は、既存のコミットを再利用します。これについては以下を参照してください)。 一方、競合がある場合—たとえば、リモートブランチとローカルブランチで同じファイルが異なる方法で変更された場合—は警告が表示されます。出力は以下のようになります:

$ git merge next
 100% (4/4) done
Auto-merged file.txt
CONFLICT (content): Merge conflict in file.txt
Automatic merge failed; fix conflicts and then commit the result.

問題のあるファイルには競合マーカーが残ります(訳注:つまり そのファイルは git merge が編集したものです)。あなたは競合を手動で解決した後(訳注:当該ファイルを手動で編集してセーブして)、新しいファイルを作成するときと同じように、インデックスを更新してGit commitを実行できます。

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

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

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

$ git commit
file.txt: needs merge

また、 git-status(1) は、これらのファイルを "unmerged" としてリストし、競合のあるファイルの内容には、以下のように競合マーカー(conflict marker)が追加されます(訳注:ファイルの内容が以下のように変更されます):

<<<<<<< HEAD:file.txt
Hello world
=======
Goodbye
>>>>>>> 77976da35a11db4580b80ae27e8d65caf5208086:file.txt

あなたしなければならないことは、競合を解決するためにファイルを編集することです。そしてその後、以下のようにします。

$ git add file.txt
$ git commit

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

単純なマージを解決するために知っておく必要があるのは、上記ですべてです。 ただし、Gitは、競合の解決に役立つ詳細情報も提供します:

$ git diff
diff --cc file.txt
index 802992c,2b60207..0000000
--- a/file.txt
+++ b/file.txt
@@@ -1,1 -1,1 +1,5 @@@
++<<<<<<< HEAD:file.txt
 +Hello world
++=======
+ Goodbye
++>>>>>>> 77976da35a11db4580b80ae27e8d65caf5208086:file.txt

$ git show :1:file.txt  # 両方のブランチの共通の祖先にあるファイル
$ git show :2:file.txt  # the version from HEAD.
$ git show :3:file.txt  # the version from MERGE_HEAD.

$ git diff
diff --cc file.txt
index 802992c,2b60207..0000000
--- a/file.txt
+++ b/file.txt
@@@ -1,1 -1,1 +1,1 @@@
- Hello world
 -Goodbye
++Goodbye world

$ git diff -1 file.txt          # diff against stage 1
$ git diff --base file.txt      # same as the above
$ git diff -2 file.txt          # diff against stage 2
$ git diff --ours file.txt      # same as the above
$ git diff -3 file.txt          # diff against stage 3
$ git diff --theirs file.txt    # same as the above.

$ git diff AUTO_MERGE
diff --git a/file.txt b/file.txt
index cd10406..8bf5ae7 100644
--- a/file.txt
+++ b/file.txt
@@ -1,5 +1 @@
-<<<<<<< HEAD:file.txt
-Hello world
-=======
-Goodbye
->>>>>>> 77976da35a11db4580b80ae27e8d65caf5208086:file.txt
+Goodbye world

$ git log --merge
$ gitk --merge

$ git add file.txt

行き詰まり、あきらめて、混乱全体を捨てることにした場合は、いつでもマージ前の状態に戻ることができます

$ git merge --abort

または、あなたが破棄したいマージをすでにコミットしちゃってる場合は以下です

$ git reset --hard ORIG_HEAD

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

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

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

作業ツリーを台無しにしたが、まだ間違いをコミットしていない場合は、作業ツリー全体を最後にコミットした状態に戻すことができます

$ git restore --staged --worktree :/

コミットしたのを後悔した時、問題を解決するためには、根本的に異なる2つの方法があります:

$ git revert HEAD

$ git revert HEAD^

$ git commit --amend

$ git restore --source=HEAD^ path/to/file

$ git show HEAD^:path/to/file

$ git stash push -m "work in progress for foo feature"

... edit and test ...
$ git commit -a -m "blorpl: typofix"

$ git stash pop

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

リポジトリのクローンを作成し、あなた独自の変更をいくつかコミットした後、元のリポジトリで更新を確認し、それらをあなた独自の作業にマージすることをお勧めします。

git-fetch(1) を使用したリモート追跡ブランチを最新の状態に保つ方法や、2つのブランチをマージする方法についてはすでに説明しました。したがって、元のリポジトリのmasterブランチからの変更を以下のようにマージできます:

$ git fetch
$ git merge origin/master

しかしながら、 git-pull(1) コマンドは、これを1ステップで実行する方法を提供します:

$ git pull origin master

実際、 あなたが master をチェックアウトしている場合、このブランチは、元のリポジトリのHEADブランチから変更を取得するように git clone 実行時に構成済です。多くの場合、以下のように単純なもので上記を達成できます

$ git pull

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

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

git pull はキーストロークを節約するだけでなく、プル元のブランチとリポジトリを文書化したデフォルトのコミットメッセージを生成するのにも役立ちます。

(注意: ただし、fast-forwardの場合、そのようなコミットは作成されないことに注意してください。代わりに、アップストリームブランチからの最新のコミットを指すようにブランチが更新されます。)

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

$ git pull . branch
$ git merge branch

よってこれらは、ほぼ同等です。

変更がいくつかある場合、それらを送信する最も簡単な方法は、パッチとして電子メールで送信することです:

まずは git-format-patch(1) の使用例です:

$ git format-patch origin

そうすると、現在のディレクトリに番号付きの一連のファイルを生成します。現在のブランチのパッチごとに1つですが、 origin/HEAD についてのモノはありません。

git format-patch は、最初に送付状(cover letter)を付けることができます。 format-patch がコミットメッセージの後、パッチ自体の前に配置する3つの破線(---)の後に、個々のパッチに関するコメントを挿入できます。送付状の素材を追跡するために git notes を使用する場合、git format-patch --notes は同様の方法でコミットのnoteを含みます。

次に、これらをメールクライアントにインポートして、手動で送信できます。 ただし、一度に送信するものが多い場合は、 git-send-email(1) スクリプトを使用してプロセスを自動化することをお勧めします。まずはプロジェクトのメーリングリストを参照して、パッチを送信するための要件を決定してください。

Gitは、このような電子メールで送信された一連のパッチをインポートするための git-am(1) (amは「apply mailbox」の略)と呼ばれるツールも提供します。パッチを含むすべてのメッセージを順番に1つのメールボックスファイル(patches.mbox など)に保存してから、以下を実行します

$ git am -3 patches.mbox

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

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

$ git am --continue

こうすると、Gitはコミットを作成し、メールボックスから残りのパッチを適用し続けます。

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

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

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

$ git clone /path/to/repository
$ git pull /path/to/other/repository

または ssh URL を指定できます:

$ git clone ssh://yourhost/~you/repository

開発者が少ないプロジェクトの場合、または少数のプライベートリポジトリを同期する場合は、これで十分な場合があります。

けれども、これを行うためのより一般的な方法は、他のユーザーが変更をプルできるように、別のパブリックリポジトリ(通常は別のホスト上)を維持することです。これは通常、より便利であり、進行中の私的な作業を公に見える作業からきれいに分離することができます。

あなたは個人リポジトリで日常業務を継続しますが、定期的に個人リポジトリから公開リポジトリに変更を「プッシュ」して、他の開発者がそのリポジトリからプルできるようにします。したがって、パブリックリポジトリを持つ他の開発者が1人いる状況での変更のフローは、以下のようになります:

                      you push
your personal repo ------------------> your public repo
      ^                                     |
      |                                     |
      | you pull                            | they pull
      |                                     |
      |                                     |
      |               they push             V
their public repo <------------------- their repo

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

$ git clone --bare ~/proj proj.git
$ touch proj.git/git-daemon-export-ok

$ mv proj.git /home/you/public_html/proj.git
$ cd proj.git
$ git --bare update-server-info
$ mv hooks/post-update.sample hooks/post-update

$ git clone http://yourserver.com/~you/proj.git

$ git push ssh://yourserver.com/~you/proj.git master:master

$ git push ssh://yourserver.com/~you/proj.git master

$ git remote add public-repo ssh://yourserver.com/~you/proj.git

[remote "public-repo"]
        url = yourserver.com:proj.git
        fetch = +refs/heads/*:refs/remotes/example/*

$ git push public-repo master

 ! [rejected]        master -> master (non-fast-forward)
error: failed to push some refs to '...'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

$ git push ssh://yourserver.com/~you/proj.git +master

$ git push -f ssh://yourserver.com/~you/proj.git master

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

shallow cloneは、 git-clone(1) に --depth スイッチを指定することで作成されます。深さは後で git-fetch(1) の --depth スイッチで変更するか、または、完全な履歴を --unshallow で復元することができます。

shallow clone内でのマージは、マージベースが取得してきた最近の履歴にある限り機能します。そうでなければ、無関係な履歴をマージするようなものになり、大きな競合が発生する可能性があります。この制限により、このようなリポジトリはマージベースのワークフローでの使用に適さなくなる可能性があります。

例えば、あなたが大規模なプロジェクトの貢献者で、複雑な機能を追加したとき、他の開発者があなたの変更を読んでそれらが正しいかどうかを確認するために、あなたがそれぞれの変更を行った理由を理解しやすい方法で、提示したいとします。

すべての変更をそれぞれ単一のパッチ(またはコミット)として提示すると、一度にすべてを消化するには多すぎると思える事があります。

あなたの仕事の全履歴を提示し、その間違い・訂正・行き詰まりでいっぱいいっぱいにしたら、それを見る人達は閉口するかもしれません。

したがって、理想なのは、通常、以下のような一連のパッチを作成することです:

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

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

$ git switch -c mywork origin
$ vi file.txt
$ git commit
$ vi otherfile.txt
$ git commit
...

myworkへのマージは実行されていないため、 origin の先頭にあるパッチの単純な線形シーケンスです:

 o--o--O <-- origin
        \
         a--b--c <-- 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

しかしながら、myworkの履歴をマージせずに単純な一連のコミットを保持したい場合は、代わりに git-rebase(1) を使用することを選択できます:

$ git switch mywork
$ git rebase origin

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

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

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

$ git rebase --continue

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

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

$ git rebase --abort

ブランチ内の多数のコミットを並べ替えたり編集したりする必要がある場合は、 git rebase -i を使用する方が簡単な場合があります。これにより、コミットを並べ替えたり押しつぶしたり(squash)、リベース中に個別に編集できるようにマークを付けたりできます。詳細については the section called “Using interactive rebases” を、代替案については the section called “Reordering or selecting from a patch series” を参照してください。

the section called “履歴を巻き戻す事によって作業ミスを修正する”で、以下のようにして最新のコミットを置き換えることができることを確認しました

$ git commit --amend

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

履歴のより深いところのコミットを修正する必要がある場合は、対話的rebaseの「edit」命令を使用できます。

時々、あなたはあなたの歴史のより深いところにコミットを編集したいです。 1つのアプローチとしては、 git format-patch を使用して一連のパッチを作成し、パッチ適用前の状態にリセットすることです:

$ git format-patch origin
$ git reset --hard origin

そして git-am(1) を使用してパッチを再度適用する前に、必要に応じてパッチを変更、並べ替え、または削除します:

$ git am *.patch

対話的なリベースで一連のパッチを編集することもできます。 これは format-patch を使用してパッチシリーズを並べ替えるのと同じなので、あなたの最も好きなインターフェースを使用してください。

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

$ git rebase -i HEAD~5

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

pick deadbee The oneline of this commit
pick fa1afe1 The oneline of the next commit
...

# Rebase c0ffeee..deadbee onto c0ffeee
#
# Commands:
#  p, pick = use commit
#  r, reword = use commit, but edit the commit message
#  e, edit = use commit, but stop for amending
#  s, squash = use commit, but meld into previous commit
#  f, fixup = like "squash", but discard this commit's log message
#  x, exec = run command (the rest of the line) using shell
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.
#
# Note that empty commits are commented out

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

リベースは、 pick が edit に置き換えられた場合、またはリスト内のステップが競合を機械的に解決できず、あなたの助けが必要な場合に停止します。競合の編集や解決が完了したら、 git rebase --continue で続行できます。途中で物事があまりにもスパゲッティ(hairy)になっていると判断した場合は、いつでも git rebase --abort で救済することができます。リベースが完了した後でも、reflogを使用して、元のブランチを回復できます。

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

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

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

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

次に、あなたが最後の3つのコミットを変更するとします:

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

このすべての履歴を1つのリポジトリにまとめて見ると、以下のようになります:

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

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

あなたは、履歴が書き換えられたブランチを公開することを選択することもできます。他の人がそれらのブランチを調べたりテストしたりするためにそれらのブランチをフェッチできると便利な場合がありますが、そのようなブランチを自分の作業に引き込もうとしないでください。

適切なマージをサポートする、本当に分散開発を行っている場合、公開されたブランチを書き直してはいけません。

git-bisect(1) コマンドは、マージコミットを含む履歴を正しく処理します。ただし、検出されたコミットがマージコミットである場合、ユーザーは、そのコミットが問題を引き起こした理由を理解するために、通常よりも慎重に作業する事を心がけて下さい。

以下の履歴があるとします:

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

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

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

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

それにもかかわらず、開発の下側のラインで追加された呼び出し側は、開発の上側ラインに導入された新しいセマンティクスに変換されていないため、Cのコードは壊れています。したがって、Dがbad、Zがgoodで、git-bisect(1) がCを原因として特定していることだけを知っている場合、あなたは問題がこのセマンティクスの変更によるものであることをどのようにして解き明かしますか？

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

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

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

ZとD*の間のbisectは、単一の犯人コミットY*にヒットし、Y*が壊れた理由を理解するのはおそらく簡単でしょう。

多くの経験豊富なGitユーザーが、他の方法でマージが多いプロジェクトで作業している場合でも、公開する前に最新のアップストリームバージョンにリベースすることで履歴を線形に保つのは、これが理由の一つです。

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

$ git fetch origin todo:my-todo-work

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

以下のように、他のリポジトリからブランチをフェッチすることもできます。

$ git fetch git://example.com/proj.git master:example-master

これは 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

場合によっては、新しいヘッドが実際には古いヘッドの子孫ではない可能性があります。たとえば、開発者は重大なミスがあったことに気づき、バックトラックすることを決定した可能性があり、その結果、以下のような状況になります:

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

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

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

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

$ git fetch git://example.com/proj.git +master:refs/remotes/example/master

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

$ git fetch -f origin

これは、前のセクションで述べたとおり、ポイントされた古いバージョンのexample/masterが失われる可能性があることに注意してください。

前述したように、 origin は、最初にクローンを作成したリポジトリを参照するためのショートカットにすぎません。この情報はGit構成変数に保存され、 git-config(1) を使用して確認できます。

$ git config -l
core.repositoryformatversion=0
core.filemode=true
core.logallrefupdates=true
remote.origin.url=git://git.kernel.org/pub/scm/git/git.git
remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*
branch.master.remote=origin
branch.master.merge=refs/heads/master

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

$ git remote add example git://example.com/proj.git

とすると、 .git/config は以下のようになります:

[remote "example"]
        url = git://example.com/proj.git
        fetch = +refs/heads/*:refs/remotes/example/*

注意: 上記の設定は、 git-remote(1) を使用する代わりに、ファイル .git/config を直接編集することでも機能することに注意してください。

リモートを構成した後、以下の3つのコマンドは同じことを行います:

$ git fetch git://example.com/proj.git +refs/heads/*:refs/remotes/example/*
$ git fetch example +refs/heads/*:refs/remotes/example/*
$ git fetch example

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

私達はすでにthe section called “Understanding History: Commits”で、すべてのコミットが40桁の「オブジェクト名」で保存されているのを見ました。実際、プロジェクトの履歴を表すために必要なすべての情報は、そのような名前のオブジェクトに格納されています。いずれの場合も、名前はオブジェクトのコンテンツのSHA-1ハッシュを使用して計算されます。SHA-1ハッシュは暗号化ハッシュ関数です。それが私たちにとって意味することは、同じ名前の2つの異なるオブジェクトを見つけることは不可能であるということです。これには多くの利点があります:

(オブジェクトのフォーマットとSHA-1計算の詳細については、the section called “Object storage format”を参照してください。)

オブジェクトには "blob"、"tree"、"commit"、"tag" の4種類があります。

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

$ git show -s --pretty=raw 2be7fcb476
commit 2be7fcb4764f2dbcee52635b91fedb1b3dcf7ab4
tree fb3a8bdd0ceddd019615af4d57a53f43d8cee2bf
parent 257a84d9d02e90447b149af58b271c19405edb6a
author Dave Watson <dwatson@mimvista.com> 1187576872 -0400
committer Junio C Hamano <gitster@pobox.com> 1187591163 -0700

    Fix misspelling of 'suppress' in docs

    Signed-off-by: Junio C Hamano <gitster@pobox.com>

$ git ls-tree fb3a8bdd0ce
100644 blob 63c918c667fa005ff12ad89437f2fdc80926e21c    .gitignore
100644 blob 5529b198e8d14decbe4ad99db3f7fb632de0439d    .mailmap
100644 blob 6ff87c4664981e4397625791c8ea3bbb5f2279a3    COPYING
040000 tree 2fb783e477100ce076f6bf57e4a6f026013dc745    Documentation
100755 blob 3c0032cec592a765692234f1cba47dfdcc3a9200    GIT-VERSION-GEN
100644 blob 289b046a443c0647624607d471289b2c7dcd470b    INSTALL
100644 blob 4eb463797adc693dc168b926b6932ff53f17d0b1    Makefile
100644 blob 548142c327a6790ff8821d67c2ee1eff7a656b52    README
...

$ git show 6ff87c4664

 Note that the only valid version of the GPL as far as this project
 is concerned is _this_ particular version of the license (ie v2, not
 v2.2 or v3.x or whatever), unless explicitly otherwise stated.
...

$ git cat-file tag v1.5.0
object 437b1b20df4b356c9342dac8d38849f24ef44f27
type commit
tag v1.5.0
tagger Junio C Hamano <junkio@cox.net> 1171411200 +0000

GIT 1.5.0
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQBF0lGqwMbZpPMRm5oRAuRiAJ9ohBLd7s2kqjkKlq1qqC57SbnmzQCdG4ui
nLE/L9aUXdWeTFPron96DLA=
=2E+0
-----END PGP SIGNATURE-----

$ git count-objects
6930 objects, 47620 kilobytes

$ git repack
Counting objects: 6020, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (6020/6020), done.
Writing objects: 100% (6020/6020), done.
Total 6020 (delta 4070), reused 0 (delta 0)

$ git prune

$ git count-objects
0 objects, 0 kilobytes

$ gitk <dangling-commit-sha-goes-here> --not --all

$ git branch recovered-branch <dangling-commit-sha-goes-here>

$ git show <dangling-blob/tree-sha-goes-here>

$ git prune

$ git fsck --full --no-dangling
broken link from    tree 2d9263c6d23595e7cb2a21e5ebbb53655278dff8
              to    blob 4b9458b3786228369c63936db65827de3cc06200
missing blob 4b9458b3786228369c63936db65827de3cc06200

$ git ls-tree 2d9263c6d23595e7cb2a21e5ebbb53655278dff8
100644 blob 8d14531846b95bfa3564b58ccfb7913a034323b8    .gitignore
100644 blob ebf9bf84da0aab5ed944264a5db2a65fe3a3e883    .mailmap
100644 blob ca442d313d86dc67e0a2e5d584b465bd382cbf5c    COPYING
...
100644 blob 4b9458b3786228369c63936db65827de3cc06200    myfile
...

$ git hash-object -w somedirectory/myfile

$ git log --raw --all --full-history -- somedirectory/myfile

commit abc
Author:
Date:
...
:100644 100644 4b9458b newsha M somedirectory/myfile


commit xyz
Author:
Date:

...
:100644 100644 oldsha 4b9458b M somedirectory/myfile

$ git hash-object -w <recreated-file>

$ git log --raw --all

インデックスは、ソートされたパス名のリストを含むバイナリファイル(通常は .git/index に保持されます)であり、それぞれパーミッションとブロブオブジェクトのSHA-1を含んでいます。 git-ls-files(1) は、インデックスの内容を表示できます。

$ git ls-files --stage
100644 63c918c667fa005ff12ad89437f2fdc80926e21c 0       .gitignore
100644 5529b198e8d14decbe4ad99db3f7fb632de0439d 0       .mailmap
100644 6ff87c4664981e4397625791c8ea3bbb5f2279a3 0       COPYING
100644 a37b2152bd26be2c2289e1f57a292534a51a93c7 0       Documentation/.gitignore
100644 fbefe9a45b00a54b58d94d06eca48b03d40a50e0 0       Documentation/Makefile
...
100644 2511aef8d89ab52be5ec6a5e46236b4b6bcd07ea 0       xdiff/xtypes.h
100644 2ade97b2574a9f77e7ae4002a4e07a6a38e46d07 0       xdiff/xutils.c
100644 d5de8292e05e7c36c4b68857c1cf9855e3d2f70a 0       xdiff/xutils.h

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

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

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

サブモジュールの変更を参照するスーパープロジェクトに変更を公開する前に、必ずサブモジュールの変更を公開してください。サブモジュールの変更を公開するのを忘れると、他の人はリポジトリのクローンを作成できなくなります:

$ cd ~/git/super/a
$ echo i added another line to this file >> a.txt
$ git commit -a -m "doing it wrong this time"
$ cd ..
$ git add a
$ git commit -m "Updated submodule a again."
$ git push
$ cd ~/git/cloned
$ git pull
$ git submodule update
error: pathspec '261dfac35cb99d380eb966e102c1197139f7fa24' did not match any file(s) known to git.
Did you forget to 'git add'?
Unable to checkout '261dfac35cb99d380eb966e102c1197139f7fa24' in submodule path 'a'

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

$ git diff
diff --git a/sub b/sub
--- a/sub
+++ b/sub
@@ -1 +1 @@
-Subproject commit 3f356705649b5d566d97ff843cf193359229a453
+Subproject commit 3f356705649b5d566d97ff843cf193359229a453-dirty
$ git diff --submodule
Submodule sub 3f35670..3f35670-dirty:

また、スーパープロジェクトでこれまでに記録されたコミットを超えて、サブモジュールのブランチを巻き戻さないでください。

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

$ cat a.txt
module a
$ echo line added from private2 >> a.txt
$ git commit -a -m "line added inside private2"
$ cd ..
$ git submodule update
Submodule path 'a': checked out 'd266b9873ad50488163457f025db7cdd9683d88b'
$ cd a
$ cat a.txt
module a

サブモジュールの作業ツリーにコミットされていない変更がある場合、 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操作はインデックスファイルで機能します。一部の操作はインデックスファイルに対して*純粋に*機能します(インデックスの現在の状態を示す)が、ほとんどの操作は、インデックスファイルとデータベースまたは作業ディレクトリの間でデータを移動します。 したがって、Git操作には4つの主要な組み合わせがあります:

$ git update-index filename

$ git write-tree

$ git read-tree <SHA-1 of tree>

$ git checkout-index filename

$ git commit-tree <tree> -p <parent> [(-p <parent2>)...]

                     commit-tree
                      commit obj
                       +----+
                       |    |
                       |    |
                       V    V
                    +-----------+
                    | Object DB |
                    |  Backing  |
                    |   Store   |
                    +-----------+
                       ^
           write-tree  |     |
             tree obj  |     |
                       |     |  read-tree
                       |     |  tree obj
                             V
                    +-----------+
                    |   Index   |
                    |  "cache"  |
                    +-----------+
         update-index  ^
             blob obj  |     |
                       |     |
    checkout-index -u  |     |  checkout-index
             stat      |     |  blob obj
                             V
                    +-----------+
                    |  Working  |
                    | Directory |
                    +-----------+

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

$ git cat-file -t <objectname>

上記はオブジェクトのタイプを表示します。タイプを取得すると(もっとも、通常はオブジェクトの配置場所で自明ではありますけれども)、以下を使用できます

$ git cat-file blob|tree|commit|tag <objectname>

とすると、その内容を表示します。 注意！ ツリーの内容はバイナリです。よって、その内容を表示するための「git ls-tree」と呼ばれる特別なヘルパーが、内容のバイナリをより読みやすい形式に変換します。

「コミット」オブジェクトは小さく、かなり自明である傾向があるため、それらを確認することは特に有益です。 特に、あなたが .git/HEAD に先頭コミット名を付けるという規則に従うと、以下のことができます。

$ git cat-file commit HEAD

は、先頭コミットが何であったかを表示します。

Gitは、3方向マージを実行するのに役立ちます。これは、マージ手順を数回繰り返すことで、多方向マージに使用できます。 通常の状況では、3方向マージ(2ラインの履歴の調整)を1回だけ実行して結果をコミットしますが、必要に応じて、一度に複数のブランチをマージできます。

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

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

$ git merge-base <commit1> <commit2>

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

$ git cat-file commit <commitname> | head -1

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

マージする3つのツリー(1つの「元の」ツリー（別名共通ツリー）と2つの「結果」ツリー（別名マージするブランチ))が分かったら、インデックスに「マージ」読み取りを行います。 古いインデックスの内容を破棄する必要がある場合には文句を言うので、それらをコミット済であることをことを確認する必要があります。実際、通常は常に最後のコミットに対してマージを実行します(したがって、とにかく現在のインデックスにあるものと一致する必要があります)。

マージを行うには以下を行います

$ git read-tree -m -u <origtree> <yourtree> <targettree>

これにより、とるにたりない些細な3方向マージ操作(trivial merge operations)の全てがインデックスファイルに対して直接実行され、 git write-tree を使用して結果を書き出すことができます。(訳注:trivial;ラテン語「3 本の道が合する所，ありふれたこと」の意がある)

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

このようなインデックスの状態は、 git ls-files --unmerged コマンドで調べることができます。 たとえば:

$ git read-tree -m $orig HEAD $target
$ git ls-files --unmerged
100644 263414f423d0e4d70dae8fe53fa34614ff3e2860 1       hello.c
100644 06fa6a24256dc7e560efa5687fa84b51f0263c3a 2       hello.c
100644 cc44c73eb783565da5831b4d820c962954019b69 3       hello.c

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方向マージプログラム、例えば、これら3つのステージのブロブオブジェクトに対する diff3 または merge またはGit独自の merge-file を実行することで解決できます:

$ git cat-file blob 263414f >hello.c~1
$ git cat-file blob 06fa6a2 >hello.c~2
$ git cat-file blob cc44c73 >hello.c~3
$ git merge-file hello.c~2 hello.c~1 hello.c~3

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

$ mv -f hello.c~2 hello.c
$ git update-index hello.c

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

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

$ git merge-index git-merge-one-file hello.c

そして、これが、より高いレベルの git merge -s resolve の実装になっています。

すべてのオブジェクトには、オブジェクトの形式(つまり、オブジェクトの使用方法や他のオブジェクトの参照方法)を識別する、静的に決定された「タイプ」( "type" )があります。 現在、「blob」、「tree」、「commit」、「tag」の4つの異なるオブジェクトタイプがあります。

オブジェクトタイプに関係なく、すべてのオブジェクトは次の特性を共有します: すべてzlibで圧縮され、タイプを指定するだけでなく、オブジェクト内のデータに関するサイズ情報も提供するヘッダーがあります。オブジェクトの名前付けに使用されるSHA-1ハッシュは、 元のデータ＋ヘッダー のハッシュであるため、 sha1sum file は file のオブジェクト名と一致しないことに注意してください。

その結果、オブジェクトの一般的な整合性は、オブジェクトの内容やタイプに関係なく常にテストできます。すべてのオブジェクトは、 (a)ハッシュがファイルの内容と一致、かつ、 (b)オブジェクトが、 <ascii type without space> + <space> + <ascii decimal size> + <byte\0> + <binary object data> というシーケンスのバイトストリームへちゃんと解凍できることで検証できます。

構造化オブジェクトは、その構造と他のオブジェクトへの接続をさらに検証できます。 これは通常、すべてのオブジェクトの完全な依存関係グラフを生成し、（ハッシュを介して表面的な一貫性を検証するだけでなく）内部の一貫性を検証する gitfsck プログラムを使用して行われます。

新しい開発者がGitのソースコードを見つけるのは必ずしも簡単ではありません。この節では、あなたがどこから始めればよいかを示すちょっとしたガイダンスを提供します。

開始するのに適した場所は、最初のコミットの内容から始めることです:

$ git switch --detach e83c5163

最初のリビジョンは、Gitが今日持っているほとんどすべての基礎を築きますが、一度に読むには十分小さくまとまっています。

そのリビジョン以降、用語が変更されていることに注意してください。 たとえば、そのリビジョンのREADMEは、 "changeset" という単語を使用して、今、 commit と呼んでいるものを説明しています。

また、 私たちはそれを「キャッシュ」(cache)と呼ぶのではなく、「インデックス」(index)と呼びます。 ただし、ファイルの名前は依然として read-cache.h です。

あなたが最初のコミットでGitの考え方を把握したなら、あなたはより新しいバージョンをチェックして、 read-cache-ll.h と object.h と commit.h を読み下すべきです。

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

今や、 あなたはインデックスが何であるかを知り(そして、それに対応するデータ構造は read-cache-ll.h にある)、 その最初のメンバーである struct object から共通の構造を継承するオブジェクトタイプ(blobs と trees と commits と tags)が幾つかあることを知りました(したがって、 たとえば (struct object *)commit とキャストして、 &commit->object と全く同様の事を行う事ができます。 つまり、 オブジェクト名とフラグを取得を取得できるのです)。

ここで、この情報を吸収するために一服するとしましょう。

次のステップ: オブジェクトの命名に慣れてください。 the section called “Naming commits” を読んでください。 オブジェクトに名前を付ける方法はたくさんあります(リビジョンだけではありません！)。 これらはすべて sha1_name.c で処理されます。 関数 get_sha1() をざっと見てください。特別な処理の多くは、 get_sha1_basic() などの関数によって実行されます。

リビジョンウォーカー。これはGitの最も解放(libified)された部分にあなたがうまく適応できるようにします。

基本から行きましょう。 git log の初期バージョンは、シェルスクリプトでした:

$ git-rev-list --pretty $(git-rev-parse --default HEAD "$@") | \
        LESS=-S ${PAGER:-less}

これはどういう意味か？

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

gitrev-parse はもはやそれほど重要ではありません。これは、スクリプトによって呼び出されたさまざまな配管コマンドに関連するオプションを除外するためにのみ使用されました。

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

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() を検索して、それが何をするかを調べます。

        git_config(git_default_config);
        if (argc != 3)
                usage("git cat-file [-t|-s|-e|-p|<type>] <sha1>");
        if (get_sha1(argv[2], sha1))
                die("Not a valid object name %s", argv[2]);

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

ここで興味深いのは以下の2つです:

コード全体でこれらの両方が表示されます。

さて、肝心の部分は:

        case 0:
                buf = read_object_with_reference(sha1, argv[1], &size, NULL);

これはブロブ(実際にはブロブだけでなくあらゆるタイプのオブジェクト)を読み取る方法です。 関数 read_object_with_reference() が実際にどのように機能するかを知るには、(Gitのリポジトリで git grep read_object_with | grep ":[a-z]" などして)そのソースコードを探して拝んでください。

結果の使用方法を確認するには、 cmd_cat_file() を読んでください:

        write_or_die(1, buf, size);

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

例: git bundle のテストケースがあったことはわかっているが、それがどこにあったか覚えていない場合(はいもちろん、あなたは git grep bundle t/ できますが、そーゆー事を言いたい訳じゃない):

$ git log --no-merges t/

ページャー(less)の中で、 "bundle" を検索し、数行前に戻って、それがコミット 18449ab0 にあることを確認します。このオブジェクト名をコピーして、コマンドラインに貼り付けます。

$ git show 18449ab0

できた！

別の例: スクリプトを組み込みにするために何をすべきかを調べます:

$ git log --no-merges --diff-filter=A builtin/*.c

ほらこのとおり。Gitは実際、Git自体のソースを見つけるのに最適なツールです！