Git
English ▾ トピック ▾ 最新バージョン ▾ git-fetch は 2.46.2 で最後に更新されました

名前

git-fetch - 別のリポジトリからオブジェクトとリファレンスをダウンロードします

概要

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

説明

ブランチやタグ（まとめて「リファレンス」）と、それらの履歴を完成させるために必要なオブジェクトを、1つ以上の他のリポジトリからフェッチします。リモート追跡ブランチは更新されます（この動作を制御する方法については、以下の<refspec>の説明を参照してください）。

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

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

リモートが指定されていない場合、デフォルトでは現在のブランチに設定されているアップストリームブランチがない限り、originリモートが使用されます。

フェッチされたリファレンスの名前とその名前が指すオブジェクト名は、.git/FETCH_HEADに書き込まれます。この情報は、git-pull[1]などのスクリプトや他のgitコマンドで使用できます。

オプション

--[no-]all

remote.<name>.skipFetchAll設定変数が設定されているものを除くすべてのリモートをフェッチします。これは設定変数fetch.allを上書きします。

-a
--append

フェッチされたリファレンスのリファレンス名とオブジェクト名を、.git/FETCH_HEADの既存の内容に追加します。このオプションがないと、.git/FETCH_HEADの古いデータは上書きされます。

--atomic

ローカルリファレンスを更新するためにアトミックトランザクションを使用します。すべてのリファレンスが更新されるか、エラーが発生すると、リファレンスは更新されません。

--depth=<depth>

各リモートブランチ履歴の先端から指定された数のコミットまでフェッチを制限します。git cloneで--depth=<depth>オプションを使用して作成された浅いリポジトリ（git-clone[1]を参照）にフェッチする場合、履歴を指定された数のコミットまで深くするか短くします。深くなったコミットのタグはフェッチされません。

--deepen=<depth>

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

--shallow-since=<date>

<date>以降に到達可能なすべてのコミットを含めるように、浅いリポジトリの履歴を深くするか短くします。

--shallow-exclude=<revision>

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

--unshallow

ソースリポジトリが完全な場合、浅いリポジトリを完全なものに変換し、浅いリポジトリによって課せられたすべての制限を削除します。

ソースリポジトリが浅い場合、現在のリポジトリがソースリポジトリと同じ履歴を持つように、可能な限り多くのものをフェッチします。

--update-shallow

浅いリポジトリからフェッチする場合、デフォルトではgit fetchは.git/shallowの更新を必要とするリファレンスを拒否します。このオプションは.git/shallowを更新し、そのようなリファレンスを受け入れます。

--negotiation-tip=<commit|glob>

デフォルトでは、Gitは受信するpackファイルのサイズを削減するために、共通のコミットを見つけるために、すべてのローカルリファレンスから到達可能なコミットをサーバーに報告します。指定された場合、Gitは指定された先端から到達可能なコミットのみを報告します。これは、ユーザーがどのローカルリファレンスがフェッチされるアップストリームリファレンスと共通のコミットを持つ可能性が高いかを知っている場合に、フェッチの高速化に役立ちます。

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

このオプションの引数は、リファレンス名のパターン、リファレンス、またはコミットの（おそらく省略された）SHA-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ファイルに、フェッチされたリモートリファレンスのリストを直接書き込みます。これがデフォルトです。コマンドラインから--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

フェッチ後にコミットグラフを書き込みます。これは設定fetch.writeCommitGraphを上書きします。

--prefetch

設定済みのrefspecを変更して、すべてのrefを`refs/prefetch/`名前空間に配置します。 git-maintenance[1]の`prefetch`タスクを参照してください。

-p
--prune

フェッチする前に、リモートに存在しなくなったリモート追跡参照をすべて削除します。タグは、デフォルトのタグ自動追従または`--tags`オプションのためにのみフェッチされた場合は、プルーニングの対象になりません。ただし、コマンドラインまたはリモート設定で明示的なrefspecを介してタグがフェッチされた場合（たとえば、リモートが`--mirror`オプションでクローンされた場合）、タグもプルーニングの対象になります。`--prune-tags`を指定すると、タグrefspecを提供することの省略形になります。

詳細は、以下のPRUNINGセクションを参照してください。

-P
--prune-tags

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

詳細は、以下のPRUNINGセクションを参照してください。

-n
--no-tags

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

--refetch

既にローカルに存在するコミットおよび関連オブジェクトの転送を回避するためにサーバーとネゴシエートする代わりに、このオプションは、新しいクローンと同様にすべてのオブジェクトをフェッチします。フィルター定義が変更された場合、構成から部分クローンフィルターを再適用するか、`--filter=`を使用してこれを使用します。自動ポストフェッチメンテナンスは、重複オブジェクトを削除するためにオブジェクトデータベースパックの統合を実行します。

--refmap=<refspec>

コマンドラインにリストされているrefをフェッチする際に、リモートリポジトリの`remote.*.fetch`設定変数の値ではなく、指定されたrefspec（複数回指定できます）を使用して、refをリモート追跡ブランチにマップします。`--refmap`オプションに空の`<refspec>`を提供すると、Gitは設定されたrefspecを無視し、コマンドライン引数として提供されたrefspecに完全に依存します。「設定済みのリモート追跡ブランチ」セクションで詳細を参照してください。

-t
--tags

その他にフェッチされるものに加えて、リモートからすべてのタグをフェッチします（つまり、リモートタグ`refs/tags/*`を同じ名前のローカルタグにフェッチします）。このオプションのみを使用しても、`--prune`を使用しても、タグはプルーニングの対象になりません（ただし、明示的なrefspecの宛先でもある場合は、タグがプルーニングされる可能性があります。`--prune`を参照）。

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

このオプションは、サブモジュールの新しいコミットもフェッチするかどうか、そしてどのような条件下でフェッチするのかを制御します。サブモジュールを再帰的に処理する場合、`git fetch`は常に「変更された」サブモジュールをフェッチしようとします。つまり、新しくフェッチされたスーパープロジェクトコミットによって参照されるが、ローカルサブモジュールクローンには存在しないコミットを持つサブモジュールです。変更されたサブモジュールは、ローカルに存在する限り（例：`$GIT_DIR/modules/`内）（gitsubmodules[7]を参照）フェッチできます。アップストリームが新しいサブモジュールを追加した場合、そのサブモジュールは、`git submodule update`などによってクローンされるまでフェッチできません。

on-demandに設定されている場合、変更されたサブモジュールのみがフェッチされます。yesに設定されている場合、すべての設定済みのサブモジュールがフェッチされ、設定されておらず変更されたサブモジュールもフェッチされます。noに設定されている場合、サブモジュールは決してフェッチされません。

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

-j
--jobs=<n>

すべてのフェッチ形式に使用される並列子プロセスの数。

`--multiple`オプションが指定されている場合、異なるリモートが並列にフェッチされます。複数のサブモジュールがフェッチされる場合、それらは並列にフェッチされます。それらを個別に制御するには、`fetch.parallel`と`submodule.fetchJobs`の設定を使用します（git-config[1]を参照）。

通常、並列再帰的およびマルチリモートフェッチの方が高速です。デフォルトでは、フェッチは並列ではなく、順次実行されます。

--no-recurse-submodules

サブモジュールの再帰的フェッチを無効にします（これは`--recurse-submodules=no`オプションを使用した場合と同じ効果があります）。

--set-upstream

リモートが正常にフェッチされた場合、引数なしのgit-pull[1]やその他のコマンドで使用されるアップストリーム（追跡）参照を追加します。詳細については、git-config[1]の`branch.<name>.merge`と`branch.<name>.remote`を参照してください。

--submodule-prefix=<path>

「サブモジュールfooをフェッチ中」などの情報メッセージに表示されるパスに<path>をプリペンドします。このオプションは、サブモジュールを再帰的に処理する際に内部で使用されます。

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

このオプションは、`--recurse-submodules`オプションに非負のデフォルト値を一時的に提供するために内部で使用されます。gitmodules[5]とgit-config[1]の設定など、フェッチのサブモジュール再帰を設定する他のすべての方法は、このオプションよりも優先され、`--[no-]recurse-submodules`を直接指定した場合も同様です。

-u
--update-head-ok

デフォルトでは、`git fetch`は現在のブランチに対応するヘッドの更新を拒否します。このフラグはチェックを無効にします。これは純粋に`git pull`が`git fetch`と通信するために内部的に使用されるものであり、独自のPorcelainを実装していない限り、使用しないでください。

--upload-pack <upload-pack>

指定され、フェッチするリポジトリが`git fetch-pack`によって処理される場合、`--exec=<upload-pack>`がコマンドに渡され、反対側で実行されるコマンドのデフォルト以外のパスが指定されます。

-q
--quiet

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

-v
--verbose

詳細情報を表示します。

--progress

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

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

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

--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`オプションは、高速フォワード更新を試行する前に、強制更新をチェックします。git-config[1]を参照してください。

-4
--ipv4

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

-6
--ipv6

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

<repository>

フェッチまたはプル操作のソースである「リモート」リポジトリ。このパラメーターは、URL（以下のGIT URLSセクションを参照）またはリモートの名前（以下のREMOTESセクションを参照）のいずれかになります。

<group>

構成ファイルの`remotes.<group>`の値として、リポジトリのリストを参照する名前。（git-config[1]を参照）。

<refspec>

フェッチするrefと更新するローカルrefを指定します。コマンドラインに<refspec>が表示されない場合、代わりに`remote.<repository>.fetch`変数からフェッチするrefが読み取られます（以下の設定済みのリモート追跡ブランチを参照）。

<refspec>パラメーターの形式は、オプションのプラス記号`+`、それに続くソース<src>、コロン`:`、それに続く宛先ref<dst>です。<dst>が空の場合、コロンを省略できます。<src>は通常refですが、完全な16進オブジェクト名にすることもできます。

<refspec>には、単純なパターンマッチを示す<src>に`*`を含めることができます。このようなrefspecは、同じプレフィックスを持つすべてのrefと一致するglobのように機能します。パターン<refspec>には、<src>と<dst>の両方に`*`が必要です。ソースから一致した内容を`*`で置き換えることによって、refを宛先にマップします。

refspecに`^`をプレフィックスとして付けると、ネガティブrefspecとして解釈されます。フェッチするrefsや更新するローカルrefsを指定するのではなく、除外するrefsを指定します。refは、少なくとも1つのポジティブrefspecに一致し、ネガティブrefspecに一致しない場合に一致するとみなされます。ネガティブrefspecは、パターンrefspecの範囲を制限して、特定のrefsを含めないようにする場合に役立ちます。ネガティブrefspec自体はパターンrefspecにすることができます。ただし、``のみを含み、``は指定できません。完全な16進オブジェクト名もサポートされていません。

`tag `は`refs/tags/:refs/tags/`と同じ意味です。指定されたタグまでのすべてをフェッチすることを要求します。

に一致するリモートrefがフェッチされ、が空文字列でない場合は、それに一致するローカルrefを更新しようとします。

`--force`なしでその更新が許可されるかどうかは、フェッチ先のref名前空間、フェッチされるオブジェクトの種類、更新が高速フォワードと見なされるかどうかによって異なります。一般的に、フェッチの場合とプッシュの場合で同じルールが適用されます。詳細は、git-push[1]の`...`セクションを参照してください。git fetchに固有のそれらのルールの例外については、以下に記載されています。

Gitバージョン2.20までは、git-push[1]によるプッシュ時とは異なり、`refs/tags/*`への更新は、refspecに`+`がない場合（または`--force`を使用しない場合）に受け入れられました。フェッチ時には、リモートからのすべてのタグ更新を強制フェッチと無差別にみなしていました。Gitバージョン2.20以降は、`refs/tags/*`を更新するためのフェッチはプッシュ時と同じように動作します。つまり、refspecに`+`がない場合（または`--force`を使用しない場合）、更新は拒否されます。

git-push[1]によるプッシュ時とは異なり、`refs/{tags,heads}/*`以外の更新は、refspecに`+`がない場合（または`--force`を使用しない場合）、ツリーオブジェクトとブロブの交換、または以前のコミットを祖先として持たない別のコミットへのコミットの交換など、受け入れられます。

git-push[1]によるプッシュ時とは異なり、これらのルールを変更する設定はなく、`pre-receive`フックと同様の`pre-fetch`フックもありません。

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

注記
 フェッチするリモートブランチが定期的に巻き戻しとリベースが行われることがわかっている場合、その新しい先端が（最後にフェッチしたときにリモートトラッキングブランチに保存されている）以前の先端の子孫ではないことが予想されます。このようなブランチには、非高速フォワード更新が必要になることを示すために`+`記号を使用する必要があります。ブランチがこのような動作でリポジトリで使用可能になることを決定または宣言する方法はありません。プルするユーザーは、これがブランチの予想される使用方法であることを知っている必要があります。
--stdin

引数として提供されたものに加えて、stdinから1行ずつrefspecを読み取ります。「tag 」形式はサポートされていません。

Git URL

一般的に、URLには、転送プロトコル、リモートサーバーのアドレス、リポジトリへのパスに関する情報が含まれています。転送プロトコルによっては、これらの情報の一部が存在しない場合があります。

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

ネイティブ転送（つまり、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>

sshプロトコルでは、代替のscpのような構文も使用できます。

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

この構文は、最初のコロンの前にスラッシュがない場合にのみ認識されます。これにより、コロンを含むローカルパスとの区別が容易になります。たとえば、ローカルパス`foo:bar`は絶対パスとして指定するか、誤解を避けるために`./foo:bar`として指定できます。

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ネイティブでもサポート）には、次の構文を使用できます。

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

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

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"のようなURLまたは"host.xz:/path/to/repo.git"のようなURLは、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を引き続き使用します。

リモート

<repository>引数の代わりに、次のいずれかの名前を使用できます。

  • Git設定ファイルのリモート：`$GIT_DIR/config`、

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

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

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

設定ファイル内の名前付きリモート

git-remote[1]、git-config[1]、または`$GIT_DIR/config`ファイルの手動編集によって以前に設定したリモートの名前を指定できます。このリモートのURLは、リポジトリへのアクセスに使用されます。このリモートのrefspecは、コマンドラインでrefspecを指定しない場合のデフォルトとして使用されます。設定ファイルのエントリは次のようになります。

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

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

`$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:`行を指定できます。

`$GIT_DIR/branches`内の名前付きファイル

`$GIT_DIR/branches`内のファイルの名前を指定できます。このファイルのURLは、リポジトリへのアクセスに使用されます。このファイルは次の形式である必要があります。

	<URL>#<head>

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

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

git fetchは使用します。

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

git pushは使用します。

	HEAD:refs/heads/<head>

設定済みのリモートトラッキングブランチ

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

通常、このような変数は次のようになります。

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

この設定は2つの方法で使用されます。

  • コマンドラインでフェッチするブランチやタグを指定せずにgit fetchを実行する場合（例：git fetch originまたはgit fetch）、remote.<repository>.fetchの値がrefspecとして使用されます。これらは、フェッチするrefと更新するローカルrefを指定します。上記の例では、`origin`に存在するすべてのブランチ（値の左側、`refs/heads/*`に一致するref）をフェッチし、`refs/remotes/origin/*`階層内の対応するリモートトラッキングブランチを更新します。

  • コマンドラインで明示的にブランチやタグを指定してgit fetchを実行した場合（例：git fetch origin master）、コマンドラインで指定された``がフェッチする対象を決定します（例ではmasterで、これはmaster:の省略形であり、「masterブランチをフェッチするが、コマンドラインからどのリモートトラッキングブランチで更新するかを明示的には指定しない」という意味です）。この例のコマンドはmasterブランチのみをフェッチします。remote.<repository>.fetchの値は、リモートトラッキングブランチが更新されるかどうかを決定します。このように使用する場合、remote.<repository>.fetchの値は何をフェッチするかを決定する際には影響を与えません（つまり、コマンドラインでrefspecがリストされている場合、refspecとしてこれらの値は使用されません）。これらの値は、マッピングとして機能することで、フェッチされたrefがどこに保存されるかを決定するためにのみ使用されます。

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

プルーニング

Gitは、明示的に破棄されない限りデータを保持するというデフォルトの動作を持っています。これは、リモート上のブランチがそれ自体で削除された後も、それらへのローカル参照を保持することにまで及びます。

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

これらのリモートトラッキング参照は、以下のいずれかの方法で一度限りの操作として削除できます。

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

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

この操作を毎回実行する必要なく、通常のワークフローの一部として参照をプルーニングするには、グローバルにfetch.prune、またはリモートごとにremote.<name>.pruneをconfigに設定します。git-config[1]を参照してください。

ここで、より複雑で具体的な部分になります。プルーニング機能は実際にはブランチを気にしません。代わりに、リモートのrefspecの関数としてローカル←→リモート参照をプルーニングします（<refspec>と上記の構成されたリモートトラッキングブランチを参照）。

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

これは期待する動作ではないかもしれません。つまり、リモート<name>をプルーニングしたいが、そこからタグを明示的にフェッチも行いたい場合、フェッチすると、ほとんどが<name>リモートから取得されたものではない可能性のあるローカルタグがすべて削除されます。

そのため、refs/tags/*:refs/tags/*のようなrefspec、または複数のリモートからの参照を同じローカル名前空間にマッピングする可能性のある他のrefspecと共にこれを使用する際には注意が必要です。

リモート上のブランチとタグの両方を最新の状態に保つことは一般的なユースケースであるため、--pruneと共に--prune-tagsオプションを指定して、リモートに存在しないローカルタグをプルーニングし、異なるタグを強制的に更新することができます。タグのプルーニングは、configでfetch.pruneTagsまたはremote.<name>.pruneTagsを有効にすることでも可能です。git-config[1]を参照してください。

--prune-tagsオプションは、リモートのrefspecに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またはそのconfigバージョンなしで指定してもエラーにならない理由は、構成されたバージョンの柔軟性のため、およびコマンドラインフラグと構成バージョンの間の1対1のマッピングを維持するためです。

例えば、~/.gitconfigでfetch.pruneTags=trueを設定して、git fetch --pruneを実行するたびにタグをプルーニングすることは妥当であり、--pruneなしでgit fetchを呼び出すたびにエラーにする必要はありません。

--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/*'

出力

「git fetch」の出力は使用される転送方法によって異なります。このセクションでは、Gitプロトコル（ローカルまたはssh経由）とSmart HTTPプロトコルでフェッチする場合の出力を説明します。

フェッチの状態は表形式で出力され、各行は単一のrefの状態を表します。各行は次の形式になります。

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

--porcelainを使用する場合、出力形式は機械で解析することを目的としています。人間が読み取れる出力形式とは対照的に、標準エラーではなく標準出力に出力します。各行は次の形式になります。

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

最新の状態のrefの状態は、--verboseオプションを使用した場合にのみ表示されます。

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

フラグ

refの状態を示す単一文字

(スペース)

正常にフェッチされた高速フォワードの場合。

+

正常に強制更新された場合。

-

正常にプルーニングされたrefの場合。

t

正常にタグが更新された場合。

*

正常に新しいrefがフェッチされた場合。

!

拒否されたか、更新に失敗したrefの場合。

=

最新の状態であり、フェッチする必要がなかったrefの場合。

要約

正常にフェッチされたrefの場合、要約には、git logの引数として使用できる適切な形式でrefの古い値と新しい値が表示されます（ほとんどの場合<old>..<new>、強制的な非高速フォワード更新の場合は<old>...<new>）。

from

フェッチ元のリモートrefの名前で、refs/<type>/プレフィックスは除きます。削除された場合は、リモートrefの名前は"(none)"になります。

to

更新されたローカルrefの名前で、refs/<type>/プレフィックスは除きます。

理由

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

例

  • リモートトラッキングブランチの更新

    $ git fetch origin

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

  • refspecの明示的な使用

    $ git fetch origin +seen:seen maint:tmp

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

    seenブランチは、高速フォワードでなくても、プラス記号で始まるため更新されます。tmpは更新されません。

  • ローカルリポジトリにリモートを構成せずに、リモートのブランチを覗き見する

    $ 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の組み込みハウスキーピングによって削除されます（git-gc[1]を参照）。

セキュリティ

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

既知の攻撃ベクトルは以下のとおりです。

  1. 被害者は、明示的に共有する意図はないが、ピアも持っている場合に転送を最適化するために使用できるオブジェクトのIDを宣伝する"have"行を送信します。攻撃者は盗むオブジェクトID Xを選択し、Xへのrefを送信しますが、被害者が既に持っているため、Xの内容を送信する必要はありません。これで、被害者は攻撃者がXを持っていると信じ込み、後でXの内容を攻撃者に送り返します。（この攻撃は、クライアントがアクセスできる名前空間にXへのrefを作成してフェッチすることで、クライアントがサーバーに対して実行するのが最も簡単です。サーバーがクライアントに対して実行する最も可能性の高い方法は、Xをパブリックブランチに「マージ」し、ユーザーがこのブランチで追加の作業を行い、マージに気付かずにサーバーにプッシュすることを期待することです。）

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

設定

このセクションのこの行の下にあるすべての内容は、git-config[1]ドキュメントから選択的に含まれています。内容はそこに記載されているものと同じです。

fetch.recurseSubmodules

このオプションは、git fetch（およびgit pullの基本となるfetch）がpopulated（中身のある）サブモジュールに再帰的にフェッチするかどうかを制御します。このオプションは、ブール値またはon-demandに設定できます。ブール値に設定すると、trueに設定するとサブモジュールに無条件に再帰的にフェッチとプルを行い、falseに設定するとまったく再帰しません。on-demandに設定すると、そのスーパープロジェクトがサブモジュールの参照を更新するコミットを取得する場合にのみ、populatedサブモジュールに再帰します。デフォルトは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-fetch-pack[1]によって使用され、git-fsck[1]では使用されません。詳細はfsck.skipListのドキュメントを参照してください。

fetch.unpackLimit

Gitネイティブ転送でフェッチされたオブジェクト数がこの制限を下回る場合、オブジェクトはルーズオブジェクトファイルに展開されます。ただし、受信したオブジェクト数がこの制限に達するかそれを超える場合、不足しているデルタベースを追加した後に、受信したパックはパックとして保存されます。プッシュからのパックの保存は、特にファイルシステムが遅い場合、プッシュ操作の完了を高速化できます。設定されていない場合、代わりにtransfer.unpackLimitの値が使用されます。

fetch.prune

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

fetch.pruneTags

trueの場合、既に設定されていない場合は、削除時にrefs/tags/*:refs/tags/* refspecが提供された場合と同様にfetchが動作します。これにより、このオプションとfetch.pruneの両方を設定して、上流のrefsとの1対1のマッピングを維持できます。remote.<name>.pruneTagsおよびgit-fetch[1]のPRUNINGセクションも参照してください。

fetch.all

trueの場合、fetchは利用可能なすべてのリモートの更新を試みます。この動作は、--no-allを渡すか、フェッチするリモートを1つ以上明示的に指定することで上書きできます。デフォルトはfalseです。

fetch.output

ref更新状況の出力方法を制御します。有効な値はfullとcompactです。デフォルト値はfullです。詳細はgit-fetch[1]のOUTPUTセクションを参照してください。

fetch.negotiationAlgorithm

サーバーによって送信されるパックファイルの内容をネゴシエートするときに、ローカルリポジトリ内のコミットに関する情報がどのように送信されるかを制御します。連続したコミットを1つずつ確認するアルゴリズムを使用するには、「consecutive」に設定します。「skipping」に設定すると、より高速に収束するアルゴリズムが使用されますが、必要以上に大きなパックファイルになる可能性があります。「noop」に設定すると、情報はまったく送信されません。これにより、必要以上に大きなパックファイルになることはほぼ確実ですが、ネゴシエーションステップはスキップされます。「default」に設定すると、以前に設定された設定を上書きしてデフォルトの動作を使用します。デフォルトは通常「consecutive」ですが、feature.experimentalがtrueの場合、デフォルトは「skipping」になります。不明な値は、git fetchのエラーの原因となります。

git-fetch[1]の--negotiate-onlyオプションと--negotiation-tipオプションも参照してください。

fetch.showForcedUpdates

git-fetch[1]コマンドとgit-pull[1]コマンドで--no-show-forced-updatesを有効にするには、falseに設定します。デフォルトはtrueです。

fetch.parallel

同時に並列実行されるフェッチ操作の最大数を指定します（git-fetch[1]の--multipleオプションが有効な場合のサブルーチンまたはリモート）。

値が0の場合、妥当なデフォルト値が使用されます。設定されていない場合は、1になります。

サブルーチンでは、この設定はsubmodule.fetchJobs config設定を使用して上書きできます。

fetch.writeCommitGraph

リモートからパックファイルをダウンロードするgit fetchコマンドごとにコミットグラフを書き込むには、trueに設定します。--splitオプションを使用すると、ほとんどの実行で既存のコミットグラフファイルの上に非常に小さいコミットグラフファイルが作成されます。場合によっては、これらのファイルがマージされ、書き込みに時間がかかることがあります。更新されたコミットグラフファイルを使用すると、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

"creationToken"ヒューリスティックを使用するバンドルリストから増分フェッチにfetch.bundleURIを使用する場合、このconfig値は、ダウンロードされたバンドルの最大creationToken値を保存します。この値は、広告されたcreationTokenがこの値よりも厳密に大きい場合にのみ、将来バンドルをダウンロードしないようにするために使用されます。

creation token値は、特定のバンドルURIを提供するプロバイダーによって選択されます。fetch.bundleURIのURIを変更する場合は、フェッチする前にfetch.bundleCreationToken値の値を削除してください。

バグ

--recurse-submodulesを使用すると、ローカルに存在するサブルーチン（例：$GIT_DIR/modules/内）で新しいコミットのみをフェッチできます。上流が新しいサブルーチンを追加した場合、そのサブルーチンは（例：git submodule updateによって）クローンされるまでフェッチできません。これは、将来のGitバージョンで修正される予定です。

参照

git-pull[1]

Git

git[1]スイートの一部

scroll-to-top