git-fetch

コマンド名

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

概要

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

説明

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

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

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

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

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

オプション

--all

すべてのリモートをフェッチします。

-a
--append

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

--depth=<depth>

各リモートブランチ履歴の末端からのコミットの指定された数にフェッチを制限します。--depth=<depth>オプションを指定してgitcloneによって作成された浅いリポジトリにフェッチする場合（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は受信するパックファイルのサイズを縮小するために、すべてのローカル参照から到達可能なコミットをサーバーにレポートして、共通のコミットを見つけます。指定した場合、Gitは指定されたヒントから到達可能なコミットのみをレポートします。これはフェッチされているアップストリーム参照と共通のコミットがある可能性が高いローカル参照がユーザーにわかっている場合、フェッチを高速化するのに役立ちます。

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

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

git-config[1]に記載されているfetch.negotiationAlgorithm構成変数も参照してください。

--dry-run

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

--[no-]write-fetch-head

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

-f
--force

「git fetch」を<src>:<dst>とともに使用すると、以下の<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 を上書きします。

-p
--prune

フェッチする前にリモートに存在しなくなったリモート追跡参照を削除します。タグはデフォルトのタグの自動フォローまたは「–tags」オプションのためにのみフェッチされた場合、プルーニングの対象にはなりません。ただし、明示的な参照スペックが原因でタグがフェッチされた場合（コマンドラインまたはリモート構成のいずれかで、例えばリモートが「–mirror」オプションで複製された場合）、タグもプルーニングの対象になります。--prune-tags の指定はタグ参照スペックを提供するための省略形です。

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

-P
-prune-tags

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

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

-n
--no-tags

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

--refmap=<refspec>

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

-t
--tags

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

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

このオプションは入力されたサブモジュールの新しいコミットもフェッチするかどうか、およびどのような条件でフェッチするかをコントロールします。これはブールオプションとして使用でき、「no」に設定すると再帰を完全に無効にしたり、「yes」に設定するとすべての入力済みサブモジュールに無条件に再帰します。これはこのオプションを値なしで使用した場合のデフォルトとなっています。スーパープロジェクトがローカルサブモジュールのクローンにまだ存在しないコミットへのサブモジュールの参照を更新するコミットを取得する場合にのみ、オンデマンドを使用して、入力されたサブモジュールに再帰します。デフォルトでは fetch.recurseSubmodules が設定されていない限り、オンデマンドが使用されます（git-config[1]を参照）。

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

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

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

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

-u
--update-head-ok

デフォルトでは「gitfetch」は現在のブランチに対応するヘッドの更新を拒否します。このフラグはチェックを無効にします。これは純粋に「gitpull」が「gitfetch」と通信するための内部使用のためであり、独自のポーセレインを実装していない限り、それを使用することは想定されていません。

--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> が指定されている場合、それらはすべてコマンドラインにリストされている順序で反対側に送信されます。

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

(See git-config[1]). 構成ファイル内の「remotes.<group>」の値としてリポジトリーのリストを参照する名前です （git-config[1]を参照）。

<refspec>

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

<refspec>パラメーターの形式はオプションのプラス+、ソース<src>、コロン:、宛先ref <dst>の順となっています。<dst>が空の場合、コロンは省略できます。<src>は通常、参照ですが、完全にスペルされた16進オブジェクト名にすることもできます。

<refspec>の<src>には単純なパターン一致を示す*が含まれている場合があります。このような参照スペックは同じプレフィックスを持つ任意の参照に一致するグロブのように機能します。パターン<refspec>には<src>と<dst>の両方に* が含まれている必要があります。 *をソースから一致したコンテンツに置き換えることにより、参照を宛先にマップします。

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

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

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

その更新が--forceなしで許可されるかどうかはフェッチ先の参照名空間、フェッチされるオブジェクトのタイプ、および更新がファーストフォワードと見なされるかどうかによって異なります。 一般的にプッシュする場合と同じルールがフェッチに適用されます。それらが何であるかについてはgit-push[1]の&lt;refspec>... セクションを参照してください。「gitfetch」に固有のこれらのルールの例外を以下に示します。

Gitバージョン2.20までおよびgit-push[1]でプッシュする場合とは異なり、 refs/tags/* の更新は参照スペック（または--force）に+がなくても受け入れられます。フェッチする時、リモートからのすべてのタグ更新を強制フェッチと無差別に考慮しています。Gitバージョン2.20以降、refs/tags/* を更新するためのフェッチはプッシュする場合と同じように機能します。つまり 参照スペック（または--force）に+がないと、更新は拒否されます。

git-push[1]でプッシュする場合とは異なり、refs/{tags,heads}/* 以外の更新はスワッピングするかどうかに関係なく、参照スペック（または--force）に+なしで受け入れられます。ブロブのツリーオブジェクト、または祖先としての前のコミットがない別のコミットなどです。

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

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

注記 定期的にリベースされるため、新しいヒントは以前のヒントの子孫ではないことが予想されます（最後にフェッチしたときにリモート追跡ブランチに保存されているように）。+記号を使用して、そのようなブランチに非ファーストフォワードの更新が必要であることを示します。この動作でブランチがリポジトリで利用可能になることを決定または宣言する方法はありません。プルするユーザーはこれがブランチの予想される使用パターンであることを知っている必要があります。

--stdin

引数として提供されているものに加えて、「stdin」から参照スペックを1ラインに1つずつ読み取ります。「tag <name>」フォーマットはサポートされていません。

GITのURL

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

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

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

次のシンタックスを使用できます。

  • ssh://[user@]host.xz[:port]/path/to/repo.git/
  • git://host.xz[:port]/path/to/repo.git/
  • http[s]://host.xz[:port]/path/to/repo.git/
  • ftp[s]://host.xz[:port]/path/to/repo.git/

代替のscpのようなシンタックスもsshプロトコルで使用できます。

  • [user@]host.xz:path/to/repo.git/

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

sshおよびgitプロトコルはさらに「〜username」拡張をサポートします。

  • ssh://[user@]host.xz[:port]/~[user]/path/to/repo.git/
  • git://host.xz[:port]/~[user]/path/to/repo.git/
  • [user@]host.xz:/~[user]/path/to/repo.git/

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はリポジトリへのアクセスに使用されます。コマンドラインで参照スペックを指定しない場合、このリモートの参照スペックがデフォルトで使用されます。構成ファイルのエントリは次のようになります。

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

<pushurl>はプッシュにのみ使用されます。これはオプションであり、デフォルトは<url>です。

$GIT_DIR/remotes 内の名付けられたファイル

$GIT_DIR/remotesでファイルの名前を指定することを選択できます。このファイルのURLはリポジトリへのアクセスに使用されます。コマンドラインで参照スペックを指定しない場合、このファイルの参照スペックがデフォルトとして使用されます。このファイルのフォーマットは次のとおりです。

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

Push: ラインは「git push」によって使用され、Pull:ラインは「gitpull」および「gitfetch」によって使用されます。複数のPush:とPull: ラインは追加のブランチマッピング用に指定できます。

$GIT_DIR/branches内の名付けられたファイル

$GIT_DIR/branchesでファイルの名前を指定することを選択できます。このファイルのURLはリポジトリへのアクセスに使用されます。このファイルのフォーマットは次のとおりです。

<url>#<head>

<url> が必要です。 #<head> はオプションとなっています。

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

gitfetchは次のように使用します。

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値は参照スペックとして使用されます。これらの値はフェッチする参照と更新するローカル参照を指定します。上記の例ではoriginに存在するすべてのブランチ（つまりrefs/heads/*である値の左側に一致するすべての参照）をフェッチし、refs/remotes/origin/* ヒエラルキー内の対応するリモートトラッキングブランチを更新します。
  • 例えばgit fetch origin masterのように、コマンドラインでフェッチする明示的なブランチやタグを使用してgit fetch を実行する時、コマンドラインで指定された<refspec>は何をフェッチするかを決定します（例えば、例のmasterはmaster:の省略形です。これは「masterブランチをフェッチしますが、私は コマンドラインからどのリモートトラッキングブランチを更新するかを明示的に指定しません」）。サンプルコマンドはマスターブランチのみをフェッチします。remote.<repository>.fetch値は更新されるリモート追跡ブランチがある場合はそれを決定します。このように使用するとremote.<repository>.fetch の値は何をフェッチするかを決定するのに効果がありません（つまり、コマンドラインに参照スペックがリストされている場合、値は参照スペックとして使用されません）。これらはマッピングとして機能することにより、フェッチされた参照がどこに格納されるかを決定するためにのみ使用されます。

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

プルーニング

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

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

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

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

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

参照を実行することを忘れずに通常のワークフローの一部として参照をプルーニングするにはfetch.pruneをグローバルに設定するか、構成でリモートあたりでremote.<name>.prune を設定します。git-config[1]を参照してください。

ここで物事がトリッキーでより具体的になります。プルーニング機能は実際にはブランチを気にしませんが、代わりにリモートの参照スペックの関数としてローカルの「<→remote-references」をプルーニングします（上記の<refspec> およびCONFIGURED REMOTE-TRACKING BRANCHESを参照してください）。

したがって、リモートの参照スペックにrefs/tags/*:refs/tags/*,、または手動で実行するgit fetch --prune <name> "refs/tags/*:refs/tags/*"が含まれている場合、削除されるのは古いリモートトラッキングブランチではなく、リモートに存在しないローカルタグです。

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

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

リモート上のブランチとタグの両方を最新の状態に保つことは一般的な使用例であるため、リモートに存在しないローカルタグをプルーニングするために--prune-tagsオプションを--pruneと一緒に提供できます。異なるタグを強制更新します。タグのプルーニングは構成の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のマッピングを維持するためです。

例えば、~/.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/*'

出力

「gitfetch」の出力は使用するトランスポート方法によって異なります。このセクションではGitプロトコル（ローカルまたはssh経由）およびSmartHTTPプロトコルを介してフェッチする場合の出力についてです。

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

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

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

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

flag

参照のステータスを示す1文字です。

(space)

正常にフェッチされたファーストフォワード

+

強制更新の成功

-

正常にプルーニングされた参照

t

タグの更新の成功

*

正常にフェッチされた新しい参照

!

拒否されたまたは更新に失敗した参照

=

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

summary

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

from

フェッチ元のリモート参照の名前からそのrefs/<type>/プレフィックスを差し引いたものです。削除の場合、リモート参照の名前は「（none）」となります。

to

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

reason

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

例

  • リモート追跡ブランチを更新します。 
    $ git fetch origin

    上記のコマンドは「remote refs/heads/ namespace」からのすべてのブランチをコピーし、branch.<name>.fetchオプションはデフォルトではない参照スペックを特定するために使用しない限り、「local refs/remotes/origin/ namespace」 にそれらをストアします。

  • 参照スペックを明示的に使用します。 
    $ 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がある場合、転送を最適化するために使用できます。攻撃者はオブジェクトIDXを選択して盗み、参照をXに送信しますが被害者はすでにXのコンテンツを持っているため、Xのコンテンツを送信する必要はありません。これで被害者は攻撃者がXを持っていると信じ、Xのコンテンツを後で攻撃者に送り返します（この攻撃はクライアントがアクセスできる名前スペースにXへの参照を作成し、それをフェッチすることで、クライアントがサーバー上で実行するのが最も簡単です。サーバーがクライアント上で実行する最も可能性の高い方法は「 Xをパブリックブランチにマージし、ユーザーがこのブランチで追加のワークを行い、マージに気付かずにサーバーにプッシュバックすることを期待します）。
  2. ＃1と同様に攻撃者は盗むオブジェクトIDXを選択します。被害者は攻撃者がすでに持っているオブジェクトYを送信し、攻撃者はYではなくXを持っていると誤って主張するため、被害者はYをXに対するデルタとして送信します。デルタは攻撃者にYに類似したXの領域を明らかにします。

バグ

「–recurse-submodules」を使用すると、現時点ではすでにチェックアウトされているサブモジュールでのみ新しいコミットをフェッチできます。例えば、アップストリームはスーパープロジェクトのフェッチされたばかりのコミットに新しいサブモジュールを追加しました。サブモジュール自体はフェッチできないため、後で再度フェッチを実行せずにそのサブモジュールをチェックアウトすることはできません。これは将来のGitバージョンで修正される予定です。

参照

git-pull[1]

GIT

git[1]パッケージソフトの一部

git公式ドキュメント

fetch