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

各リモートブランチ履歴の先端から指定されたコミット数にフェッチを制限します。--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は指定されたコミットのいずれかから到達可能なコミットを報告します。

このオプションの引数は、参照名のglob、参照、またはコミットの（短縮された可能性のある）SHA-1である場合があります。globを指定することは、一致する参照名ごとにこのオプションを複数回指定することと同じです。

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を変更して、すべてのrefを refs/prefetch/ 名前空間に配置します。git-maintenance[1] の prefetch タスクを参照してください。

-p
--prune

フェッチする前に、リモートに存在しなくなったリモートトラッキング参照を削除します。タグは、デフォルトのタグ自動追従または --tags オプションによってのみフェッチされる場合、プルーニングの対象外です。ただし、明示的なリファースペック（コマンドラインまたはリモート設定、例えば --mirror オプションでリモートがクローンされた場合）によってタグがフェッチされた場合は、プルーニングの対象となります。--prune-tags を指定することは、タグのリファースペックを指定するショートカットです。

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

-P
--prune-tags

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

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

-n
--no-tags

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

--refetch

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

--refmap=<refspec>

コマンドラインにリストされている参照をフェッチする場合、リモートリポジトリの remote.*.fetch 設定変数の値の代わりに、指定された参照スペック（複数回指定可能）を使用して、参照をリモートトラッキングブランチにマッピングします。--refmap オプションに空の <refspec> を指定すると、Git は設定された参照スペックを無視し、コマンドライン引数として提供された参照スペックに完全に依存します。詳細については、「設定されたリモートトラッキングブランチ」セクションを参照してください。

-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>

「Fetching submodule 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> が指定された場合、コマンドラインにリストされた順序ですべて相手側に送信されます。コマンドラインから --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 URLS セクションを参照）またはリモートの名前（以下の REMOTES セクションを参照）のいずれかです。

<group>

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

<refspec>

どの参照をフェッチし、どのローカル参照を更新するかを指定します。コマンドラインに <refspec> が現れない場合、フェッチする参照は代わりに remote.<repository>.fetch 変数から読み込まれます（以下の CONFIGURED REMOTE-TRACKING BRANCHES を参照）。

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

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

参照スペックに ^ が前置されている場合、それは負の参照スペックとして解釈されます。どの参照をフェッチするか、どのローカル参照を更新するかを指定する代わりに、そのような参照スペックは除外する参照を指定します。参照は、少なくとも1つの正の参照スペックに一致し、かつ負の参照スペックに一致しない場合に一致すると見なされます。負の参照スペックは、特定の参照を含まないようにパターン参照スペックの範囲を制限するのに役立ちます。負の参照スペック自体がパターン参照スペックである場合もあります。ただし、それらは <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/* 名前空間が非コミットオブジェクトを受け入れることはないということです。

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

引数として提供されたものに加えて、stdin から1行に1つずつ参照スペックを読み込みます。「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>

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つの構文はほとんど同じですが、クローン作成時を除き、前者は --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 がデフォルトで使用するリファレンスが含まれているためです。

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

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

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

<pushurl> はプッシュにのみ使用されます。これはオプションで、デフォルトは <URL> です。リモートへのプッシュは、定義されているすべてのプッシュURL、またはプッシュURLが定義されていない場合は定義されているすべての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 は次のいずれかの参照スペックを使用します。<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 として使用されます。これらは、どの参照をフェッチし、どのローカル参照を更新するかを指定します。上記の例では、origin に存在するすべてのブランチ（つまり、値の左側、refs/heads/* に一致する任意の参照）をフェッチし、対応するリモートトラッキングブランチを refs/remotes/origin/* 階層で更新します。

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

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> と CONFIGURED REMOTE-TRACKING BRANCHES を参照）の関数としてローカル ←→ リモート参照をプルーニングします。

したがって、リモートの参照スペックに例えば 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 オプションは、リモートの参照スペックに 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マッピングを維持するためです。

例えば、fetch.pruneTags=true を ~/.gitconfig に設定して、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 経由）およびスマート HTTP プロトコルでフェッチする場合の出力について説明します。

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

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

--porcelain を使用する場合、出力形式は機械が解析できるように意図されています。そのため、人間が読める出力形式とは対照的に、標準エラー出力ではなく標準出力に出力されます。各行の形式は次のとおりです。

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

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

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

flag

参照のステータスを示す単一文字

(スペース)

正常にフェッチされた早送り更新の場合;

+

強制更新が成功した場合;

-

正常にプルーニングされた参照の場合;

t

タグの更新が成功した場合;

*

正常にフェッチされた新しい参照の場合;

!

拒否されたか、更新に失敗した参照の場合; および

=

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

summary

正常にフェッチされた参照の場合、要約は、git log の引数として使用するのに適した形式で、参照の古い値と新しい値を表示します（ほとんどの場合 <old>..<new>、強制的な早送りでない更新の場合は <old>...<new>）。

from

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

to

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

reason

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

例

  • リモートトラッキングブランチを更新する

    $ git fetch origin

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

  • 参照スペックを明示的に使用する

    $ 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への参照を送信しますが、被害者はすでにそれを持っているのでXの内容を送信する必要はありません。これで、被害者は攻撃者がXを持っていると信じ、後でXの内容を攻撃者に送り返します。（この攻撃は、クライアントがアクセスできる名前空間にXへの参照を作成し、それをフェッチすることで、クライアントがサーバーに対して実行するのが最も簡単です。サーバーがクライアントに対して実行する最も可能性のある方法は、Xを公開ブランチに「マージ」し、ユーザーがこのブランチで追加作業を行い、マージに気付かずにサーバーにプッシュバックすることを期待することです。）

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

設定

このセクションのこの行より下のすべての内容は、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] の PRUNING セクションも参照してください。

fetch.pruneTags

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

fetch.all

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

fetch.output

参照更新ステータスの表示方法を制御します。有効な値は 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

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 オプションの動作に似ています。git clone --bundle-uri は、提供されたバンドル 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