SYNOPSIS

'git fetch' [<options>] [<repository> [<refspec>...]]
'git fetch' [<options>] <group>
'git fetch' --multiple [<options>] [(<repository> | <group>)...]
'git fetch' --all [<options>]

DESCRIPTION

履歴を完成させるために必要なオブジェクトとともに、1つ以上の他のリポジトリからブランチやタグ(総称して「refs」)を取得します。 リモート追跡ブランチが更新されます(この振る舞いを制御する方法については、以下の <refspec> の説明を参照してください)。

デフォルトでは、フェッチされている履歴を指すタグもフェッチされます。 その効果は、関心のあるブランチを指すタグをフェッチすることです。 このデフォルトの振る舞いは、 --tags または --no-tags オプションを使用するか、 remote.<name>.tagOpt を構成することで変更できます。 あなたは、タグを明示的にフェッチするrefspecを使用することで、関心のあるブランチを指していないタグもフェッチできます。

git fetch は、単一の名前付きリポジトリまたはURLから、あるいは、 <group> が指定され、かつ、構成ファイルに remotes.<group> エントリがある場合は、一度に複数のリポジトリからフェッチできます。 (git-config(1) 参照)。

「リモート」が指定されていない場合、現在のブランチ用に上流ブランチが構成されていない限り、デフォルトで origin リモートが使用されます。

フェッチされたrefの名前は、それらが指すオブジェクト名とともに、 .git/FETCH_HEAD に書き込まれます。 この情報は、スクリプトまたは git-pull(1) などの他のgitコマンドで使用される場合があります。

OPTIONS

--[no-]all

remote.<name>.skipFetchAll 設定変数が設定されているリモートを除く、 すべてのリモートを取得(fetch)します。 これは設定変数 fetch.all をオーバーライドします。

-a
--append

取得した refs の ref 名とオブジェクト名を .git/FETCH_HEAD の既存のコンテンツに追加します。 このオプションがないと、 .git/FETCH_HEAD の古いデータが上書きされます。

--atomic

アトミック・トランザクションを使用して、ローカル参照を更新します。 すべての参照が更新されるか、あるいは、エラーが発生してすべての参照が更新されないか、のいずれかです。

--depth=<depth>

各リモートブランチ履歴の先端からの指定されたコミット数に取得を制限します。 --depth=<depth> オプションを指定して git clone によって作成された浅いリポジトリー(shallow repository)から取得する場合(git-clone(1) 参照)、指定されたコミット数まで履歴を深くするか浅くするかします。

--deepen=<depth>

--depth に似ていますが、各リモートブランチ履歴の先端からではなく、現在の浅い境界(shallow boundary)からのコミット数を指定する点が異なります。

--shallow-since=<date>

浅い(shallow)リポジトリーの履歴を深くしたり浅くしたりして、<date>以降の到達可能なすべてのコミットを含めます。

--shallow-exclude=<ref>

浅い(shallow)リポジトリーの履歴を深くするか浅くするかして、指定されたリモートブランチまたはタグから到達可能なコミットを除外します。 このオプションは複数回指定できます。

--unshallow

ソース・リポジトリーが完全な場合は、 浅い(shallow)リポジトリーを完全なリポジトリーに変換し、 浅い(shallow)リポジトリーに課せられるすべての制限を取り除きます。

ソース・リポジトリーが浅い(shallow)場合は、現在のリポジトリーがソースリ・ポジトリと同じ履歴を持つように、可能な限り取得します。

--update-shallow

デフォルトでは、 浅い(shallow)リポジトリーから取得する場合、 git fetch は .git/shallow の更新が必要な ref を拒否します。 このオプションは .git/should を更新し、そのような ref を受け入れます。

--negotiation-tip=<commit|glob>

デフォルトでは、Gitは、受信するパック・ファイルのサイズを縮小するために、すべてのローカル ref から到達可能なコミットをサーバーに報告して、共通のコミットを見つけます。 指定した場合、Gitは指定された先端から到達可能なコミットのみを報告します。 これは、取得される上流 ref と共通のコミットを持つ可能性のあるローカルrefがユーザーにわかっている場合に、取得を高速化するのに役立ちます。

このオプションは複数回指定できます。 その場合、Gitは指定されたコミットのいずれかから到達可能なコミットを報告します。

このオプションの引数は、 ref 名または ref またはコミットの(おそらく省略された) SHA-1 のグロブ(glob)である可能性があります。 グロブを指定することは、 一致する ref 名ごとに1つずつ、 このオプションを複数回指定することと同じです。

git-config(1) に記載されている fetch.negotiationAlgorithm と push.negotiate 構成変数、および、以下の --negotiate-only オプションも参照してください。

--negotiate-only

サーバーから何も取得せず、代わりに、サーバーと共通している、提供された --negotiation-tip=* 引数の祖先を出力します。

これは --recurse-submodules=[yes|on-demand] と互換性がありません。 内部的には、これは push.negotiate オプションを実装するために使用されます。 git-config(1) を参照してください。

--dry-run

変更を加えずに、何が行われるかを示します。

--porcelain

スクリプトがパースしやすい形式で標準出力に出力します。 詳細については、git-fetch(1) のセクション OUTPUT を参照してください。

これは --recurse-submodules=[yes|on-demand] とは互換性がなく、 かつ、 fetch.output 設定オプションよりも優先されます。

--[no-]write-fetch-head

$GIT_DIR のすぐ下の FETCH_HEAD ファイルに取得されたリモートrefのリストを書き込みます。 これがデフォルトです。 コマンドラインから --no-write-fetch-head を渡すと、Gitにファイルを書き込まないように指示します。 --dry-run オプションでは、ファイルが書き込まれることはありません。

-f
--force

git fetch が <src>:<dst> な refspec とともに使用される場合、 下記の <refspec> の部分で説明するように、 ローカル・ブランチの更新を拒否する可能性があります。 このオプションはそのチェックをオーバーライドします。

-k
--keep

ダウンロードしたパックを保持してください。

--multiple

複数の<repository>および<group>引数を指定できるようにします。 <refspec>を指定することはできません。

--[no-]auto-maintenance
--[no-]auto-gc

最後に git maintenance run --auto を実行して、必要に応じて自動リポジトリーメンテナンスを実行します。 (--[no-]auto-gc は同義語です。) これはデフォルトで有効になっています。

--[no-]write-commit-graph

取得後にコミットグラフ(commit-graph)を記述します。 これは、構成設定 fetch.writeCommitGraph をオーバーライドします。

--prefetch

構成されたrefspecを変更して、すべてのrefを refs/prefetch/ 名前空間に配置します。 git-maintenance(1)の prefetch タスクを参照してください。

-p
--prune

取得する前に、リモートに存在しなくなったリモート追跡参照を削除します。 タグは、デフォルトのタグの自動追跡または --tags オプションのためにのみフェッチされた場合(コマンドラインまたはリモート構成のいずれかで、たとえば、リモートが --mirror オプションでcloneされた場合)、刈り込み(pruning)の対象にはなりません。 ただし、明示的なrefspecが原因でタグが取得された場合、それらも刈り込み(pruning)の対象になります。 --prune-tags を指定することは、タグrefspecを提供するための省略形です。

詳細については、下記の「PRUNING」セクションを参照してください。

-P
--prune-tags

--prune が有効になっている場合は、取得する前に、リモートに存在しなくなったローカルタグをすべて削除します。 このオプションは、 --prune とは異なり、より慎重に使用する必要があります。作成されたローカル参照(ローカルタグ)はすべて削除されます。 このオプションは、明示的なタグrefspecを --prune とともに提供するための省略形です。これについては、そのドキュメントの説明を参照してください。

詳細については、下記の「PRUNING」セクションを参照してください。

-n
--no-tags

デフォルトでは、リモートリポジトリーからダウンロードされたオブジェクトを指すタグが取得され、ローカルに保存されます。このオプションは、この自動タグ追跡を無効にします。 リモートのデフォルトの動作は、 remote.<name>.tagOpt 設定で指定できます。 git-config(1) を参照してください。

--refetch

すでにローカルに存在するコミットとその関連オブジェクトの転送を避けるためにサーバーと交渉(negotiate)する代わりに、 このオプションは新しいクローン(fresh clone)のようにすべてのオブジェクトを取得します。 これを使用して、構成から部分(partial)クローン・フィルターを再適用するか、または、フィルター定義が変更されたときに --filter= を使用します。 取得後の自動メンテナンスにより、オブジェクト・データベース・パックの統合が実行され、重複オブジェクトが削除されます。

--refmap=<refspec>

コマンドラインにリストされているrefを取得するときは、リモートリポジトリーの remote.*.fetch 構成変数の値の代わりに、指定されたrefspec(複数回指定可能)を使用してrefをリモート追跡ブランチにマップします。 空の <refspec> を --refmap オプションに指定すると、Gitは構成されたrefspecsを無視し、コマンドライン引数として提供されたrefspecsに完全に依存します。 詳細については、「Configured Remote-tracking Branches」のセクションを参照してください。

-t
--tags

他の方法で取得されるものに加えて、リモートからすべてのタグを取得します(つまり、リモートタグ refs/tags/* を同じ名前のローカルタグに取得します)。 このオプションを単独で使用しても、 --prune が使用されている場合でも、タグは刈り込み(pruning)の対象にはなりません(ただし、タグが明示的なrefspecの宛先でもある場合は、タグは刈り込み(pruning)される可能性があります。 --prune を参照してください)。

--recurse-submodules[=(yes|on-demand|no)]

このオプションは、サブモジュールの新しいコミットも取得する必要があるかどうか、およびどのような条件で取得するかを制御します。 サブモジュールを再帰するとき、 git fetch は常に「変更された」サブモジュール、つまり、新しく取得(fetch)されたスーパープロジェクト・コミットによって参照されるが、ローカル・サブモジュール・クローンにないコミットを持つサブモジュールを取得(fetch)しようとします。 変更されたサブモジュールは、ローカル、たとえば $GIT_DIR/modules/ 内に存在する限り取得(fetch)できます(gitsubmodules(7) を参照)。 アップストリームが新しいサブモジュールを追加した場合、そのサブモジュールはクローン、たとえば git submodule update されるまで取得(fetch)できません。

on-demand に設定すると、 変更されたサブモジュールのみが取得されます。 yes に設定すると、すべての入力済みサブモジュールと、未入力かつ変更されたサブモジュールが、取得されます。 no に設定すると、サブモジュールはフェッチされません。

指定されていない場合、 fetch.recurseSubmodules が設定されている場合は fetch.recurseSubmodules の値が使用され(git-config(1) 参照)、 fetch.recurseSubmodules も設定されていない場合はデフォルトで on-demand になります。 このオプションを値なしで使用すると、デフォルトで yes になります。

-j
--jobs=<n>

すべての形式の取得に使用されるparallel childrenの数。

--multiple オプションが指定された場合、異なるリモートが並行して取得されます。 複数のサブモジュールが取得される場合、それらは並行して取得されます。 それらを個別に制御するには、構成設定 fetch.parallel と submodule.fetchJobs を使用します(git-config(1) 参照)。

通常、並列再帰取得(parallel recursive fetches)やマルチリモート取得(multi-remote fetches)の方が高速です。デフォルトでは、取得は並列ではなく順次実行されます。

--no-recurse-submodules

サブモジュールの再帰的取得を無効にします(これは、 --recurse-submodules=no オプションを使用するのと同一の効果があります)。

--set-upstream

リモートが正常に取得された場合は、引数のない git-pull(1) およびその他のコマンドで使用される上流(追跡)参照を追加します。 詳細については、 git-config(1) の branch.<name>.merge および branch.<name>.remote を参照してください。

--submodule-prefix=<path>

「Fetching submodule foo」などの情報メッセージに出力されるパスの前に<path>を付けます。このオプションは、サブモジュールを再帰的に実行するときに内部的に使用されます。

--recurse-submodules-default=[yes|on-demand]

このオプションは、 --recurse-submodules オプションに no で無いデフォルト値(non-negative default value)を一時的に提供するために内部的に使用されます。 取得のサブモジュール再帰を構成する他のすべての方法(gitmodules(5) や git-config(1) の設定など) は、 --[no-]recurse-submodules を直接指定する場合と同様に、このオプションをオーバーライドします。

-u
--update-head-ok

デフォルトでは、 git fetch は現在のブランチに対応する HEAD の更新を拒否します。 このフラグはそのチェックを無効にします。 これは純粋に git pull が git fetch と通信するための内部使用のためであり、あなたが独自の磁器コマンドを実装していない限り、あなたがそれを使用することは想定されていません。

--upload-pack <upload-pack>

このオプションが指定され、 かつ、 取得元のリポジトリーが git fetch-pack によって処理される場合、 --exec=<upload-pack> がコマンドに渡され、もう一方の端で実行されるコマンドのデフォルト以外のパスが指定されます。

-q
--quiet

--quiet を git-fetch-pack に渡し、内部で使用される他のgitコマンドをすべて静粛にさせます。 進行状況は標準エラーストリームに報告されません。

-v
--verbose

おしゃべりにします。

--progress

-q が指定されていない限り、進行状況は、端末に接続されている場合、デフォルトで標準エラーストリームに報告されます。 このフラグは、標準エラーストリームが端末に送信されていない場合でも、進行状況を強制します。

-o <option>
--server-option=<option>

プロトコル・バージョン2を使用して通信する場合は、指定された文字列をサーバーに送信します。 指定された文字列には、NUL文字またはLF文字を含めることはできません。 不明なオプションを含むサーバー・オプションのサーバー処理は、サーバー固有です。 複数の --server-option=<option> が指定されている場合、それらはすべてコマンドラインにリストされている順序で相手側に送信されます。 コマンドラインから --server-option=<option> が指定されて無い場合、 代わりに設定変数 remote.<name>.serverOption の値が使用されます。

--show-forced-updates

デフォルトでは、gitは取得中にブランチが強制的に更新されるかどうかをチェックします。 これは fetch.showForcedUpdates を介して無効にすることができますが、 --show-forced-updates オプションはこのチェックが行われることを保証します。 git-config(1) を参照してください。

--no-show-forced-updates

デフォルトでは、gitは取得中にブランチが強制的に更新されるかどうかをチェックします。 --no-show-forced-updates を渡すか、 fetch.showForcedUpdates を false に設定して、パフォーマンス上の理由からこのチェックをスキップします。 git-pull 処理中に使用された場合、 --ff-only オプションは、早送り(fast-forward)更新を試行する前に、強制更新をチェックします。 git-config(1) を参照してください。

-4
--ipv4

IPv6アドレスを無視して、IPv4アドレスのみを使用します。

-6
--ipv6

IPv4アドレスを無視して、IPv6アドレスのみを使用します。

<repository>

fetch または pull 操作のソースである「リモート」リポジトリー。このパラメーターは、URL(以下の GIT URLS セクションを参照)またはリモートの名前(以下の REMOTES セクションを参照)のいずれかです。

<group>

構成ファイル内のリモート。 <group> の値としてリポジトリーのリストを参照する名前。(git-config(1) を参照)。

<refspec>

取得するrefと更新するローカルrefを指定します。コマンドラインに <refspec> がない場合、取得するrefは代わりに remote.<repository>.fetch 変数から読み取られます。 (下記 CONFIGURED REMOTE-TRACKING BRANCHES 参照)

<refspec> パラメータの書式は、 オプションのプラス + に続いて、 ソースの <src> 、コロン : 、 宛先の <dst> の順です。 <dst> が空の場合、 コロン(:)は省略できます。 <src> は通常 ref 、 または一連の refs とマッチさせる使用する単一の * を含むグロブ(glob)パターンですが、 フルスペルの16進オブジェクト名にすることもできます。

<refspec> の <src> には、単純なパターンマッチを示すための * が含まれている場合があります。 このような refspec は、 そのパターンに合致する任意の ref とマッチするグロブのように機能します。 このパターンの <refspec> には、 <src> と <dst> の両方の中でたった 1 つだけ * の箇所が必要です。 * をソース(src)から、 マッチしたコンテンツに置き換えることにより、 ref を宛先(dst)にマッピングします。

refspecの前に ^ が付いている場合、それは否定(negative)のrefspecとして解釈されます。このようなrefspecは、取得するrefや更新するローカルrefを指定するのではなく、除外するrefを指定します。 refは、少なくとも1つの肯定(positive)のrefspecと一致し、 否定のrefspecと一致しない場合、 一致すると見なされます。 否定のrefspecは、特定のrefが含まれないように、 パターンrefspecのスコープを制限するのに役立ちます。 否定のrefspecは、それ自体がパターンrefspecである可能性があります。 ただし、 <src> のみを含めることができ、 <dst> を指定することはできません。 フルスペルの16進オブジェクト名もサポートされていません。

tag <tag> は、 refs/tags/<tag>:refs/tags/<tag> と同じ意味です。指定されたタグまでのすべてを取得するように要求します。

<src> に一致するリモートrefが取得され、 <dst> が空の文字列でない場合は、それに一致するローカルrefを更新しようとします。

その更新が --force なしで許可されるかどうかは、取得先のref名前空間、取得されるオブジェクトのタイプ、および更新がfast-forwardであると見なされるかどうかによって異なります。一般に、 push する場合と同じルールが fetch に適用されます。それらが何であるかについては、 git-push(1)の <refspec>... セクションを参照してください。 以下に git fetch に固有の例外ルールを示します:

Gitバージョン2.20までは、 git-push(1) でプッシュする場合とは異なり、 refs/tags/* の更新は、 refspec に + がなくても(または --force 指定が無くても)受け入れられます。 fetch するとき、リモートからのすべてのタグ更新を強制取得としていました。Gitバージョン2.20以降では、 refs/tags/* を更新するための fetch は、 push する場合と同じように機能します。 つまり refspecに + が無い場合(または --force が無い場合)、更新は拒否されます。

git-push(1) でプッシュする場合とは異なり、 refs/{tags,heads}/* の外部での更新は、 refspec に + を指定しなくても(または --force を指定しなくても)受け入れられます。 たとえば、 ツリー・オブジェクトをブロブに置き換えたり、 あるコミットを、 その前のコミットを祖先としない別のコミットに置き換えたりする場合などです。

git-push(1) でプッシュする場合とは異なり、これらのルールを修正する構成はなく、 pre-receive フックに類似した pre-fetch フックのようなものはありません。

git-push(1) を使用したプッシュと同様に、 更新として許可されないものに関する上記のすべてのルールは、 refspec 先頭にオプションで + をに追加する(または --force コマンドライン・オプションを使用する)ことでオーバーライドできます。 これに対する唯一の例外は、 refs/heads/* 名前空間が非コミット・オブジェクトを受け入れるように強制することはないということです。

Note
 取得するリモート・ブランチが定期的に巻き戻されてリベースされることがわかっている場合、その新しい先端は(最後に取得したときにリモート・トラッキング・ブランチに保存された)以前の先端の子孫ではないことが予想されます。あなたは + 記号を使用して、そのようなブランチにnon-fast-forwardの更新が必要であることを指示します。この操作でブランチがリポジトリーで使用可能になることを決定または宣言する方法はありません。プルするユーザーは、これがブランチの予想される使用パターンであることを知っている必要があります。
--stdin

引数として提供されているものに加えて、標準入力からrefspecsを1行に1つずつ読み取ります。 「tag <name>」形式はサポートされていません。

GIT URLS

一般に URLには、トランスポート・プロトコルや、リモート・サーバーのアドレスや、 リポジトリーへのパスに関する情報が含まれています。トランスポート・プロトコルによっては、一部の情報が欠落している場合があります。

Gitは、 ssh プロトコルと git プロトコルと http プロトコルと https プロトコルをサポートします(さらに ftp と ftps を fetch に使用できますが、 これらは非効率的で非推奨です。 使用しないでください)。

ネイティブ・トランスポート(つまり、 git:// URL)は認証を行わないため、セキュリティで保護されていないネットワークでは注意して使用する必要があります。

以下の構文を使用できます:

  • ssh://[<user>@]<host>[:<port>]/<path-to-git-repo>

  • git://<host>[:<port>]/<path-to-git-repo>

  • http[s]://<host>[:<port>]/<path-to-git-repo>

  • ftp[s]://<host>[:<port>]/<path-to-git-repo>

代替scp風の構文を、 sshプロトコルで使用することもできます:

  • [<user>@]<host>:/<path-to-git-repo>

この構文は、最初のコロン(:)の前にスラッシュがない場合にのみ認識されます。これは、コロンを含むローカル・パスを区別するのに役立ちます。たとえば、ローカル・パス foo:bar を、絶対パスまたは ./foo:bar として指定して、 ssh url として誤って解釈されないようにすることができます。

sshおよびgitプロトコルは、さらに ~<username> 拡張をサポートします:

  • ssh://[<user>@]<host>[:<port>]/~<user>/<path-to-git-repo>

  • git://<host>[:<port>]/~<user>/<path-to-git-repo>

  • [<user>@]<host>:~<user>/<path-to-git-repo>

ローカル・リポジトリーは、 Git によってネイティブにサポートされているため、 以下の構文を使用できます:

  • /path/to/repo.git/

  • file:///path/to/repo.git/

これら2つの構文はほとんど同等ですが、 clone 時には前者が --local オプションを意味します。 詳細は git-clone(1) を参照してください。

git clone と git fetch と git pull は、 git push と違って適切なバンドルファイルを受け入れます。 git-bundle(1) を参照してください。

Gitが特定のトランスポート・プロトコルを処理する方法を知らない場合、Gitは remote-<transport> リモート・ヘルパー(存在する場合)を使用しようとします。リモート・ヘルパーを明示的に要求するには、以下の構文を使用できます:

  • <transport>::<address>

ここで、 <address> は、パス、またはサーバーとパス、または呼び出されている特定のリモート・ヘルパーによって認識される任意のURLのような文字列です。詳細については、 gitremote-helpers(7) を参照してください。

同じ名前のリモートリポジトリが多数あり、それらに異なる形式を使用する場合(あなたの使用するURLが機能するURLに書き換えられるように)、以下の形式の構成セクションを作成できます:

        [url "<actual-url-base>"]
                insteadOf = <other-url-base>

例えば、以下のようになります:

        [url "git://git.host.xz/"]
                insteadOf = host.xz:/path/to/
                insteadOf = work:

work:repo.git や host.xz:/path/to/repo.git のようなURLは、任意のコンテキストで、 git://git.host.xz/repo.git に書き換えられます。

プッシュ専用のURLを書き換えたい場合は、以下の形式の構成セクションを作成できます:

        [url "<actual-url-base>"]
                pushInsteadOf = <other-url-base>

例えば、以下のようになります:

        [url "ssh://example.org/"]
                pushInsteadOf = git://example.org/

git://example.org/path/to/repo.git のようなURLは、プッシュの場合は ssh://example.org/path/to/repo.git に書き換えられますが、プルは引き続き元のURLのままです。

REMOTES

<repository> 引数として、URLの代わりに以下のいずれかの名前を使用できます:

  • Git構成ファイル(configuration file)内のリモート(remote)として、 $GIT_DIR/config または

  • $GIT_DIR/remotes ディレクトリ内のファイル または

  • $GIT_DIR/branches ディレクトリ内のファイル

これらはすべて、gitがデフォルトで使用するrefspecをそれぞれ含んでいるため、コマンドラインからrefspecを省略できます。

Named remote in configuration file

あなたは、 git-remote(1) を使うか、または git-config(1) を使うか、または $GIT_DIR/config ファイルを手動で編集して、これ以前に構成したリモートの名前から選択できます。このリモートのURLは、リポジトリーへのアクセスに使用されます。コマンドラインでrefspecを指定しない場合、このリモートのrefspecがデフォルトで使用されます。構成ファイルのエントリは以下のようになります:

        [remote "<name>"]
                url = <URL>
                pushurl = <pushurl>
                push = <refspec>
                fetch = <refspec>

<pushurl> は push でのみ使用されます。 これはオプションであり、 デフォルトは <URL> です。 リモートへの push は、 定義済の全ての pushurls に影響し、 pushurls が定義されていない場合は全ての定義済の URL に影響します。ただし、 複数の url が定義されている場合、 fetch 用は最初に定義された url のみです。

Named file in $GIT_DIR/remotes

あなたは、 $GIT_DIR/remotes でファイル名を指定できます。このファイルのURLは、リポジトリーへのアクセスに使用されます。コマンドラインでrefspecを指定しない場合、このファイルのrefspecがデフォルトとして使用されます。このファイルの形式は以下のとおりです:

        URL: one of the above URL formats
        Push: <refspec>
        Pull: <refspec>

Push: 行は git push で使用され、 Pull: 行は git pull と git fetch で使用されます。追加のブランチマッピングのために、複数の Push: および Pull: 行を指定できます。

Named file in $GIT_DIR/branches

$GIT_DIR/branches でファイル名を指定できます。このファイルのURLは、リポジトリーへのアクセスに使用されます。 このファイルの形式は以下のとおりです:

        <URL>#<head>

<URL> は必須です。 #<head> はオプションです。

コマンドラインで指定しない場合、操作に応じて、gitは以下のrefspecのいずれかを使用します。 <branch> は $GIT_DIR/branchs 内のこのファイルの名前であり、 <head> はデフォルトで master になります。

git fetch は以下を使用します:

        refs/heads/<head>:refs/heads/<branch>

git push は以下を使用します:

        HEAD:refs/heads/<head>

CONFIGURED REMOTE-TRACKING BRANCHES

あなたは、定期的かつ繰り返しフェッチすることで、同じリモートリポジトリとやり取りすることがよくあります。 このようなリモートリポジトリの進行状況を追跡するために、 git fetch では remote.<repository>.fetch 構成変数を構成できます。

通常、このような変数は以下のようになります:

[remote "origin"]
        fetch = +refs/heads/*:refs/remotes/origin/*

この構成は、以下の2つの方法で使用されます:

  • コマンドラインで取得するブランチやタグを指定せずに git fetch を実行した場合、例えば git fetch origin や git fetch では remote.<repository>.fetch の値が refspecs として使用され、取得する ref と更新するローカル ref を指定します。 上記の例では、origin に存在するすべてのブランチ(つまり、値の左辺 refs/heads/* にマッチするすべての ref)を取得し、対応するリモート追跡ブランチを refs/remotes/origin/* 階層にあるものに更新します。

  • フェッチするブランチやタグをコマンドラインで明示的に指定して、 git fetch を実行した場合、 たとえば git fetch origin master すると、コマンドラインで指定された <refspec> が何をフェッチするかを決定し(たとえば、この例の master は、 master: の省略形で、 「master ブランチを取得しますが、どのリモート追跡ブランチを更新するかはコマンドラインから明示的に指示しません」を意味します)、 サンプルコマンドは「master ブランチのみ」をフェッチします。 remote.<repository>.fetch 値は、更新されるリモート追跡ブランチがある場合はそれを決定します。 このような使い方をすると、 remote.<repository>.fetch 値は、「何をフェッチするか」を決定するのに効果がありません(つまり、コマンドラインに refspecs がリストされている場合、 remote.<repository>.fetch 値は refspecs として使用されません)。 これらは、マッピングとして機能することにより、フェッチされた ref がどこに保存されるかを決定するためにのみ使用されます。

後者の remote.<repository>.fetch 値の使用は、コマンドラインで --refmap=<refspec> パラメーターを指定することでオーバーライドできます。

PRUNING

【刈り込み】Gitには、明示的に破棄されない限り、データを保持するというデフォルトの性質があります。 これは、ブランチを削除したリモートのブランチへのローカル参照を保持することにまで及びます。

蓄積したままにしておくと、これらの古い参照は、ブランチの撹拌が多い大きく忙しいリポジトリでパフォーマンスを低下させる可能性があります。 git branch -a --contains <commit> のようなコマンドの出力を不必要に冗長にし、既知の参照の完全なセットで機能する他のすべてに影響を与えます。

これらのリモート追跡参照は、1回限りの利用で、以下のいずれかを使用して削除できます:

# While fetching
$ git fetch --prune <name>

# Only prune, don't fetch
$ git remote prune <name>

あなたの通常の作業フローの一部として参照を刈り込む(prune)には、それを実行することを覚えておく必要はありません。設定で fetch.prune をグローバルに設定するか、 remote.<name>.prune をリモート毎に設定します。 git-config(1) を参照してください。

ここで、物事がトリッキーでより具体的になります。 刈り込み機能は実際にはブランチを気にせず、代わりにリモートのrefspecの関数として local <--> remote-references を刈り込みます( <refspec> および 上記 CONFIGURED REMOTE-TRACKING BRANCHES 参照)。

したがって、リモートの refspec に、 たとえば refs/tags/*:refs/tags/* が含まれていたり、 手動でたとえば git fetch --prune <name> "refs/tags/*:refs/tags/*" を実行したりすると、削除されるのは古いリモート追跡ブランチではなく、リモートには存在しないローカルタグが削除されます。

これはあなたが期待したものではない可能性があります。つまり、リモート <name> を刈り込むだけでなく、そこからタグを明示的にフェッチするため、そこからフェッチするときに、すべてのローカルタグを削除します。 そのほとんどは、そもそも <name> リモートからのものではない可能性があります。

したがって、これを refs/tags/*:refs/tags/* のようなrefspec、または複数のリモートからの参照を同じローカル名前空間にマップする可能性のある他のrefspecで使用する場合は注意してください。

リモートのブランチとタグの両方を最新に保つことはよくあることなので、 --prune と一緒に --prune-tags オプションを指定することで、リモートに存在しないローカルタグを削除し、異なるタグを強制更新することができます。 タグの刈り込みは、設定ファイルの fetch.pruneTags や remote.<name>.pruneTags で有効にすることもできます。 git-config(1) を参照してください。

--prune-tags オプションは、「リモート」のrefspecsで refs/tags/*:refs/tags/* を宣言するのと同じです。 これは、一見奇妙な相互作用につながる可能性があります:

# These both fetch tags
$ git fetch --no-tags origin 'refs/tags/*:refs/tags/*'
$ git fetch --no-tags --prune-tags origin

--prune またはその構成変数版なしで提供されたときにエラーにならない理由は、構成変数版の柔軟性と、コマンドラインフラグの機能と構成変数版の機能の間の 一対一 のマッピングを維持するためです。

たとえば、 ~/.gitconfig で fetch.pruneTags=true を構成して、 --prune なしで git fetch を呼び出すたびにエラーが発生することなく、 git fetch --prune が実行されるたびにタグが刈り込まれるようにします。

--prune-tags によるタグの刈り込みは、名前付きリモートの代わりに URL を取得するときにも機能します。 以下はすべて、origin で見つからなかったタグを刈り込みます:

$ git fetch origin --prune --prune-tags
$ git fetch origin --prune 'refs/tags/*:refs/tags/*'
$ git fetch <url-of-origin> --prune --prune-tags
$ git fetch <url-of-origin> --prune 'refs/tags/*:refs/tags/*'

OUTPUT

git fetch の出力は、使用する転送方法によって異なります。 このセクションでは、Gitプロトコル(ローカルまたはssh経由)およびスマートHTTPプロトコルを介してフェッチする場合の出力について説明します。

フェッチのステータスは表形式で出力され、各行は単一のrefのステータスを表します。 各行の形式は以下のとおりです:

 <flag> <summary> <from> -> <to> [<reason>]

--porcelain を使用する場合、 出力形式は機械でパース可能(machine-parseable)であることが意図されています。 したがって、 人間が判読できる出力形式とは対照的に、 標準エラーではなく標準出力に出力されます。 各行の形式は以下のとおりです:

<flag> <old-object-id> <new-object-id> <local-reference>

最新のrefのステータスは、 --verbose オプションが使用されている場合にのみ表示されます。

構成変数fetch.outputで指定されたコンパクト出力モードでは、他の文字列に <from> または <to> 全体が見つかった場合、他の文字列内では * に置き換えられます。 たとえば、 master -> origin/master は master -> origin/* になります。

flag

refのステータスを示す1文字:

(space)

フェッチされた早送りの成功

+

強制更新の成功

-

refの刈り込みの成功

t

タグ更新の成功

*

新しいrefのフェッチの成功

!

拒否された、または更新に失敗したref

=

最新であり、フェッチする必要がなかったref

summary

成功裏にフェッチされたrefの場合、概要には、refの古い値と新しい値が git log の引数として使用するのに適した形式で表示されます(これはほとんどの場合 <old>..<new> であり、強制的な非早送り(non-fast-forward)更新の場合は <old>...<new> です)。

from

フェッチ元のリモート ref の名前から、その refs/<type>/ プレフィックスを差し引いたもの。 削除の場合、リモート ref の名前は (none) です。

to

更新されるローカルrefの名前から、その refs/<type>/ プレフィックスを差し引いたもの。

reason

人間が読める説明。 正常にフェッチされたrefの場合、説明は必要ありません。 失敗したrefについては、失敗の理由が説明されています。

EXAMPLES

  • リモート追跡ブランチを更新します: 

    $ git fetch origin

    上記のコマンドは、 branch.<name>.fetch オプションを使用してデフォルト以外のrefspecを指定しない限り、 すべてのブランチをリモートの refs/heads/ 名前空間からコピーし、 ローカルの refs/remotes/origin/ 名前空間に格納します。

  • refspecsの明示的な使用: 

    $ git fetch origin +seen:seen maint:tmp

    これにより、リモートリポジトリからブランチ seen と maint を(それぞれ)フェッチすることにより、ローカルリポジトリでブランチ seen と tmp が更新(または必要に応じて作成)されます。

    seen ブランチは、接頭辞にプラス記号(+)が付いているため、早送りしなくても更新されます。 tmp はそうしません。

  • あなたのローカルリポジトリで「リモート」を構成せずに、リモートのブランチをちらっと見ます(peek): 

    $ git fetch git://git.kernel.org/pub/scm/git/git.git maint
$ git log FETCH_HEAD

    最初のコマンドは git://git.kernel.org/pub/scm/git/git.git のリポジトリから maint ブランチをフェッチし、2番目のコマンドは FETCH_HEAD を使用して git-log(1) でブランチを調べます。 フェッチされたオブジェクトは、最終的にgitの組み込みの家政婦(housekeeping)によって削除されます(git-gc(1) を参照)。

SECURITY

フェッチ・プロトコルやプッシュ・プロトコルは、 共有することを意図していない一方の側が他方のリポジトリからデータを盗むのを防ぐようには設計されていません。悪意のある者から保護する必要のあるプライベートデータがある場合、最善のオプションはそれを別のリポジトリに保存することです。これは、クライアントとサーバーの両方に適用されます。特に、サーバー上の名前空間は、読み取りアクセス制御には効果的ではありません。リポジトリ全体への読み取りアクセスで信頼できるクライアントにのみ、名前空間への読み取りアクセスを許可する必要があります。

既知の攻撃ベクトル(attack vectors)は以下のとおりです:

  1. 被害者は have 行を送信して、 所有しているオブジェクトのIDを広告(advertise)します。 これらのIDは明示的に共有されることを意図していませんが、 相手(peer)もそれを持っている場合に転送を最適化するために使用できます。 攻撃者は盗むオブジェクトID Xを選択して、 X への ref 送信しますが、 被害者はすでにXのコンテンツを持っているため、 Xのコンテンツを送信する必要はありません。 これで、 被害者は攻撃者がXを持っていると信じ、 X のコンテンツを後で攻撃者に送り返します。 (この攻撃は、クライアントがアクセスできる名前空間に X への ref を作成してフェッチすることにより、 クライアントがサーバー上で実行するのが最も簡単です。 サーバーがクライアント上で実行する最も可能性の高い方法は、 X をパブリック・ブランチにマージし、ユーザーがこのブランチで追加の作業を行い、マージに気付かずにサーバーにプッシュバックすることを期待します。)

  2. #1 と同様に、攻撃者は盗むオブジェクトID Xを選択します。被害者は、攻撃者がすでに持っているオブジェクトYを送信し、攻撃者はYではなくXを持っていると誤って主張するため、被害者はYをXに対するデルタとして送信します。デルタは、攻撃者にYに類似したXの領域を明らかにします。

CONFIGURATION

このセクションの以下のすべては、 git-config(1) ドキュメントの抜粋です。 内容は git-config(1) ドキュメント にあるものと同一です:

fetch.recurseSubmodules

このオプションは、 git fetch(および git pull の基になるフェッチ)が入力されたサブモジュールに再帰的にフェッチするかどうかを制御します。 このオプションは、ブール値または on-demand のいずれかに設定できます。 ブール値に設定すると、フェッチとプルの動作が変更され、trueに設定されている場合は無条件にサブモジュールに再帰し、falseに設定されている場合はまったく再帰しません。 on-demand に設定すると、フェッチとプルは、スーパープロジェクトがサブモジュールの参照を更新するコミットを取得したときにのみ、入力されたサブモジュールに再帰します。 デフォルトは on-demand 、または submodule.recurse が設定されている場合はその値です。

fetch.fsckObjects

trueに設定されている場合、git-fetch-packはフェッチされたすべてのオブジェクトをチェックします。 チェックされる内容については、 transfer.fsckObjects を参照してください。 デフォルトはfalseです。 設定されていない場合は、代わりに transfer.fsckObjects の値が使用されます。

fetch.fsck.<msg-id>

fsck.<msg-id> のように機能しますが、 git-fsck(1) の代わりに git-fetch-pack(1) によって使用されます。 詳細については、 fsck.<msg-id> のドキュメントを参照してください。

fetch.fsck.skipList

fsck.skipList のように機能しますが、 git-fsck(1) の代わりに git-fetch-pack(1) によって使用されます。 詳細については、 fsck.skipList のドキュメントを参照してください。

fetch.unpackLimit

Gitネイティブ転送を介してフェッチされるオブジェクトの数がこの制限を下回る場合、オブジェクトは緩いオブジェクト(loose object)ファイルに解凍されます。 ただし、受信したオブジェクトの数がこの制限以上の場合、受信したパックは、欠落しているデルタベースを追加した後、パックとして保存されます。 プッシュからパックを保存すると、特に低速のファイルシステムで、プッシュ操作をより速く完了することができます。 これが設定されていない場合は、代わりに transfer.unpackLimit の値が使用されます。

fetch.prune

trueの場合、fetchはコマンドラインで --prune オプションが指定されたかのように自動的に動作します。 remote.<name>.prune および git-fetch(1) の「PRUNING」セクションも参照してください。

fetch.pruneTags

trueの場合、フェッチは、まだ設定されていない場合、刈り込み(pruning)時に refs/tags/*:refs/tags/* refspecが提供されたかのように自動的に振る舞います。 これにより、このオプションと fetch.prune の両方を設定して、アップストリーム参照への 1=1 マッピングを維持できます。 remote.<name>.pruneTags および git-fetch(1) の「PRUNING」セクションも参照してください。

fetch.all

true の場合、 fetch は使用可能なすべてのリモートの更新を試みます。 この動作は、 --no-all を渡すか、 または、 取得先の 1 つ以上のリモートを明示的に指定することによってオーバーライドできます。 デフォルトは false です。

fetch.output

ref updateステータスの出力方法を制御します。 有効な値は full と compact です。 デフォルト値は full です。 詳細については、 git-fetch(1) の「OUTPUT」セクションを参照してください。

fetch.negotiationAlgorithm

サーバーによって送信されるパックファイルの内容をネゴシエートするときに、ローカルリポジトリ内のコミットに関する情報がどのように送信されるかを制御します。 consecutive に設定すると、連続したコミットをそれぞれチェックするアルゴリズムを使用します。 skipping に設定すると、収束を高速化するためにコミットをスキップするアルゴリズムが使用されますが、必要以上の大きさのパックファイルが生成される可能性があります。 または、 noop に設定して情報をまったく送信しないようにします。これにより、ほぼ確実に必要以上に大きなパックファイルが生成されますが、ネゴシエーション・ステップはスキップされます。 default に設定すると、それ以前に行われた設定をオーバーライドしてデフォルトの振る舞いをします。 デフォルトは通常 consecutive ですが、 feature.experimental が true の場合、デフォルトは skipping です。 値が不明な場合、 git fetch でエラーが発生します。

git-fetch(1) の --negotiate-only および --negotiation-tip オプションも参照してください。

fetch.showForcedUpdates

falseに設定すると、 git-fetch(1) および git-pull(1) コマンドで --no-show-forced-updates が有効になります。 デフォルトはtrueです。

fetch.parallel

一度に並行して実行されるフェッチ操作の最大数を指定します(サブモジュール、または、git-fetch(1) の --multiple オプションが有効な場合はリモート)。

値0は、適切なデフォルトを提供します。 設定されていない場合、デフォルトで1になります。

サブモジュールの場合、この設定は、 submodule.fetchJobs 構成設定を使用してオーバーライドできます。

fetch.writeCommitGraph

リモートからパックファイルをダウンロードするすべての git fetch コマンドの後でcommit-graphを書き込むには、trueに設定します。 --split オプションを使用すると、ほとんどの実行で、既存のcommit-graphファイルの上に非常に小さなcommit-graphファイルが作成されます。 場合によっては、これらのファイルがマージされ、書き込みに時間がかかることがあります。 更新されたcommit-graphファイルがあると、 git merge-base や git push -f や git log --graph などの多くのGitコマンドのパフォーマンス改善に役立ちます。 デフォルトはfalseです。

fetch.bundleURI

この値には、 元の Git サーバーからの増分フェッチを実行する前に、 バンドル URI から Git オブジェクト・データをダウンロードするための URI が格納されます。これは、 git-clone(1) の --bundle-uri オプションの動作に似ています。 指定されたバンドル URI に増分フェッチ用に編成されたバンドル・リストが含まれている場合、git clone --bundle-uri では fetch.bundleURI 値を設定します。

あなたが、 この値を変更し、 かつ、 あなたのリポジトリに fetch.bundleCreationToken 値がある場合、 新しいバンドル URI からフェッチする前に、 fetch.bundleCreationToken 値を削除してください。

fetch.bundleCreationToken

fetch.bundleURI を使用して「creationToken」ヒューリスティックを使用するバンドル・リストから増分フェッチする場合、 この設定値には、 ダウンロードされたバンドルの、 最大 creationToken 値が格納されます。 この値は、 通知された creationToken がこの値を超えない限り、 その後のバンドルがダウンロードされないようにするために使用されます。

作成トークン(creation token)の値は、 指定のバンドル URI を提供しているプロバイダーが使います。 fetch.bundleURI で URI を変更する場合は、 フェッチする前に必ず fetch.bundleCreationToken 値を削除してください。

BUGS

--recurse-submodules を使用すると、ローカルに存在するサブモジュール、たとえば $GIT_DIR/modules/ 内の新しいコミットのみを取得(fetch)できます。 アップストリームが新しいサブモジュールを追加した場合、そのサブモジュールは、たとえば git submodule update によるクローンが作成されるまで取得(fetch)できません。 これは、将来の Git バージョンで修正される予定です。

SEE ALSO

git-pull(1)

GIT

Part of the git(1) suite