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

名前

git-fetch - 別のリポジトリからオブジェクトと参照をダウンロード

概要

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

説明

他の1つ以上のリポジトリから、ブランチやタグ（総称して「ref」）を、それらの履歴を完結させるために必要なオブジェクトとともにフェッチします。リモート追跡ブランチは更新されます（この動作を制御する方法については、後述の <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

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

--atomic

アトミックなトランザクションを使用してローカルの参照を更新します。すべての参照が更新されるか、エラー発生時にはどの参照も更新されません。

--depth=<depth>

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

--deepen=<depth>

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

--shallow-since=<date>

シャローリポジトリの履歴を深くしたり短くしたりして、<date> 以降の到達可能なすべてのコミットを含めます。

--shallow-exclude=<ref>

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

--unshallow

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

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

--update-shallow

デフォルトでは、シャローリポジトリからフェッチする際、`git fetch` は .git/shallow の更新が必要な参照を拒否します。このオプションは .git/shallow を更新し、そのような参照を受け入れます。

--negotiation-tip=<commit|glob>

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

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

このオプションの引数は、参照名に対するグロブ、参照、またはコミットの（短縮された可能性のある）SHA-1である場合があります。グロブを指定することは、このオプションを複数回、一致する各参照名に対して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] の「出力」セクションを参照してください。

これは `--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を変更して、すべての参照を `refs/prefetch/` ネームスペースに配置します。git-maintenance[1] の `prefetch` タスクを参照してください。

-p
--prune

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

詳細については、以下の「プルーニング」セクションを参照してください。

-P
--prune-tags

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

詳細については、以下の「プルーニング」セクションを参照してください。

-n
--no-tags

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

--refetch

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

--refmap=<refspec>

コマンドラインで指定された参照をフェッチする場合、リモートリポジトリの `remote.*.fetch` 設定変数の値の代わりに、指定された refspec（複数回指定可能）を使用して参照をリモート追跡ブランチにマップします。`--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_ と通信するための内部的な使用のみを目的としており、独自のポーセリンを実装している場合を除き、これを使用するべきではありません。

--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>` が指定された場合、それらはすべてコマンドラインでリストされた順序で相手側に送信されます。コマンドラインから `--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 オプションは、早送り更新を試みる前に強制更新をチェックします。git-config[1] を参照してください。

-4
--ipv4

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

-6
--ipv6

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

<repository>

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

<group>

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

<refspec>

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

<refspec> パラメータの形式は、オプションのプラス記号 `+`、その後にソース <src>、コロン `:`、その後に宛先 <dst> が続きます。<dst> が空の場合、コロンは省略できます。<src> は通常、参照、または参照のセットに一致させるために使用される単一の `*` を含むグロブパターンですが、完全に記述された16進オブジェクト名であることもあります。

A <refspec> には、単純なパターンマッチを示すために <src> 内に `*` を含めることができます。このような refspec は、パターンに一致する任意の参照をマッチさせるグロブのように機能します。パターン <refspec> には、<src> と <dst> の両方に1つだけ `*` がなければなりません。ソースから一致した内容で `*` を置き換えることにより、参照を宛先にマップします。

refspec の前に `^` が付いている場合、それは負の refspec として解釈されます。そのような refspec は、フェッチする参照や更新するローカル参照を指定するのではなく、除外する参照を指定します。参照は、少なくとも1つの正の refspec に一致し、かつ負の refspec のいずれにも一致しない場合に一致すると見なされます。負の refspec は、特定の参照を含まないようにパターン refspec のスコープを制限するのに役立ちます。負の refspec 自体がパターン refspec であることもあります。ただし、それらは <src> のみを含み、<dst> は指定しません。完全に記述された16進オブジェクト名もサポートされていません。

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

<src> に一致するリモート参照がフェッチされ、<dst> が空でない文字列の場合、それに一致するローカル参照を更新する試みが行われます。

`--force` なしでその更新が許可されるかどうかは、フェッチ先の参照名前空間、フェッチされるオブジェクトのタイプ、および更新がファストフォワードと見なされるかどうかに依存します。一般に、プッシュ時と同じ規則がフェッチにも適用されます。それらが何かについては、git-push[1] の `<refspec>...` セクションを参照してください。_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/*` 名前空間が非コミットオブジェクトを受け入れることはないということです。

注
 フェッチしたいリモートブランチが定期的に巻き戻し（rewound）およびリベースされることが知られている場合、その新しい先端は以前の先端（前回フェッチしたときにリモート追跡ブランチに保存されたもの）の子孫ではないと予想されます。そのようなブランチには非ファストフォワード更新が必要であることを示すために `+` 記号を使用したいでしょう。この動作を持つリポジトリでブランチが利用可能になることを判断または宣言する方法はありません。プルするユーザーは、これがブランチの期待される使用パターンであることを単に知っている必要があります。
--stdin

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

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` は、ssh URLと誤解されないように、絶対パスまたは `./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がネイティブでサポートしているローカルリポジトリでは、以下の構文を使用できます

  • /path/to/repo.git/

  • file:///path/to/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" や "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> 引数としてURLの代わりに、以下のいずれかの名前を使用できます。

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

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

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

これらすべては、それぞれにGitがデフォルトで使用するrefspecが含まれているため、コマンドラインから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> はオプションです。

操作に応じて、コマンドラインでrefspecを指定しない場合、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）、コマンドラインで指定された<refspec>は、何をフェッチするかを決定します（例として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 を設定します。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 オプションを指定すると、リモートに存在しないローカルタグをプルーニングし、異なるタグを強制的に更新できます。タグのプルーニングは、設定で 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 またはその設定バージョンなしで提供されたときにエラーにならない理由は、設定されたバージョンの柔軟性のためであり、コマンドラインフラグが行うことと設定バージョンが行うことの間に1対1のマッピングを維持するためです。

例えば、~/.gitconfig で fetch.pruneTags=true を設定し、git fetch --prune が実行されるたびにタグがプルーニングされるようにするのは合理的です。これにより、--prune なしで git fetch を呼び出すたびにエラーになるのを避けることができます。

--prune-tags を使用したタグのプルーニングは、名前付きリモートではなくURLをフェッチする場合にも機能します。これらすべては、オリジンに見つからないタグをプルーニングします。

$ 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>です）。

元

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

先

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

理由

人間が読みやすい説明です。正常にフェッチされたrefの場合、説明は不要です。失敗したrefの場合、失敗の理由が記述されます。

例

  • リモート追跡ブランチを更新する

    $ git fetch origin

    上記のコマンドは、リモートのrefs/heads/名前空間からすべてのブランチをコピーし、ローカルのrefs/remotes/origin/名前空間に保存します。ただし、remote.<repository>.fetchオプションを使用して非デフォルトのrefspecが指定されている場合は除きます。

  • 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は持っていないと偽って主張するため、被害者はYをXに対するデルタとして送信します。このデルタは、XのうちYに類似する領域を攻撃者に明らかにします。

設定

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

fetch.prune

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

fetch.pruneTags

trueの場合、フェッチは、すでに設定されていない場合、プルーニング時にrefs/tags/*:refs/tags/* refspecが提供されたかのように自動的に動作します。これにより、このオプションとfetch.pruneの両方を設定して、上流のrefへの1対1のマッピングを維持できます。remote.<name>.pruneTags および git-fetch[1] の「プルーニング」セクションも参照してください。

fetch.all

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

fetch.output

refの更新ステータスがどのように表示されるかを制御します。有効な値はfullとcompactです。デフォルト値はfullです。詳細については、git-fetch[1] の「出力」セクションを参照してください。

fetch.negotiationAlgorithm

サーバーから送信されるパックファイルの内容をネゴシエートする際に、ローカルリポジトリ内のコミットに関する情報がどのように送信されるかを制御します。「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設定で上書きできます。

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を使用して増分的にフェッチする場合、この設定値はダウンロードされたバンドルの最大creationToken値を格納します。この値は、広告されたcreationTokenがこの値よりも厳密に大きくない場合に、将来のバンドルダウンロードを防ぐために使用されます。

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

バグ

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

関連項目

git-pull[1]

GIT

git[1] スイートの一部

scroll-to-top