fetch

NAME名

git-fetch - Download objects and refs from another repositorygit-fetch - 他のリポジトリからオブジェクトと参照をダウンロードする

SYNOPSIS概要

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

DESCRIPTION説明

Fetch branches and/or tags (collectively, "refs") from one or more other repositories, along with the objects necessary to complete their histories. Remote-tracking branches are updated (see the description of <refspec> below for ways to control this behavior).履歴を完成させるのに必要なオブジェクトと共に、1つ以上の他のリポジトリからブランチやタグ（まとめて "refs"）を取得します。リモートトラッキングブランチが更新されました（この振る舞いを制御する方法については、以下の<refspec>の説明を参照してください）。

By default, any tag that points into the histories being fetched is also fetched; the effect is to fetch tags that point at branches that you are interested in. This default behavior can be changed by using the --tags or --no-tags options or by configuring remote.<name>.tagOpt. By using a refspec that fetches tags explicitly, you can fetch tags that do not point into branches you are interested in as well.デフォルトでは、取得中の履歴を指すタグも取得されます。このデフォルトの動作は、--tagsオプションまたは--no-tagsオプションを使用するか、remote。<name> .tagOptを設定することで変更できます。タグを明示的に取得するrefspecを使用することで、関心のある分岐を指していないタグも取得できます。

git fetch can fetch from either a single named repository or URL, or from several repositories at once if <group> is given and there is a remotes.<group> entry in the configuration file. (See git-config[1]).git fetchは単一の名前付きリポジトリまたはURLから、あるいは<group>が与えられていて設定ファイルにremotes。<group>エントリがある場合は一度に複数のリポジトリから取得できます。（git-config [1]を見てください）。

When no remote is specified, by default the origin remote will be used, unless there’s an upstream branch configured for the current branch.リモートが指定されていoriginない場合、現在のブランチ用に設定されているアップストリームブランチがない限り、デフォルトでリモートが使用されます。

The names of refs that are fetched, together with the object names they point at, are written to .git/FETCH_HEAD. This information may be used by scripts or other git commands, such as git-pull[1].取得された参照の名前は、それらが指し示すオブジェクト名とともに書き込まれ.git/FETCH_HEADます。この情報は、スクリプトやgit-pull [1]などの他のgitコマンドで使用される可能性があります。

OPTIONSオプション

--all - すべて

Fetch all remotes.すべてのリモートを取得します。

-a
--append - 追加

Append ref names and object names of fetched refs to the existing contents of .git/FETCH_HEAD. Without this option old data in .git/FETCH_HEAD will be overwritten.の参照名と取得した参照のオブジェクト名をの既存の内容に追加します.git/FETCH_HEAD。このオプションがなければ、古いデータは.git/FETCH_HEAD上書きされます。

--depth=<depth> --depth = <深さ>

Limit fetching to the specified number of commits from the tip of each remote branch history. If fetching to a shallow repository created by git clone with --depth=<depth> option (see git-clone[1]), deepen or shorten the history to the specified number of commits. Tags for the deepened commits are not fetched.各リモートブランチ履歴の先端からの指定したコミット数までのフェッチを制限します。with option（git-clone [1]を参照）で作成された浅いリポジトリにフェッチする場合は、指定されたコミット数まで履歴を深くするか短くします。深くなったコミットのタグは取得されません。git clone--depth=<depth>

--deepen=<depth> --deepen = <深さ>

Similar to --depth, except it specifies the number of commits from the current shallow boundary instead of from the tip of each remote branch history.--depthと似ていますが、各リモートブランチ履歴の先端からではなく、現在の浅い境界からのコミット数を指定する点が異なります。

--shallow-since=<date> --shallow-since = <日付>

Deepen or shorten the history of a shallow repository to include all reachable commits after <date>.<date>の後に到達可能なすべてのコミットを含めるように、浅いリポジトリの履歴を深くするか短くします。

--shallow-exclude=<revision> --shallow-exclude = <リビジョン>

Deepen or shorten the history of a shallow repository to exclude commits reachable from a specified remote branch or tag. This option can be specified multiple times.指定されたリモートブランチまたはタグから到達可能なコミットを除外するために、浅いリポジトリの履歴を深くするか短くします。このオプションは複数回指定できます。

--unshallow - アンシャロー

If the source repository is complete, convert a shallow repository to a complete one, removing all the limitations imposed by shallow repositories.ソースリポジトリが完成したら、浅いリポジトリを完全なリポジトリに変換し、浅いリポジトリによる制限をすべて取り除きます。

If the source repository is shallow, fetch as much as possible so that the current repository has the same history as the source repository.ソースレポジトリが浅い場合は、現在のレポジトリがソースレポジトリと同じ履歴を持つように、できるだけ取得します。

--update-shallow

By default when fetching from a shallow repository, git fetch refuses refs that require updating .git/shallow. This option updates .git/shallow and accept such refs.浅いリポジトリから取得するときのデフォルトでは、git fetch.git / shallowの更新が必要な参照を拒否します。このオプションは.git / shallowを更新し、そのような参照を受け入れます。

--negotiation-tip=<commit|glob> --negotiation-tip = <commit | glob>

By default, Git will report, to the server, commits reachable from all local refs to find common commits in an attempt to reduce the size of the to-be-received packfile. If specified, Git will only report commits reachable from the given tips. This is useful to speed up fetches when the user knows which local ref is likely to have commits in common with the upstream ref being fetched.デフォルトでは、Gitは、受信するpackfileのサイズを減らすために、すべてのローカル参照から到達可能なコミットを報告して、共通のコミットを見つけます。指定された場合、Gitは与えられた助言から到達可能なコミットのみを報告します。これは、どのローカル参照が取り出される上流参照と共通してコミットされている可能性が高いかをユーザーが知っているときに取り出しを高速化するのに役立ちます。

This option may be specified more than once; if so, Git will report commits reachable from any of the given commits.このオプションは複数回指定できます。もしそうなら、Gitは与えられたコミットのどれからでも到達可能なコミットを報告します。

The argument to this option may be a glob on ref names, a ref, or the (possibly abbreviated) SHA-1 of a commit. Specifying a glob is equivalent to specifying this option multiple times, one for each matching ref name.このオプションへの引数は、参照名に対するグロブ、参照、またはコミットの（おそらく短縮された）SHA-1です。グロブを指定することは、このオプションを複数回指定することと同じです（一致する参照名ごとに1回）。

See also the fetch.negotiationAlgorithm configuration variable documented in git-config[1].git-config [1]にfetch.negotiationAlgorithm記載されている設定変数も参照してください。

--dry-run

Show what would be done, without making any changes.何も変更せずに、何が行われるのかを示します。

-f
--force - 力

When git fetch is used with <src>:<dst> refspec it may refuse to update the local branch as discussed in the <refspec> part below. This option overrides that check.場合Gitは、フェッチで使用され<src>:<dst>、それはで説明したようにローカルブランチを更新することを拒否してもよいrefspec <refspec>以下部。このオプションはそのチェックを無効にします。

-k
--keep - キープ

Keep downloaded pack.ダウンロードしたパックを保管してください。

--multiple - 複数

Allow several <repository> and <group> arguments to be specified. No <refspec>s may be specified.複数の<repository>および<group>引数を指定することを許可します。<reffspec>は指定できません。

-p
--prune - プルーン

Before fetching, remove any remote-tracking references that no longer exist on the remote. Tags are not subject to pruning if they are fetched only because of the default tag auto-following or due to a --tags option. However, if tags are fetched due to an explicit refspec (either on the command line or in the remote configuration, for example if the remote was cloned with the --mirror option), then they are also subject to pruning. Supplying --prune-tags is a shorthand for providing the tag refspec.取得する前に、リモートに存在しなくなったリモートトラッキング参照をすべて削除します。タグがデフォルトの自動追従または--tagsオプションのためだけに取得された場合、タグは整理の対象になりません。ただし、明示的なrefspecのためにタグがフェッチされた場合（たとえば、リモートが--mirrorオプションで複製された場合など）、タグは整理の対象にもなります。供給--prune-tagsはタグrefspecを提供するための速記です。

See the PRUNING section below for more details.詳細については、下記の「削除」セクションを参照してください。

-P
--prune-tags

Before fetching, remove any local tags that no longer exist on the remote if --prune is enabled. This option should be used more carefully, unlike --prune it will remove any local references (local tags) that have been created. This option is a shorthand for providing the explicit tag refspec along with --prune, see the discussion about that in its documentation.フェッチする前に、--prune有効になっていればリモートに存在しなくなったローカルタグを削除します。このオプションは、--prune作成されたローカル参照（ローカルタグ）を削除するのとは異なり、より慎重に使用する必要があります。このオプションは明示的なタグrefspecを一緒に提供するための省略形です--prune。それに関する説明はそのドキュメントで見られます。

See the PRUNING section below for more details.詳細については、下記の「削除」セクションを参照してください。

-n
--no-tags

By default, tags that point at objects that are downloaded from the remote repository are fetched and stored locally. This option disables this automatic tag following. The default behavior for a remote may be specified with the remote.<name>.tagOpt setting. See git-config[1].デフォルトでは、リモートリポジトリからダウンロードされたオブジェクトを指すタグが取得され、ローカルに保存されます。このオプションは、この自動タグフォローを無効にします。リモートのデフォルトの動作は、remote。<name> .tagOpt設定で指定できます。参照のgit-config設定を[1]。

--refmap=<refspec> --refmap = <参照仕様>

When fetching refs listed on the command line, use the specified refspec (can be given more than once) to map the refs to remote-tracking branches, instead of the values of remote.*.fetch configuration variables for the remote repository. See section on "Configured Remote-tracking Branches" for details.コマンドラインにリストされている参照を取得するときremote.*.fetchは、リモートリポジトリの設定変数の値の代わりに、指定されたrefspec（複数回指定可能）を使用して参照をリモート追跡ブランチにマッピングします。詳細は "設定されたリモートトラッキングブランチ"のセクションを見てください。

-t
--tags - タグ

Fetch all tags from the remote (i.e., fetch remote tags refs/tags/* into local tags with the same name), in addition to whatever else would otherwise be fetched. Using this option alone does not subject tags to pruning, even if --prune is used (though tags may be pruned anyway if they are also the destination of an explicit refspec; see --prune).refs/tags/*他の方法で取得されるもの以外に、すべてのタグをリモートから取得します（つまり、リモートタグを同じ名前のローカルタグに取得します）。このオプションを単独で使用しても、--pruneが使用されていてもタグの整理は行われません（ただし、タグが明示的なrefspecの宛先でもある場合は、タグは整理されることがあります--prune）。

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

This option controls if and under what conditions new commits of populated submodules should be fetched too. It can be used as a boolean option to completely disable recursion when set to no or to unconditionally recurse into all populated submodules when set to yes, which is the default when this option is used without any value. Use on-demand to only recurse into a populated submodule when the superproject retrieves a commit that updates the submodule’s reference to a commit that isn’t already in the local submodule clone.このオプションは、投入されたサブモジュールの新しいコミットも取得するかどうか、またどのような条件下で取得するかを制御します。noに設定すると再帰を完全に無効にし、yesに設定するとすべての入力されたサブモジュールに無条件に再帰するためのブール値オプションとして使用できます。これは、このオプションを値なしで使用する場合のデフォルトです。スーパープロジェクトが、サブモジュールの参照をローカルサブモジュールクローンにまだ存在しないコミットに更新するコミットを取得したときにのみ、投入されたサブモジュールに再帰するためにオンデマンドを使用します。

-j
--jobs=<n> --jobs = <n>

Number of parallel children to be used for fetching submodules. Each will fetch from different submodules, such that fetching many submodules will be faster. By default submodules will be fetched one at a time.サブモジュールの取得に使用される並列の子の数。それぞれが異なるサブモジュールからフェッチするため、多数のサブモジュールをフェッチするのが速くなります。デフォルトでは、サブモジュールは一度に1つずつフェッチされます。

--no-recurse-submodules

Disable recursive fetching of submodules (this has the same effect as using the --recurse-submodules=no option).サブモジュールの再帰的フェッチを無効にします（これは--recurse-submodules=noオプションを使用するのと同じ効果があります）。

--submodule-prefix=<path> --submodule-prefix = <パス>

Prepend <path> to paths printed in informative messages such as "Fetching submodule foo". This option is used internally when recursing over submodules."Fetching submodule foo"のような情報メッセージに表示されたパスの前に<path>を付けます。このオプションは、サブモジュールを再帰的に処理するときに内部的に使用されます。

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

This option is used internally to temporarily provide a non-negative default value for the --recurse-submodules option. All other methods of configuring fetch’s submodule recursion (such as settings in gitmodules[5] and git-config[1]) override this option, as does specifying --[no-]recurse-submodules directly.このオプションは、--recurse-submodulesオプションに負でないデフォルト値を一時的に提供するために内部的に使用されます。- [no-] recurse-submodulesを直接指定するのと同様に、フェッチのサブモジュール再帰を設定する他のすべての方法（gitmodules [5]やgit-config [1]の設定など）はこのオプションをオーバーライドします。

-u
--update-head-ok

By default git fetch refuses to update the head which corresponds to the current branch. This flag disables the check. This is purely for the internal use for git pull to communicate with git fetch, and unless you are implementing your own Porcelain you are not supposed to use it.デフォルトではgit fetchは現在のブランチに対応するheadの更新を拒否します。このフラグはチェックを無効にします。これは純粋にgit pullがgit fetchと通信するための内部使用のためのものであり、あなたがあなた自身のPorcelainを実装していない限りあなたはそれを使うべきではありません。

--upload-pack <upload-pack>

When given, and the repository to fetch from is handled by git fetch-pack, --exec=<upload-pack> is passed to the command to specify non-default path for the command run on the other end.与えられた、とリポジトリがによって処理されるからフェッチするときにgitのフェッチパック、--exec=<upload-pack>もう一方の端で実行するコマンドにデフォルト以外のパスを指定するには、コマンドに渡されます。

-q
--quiet - 静か

Pass --quiet to git-fetch-pack and silence any other internally used git commands. Progress is not reported to the standard error stream.--quietをgit-fetch-packに渡し、他の内部で使用されているgitコマンドを黙らせます。進行状況は標準エラーストリームに報告されません。

-v
--verbose - 冗談

Be verbose.冗長になります。

--progress - 進捗

Progress status is reported on the standard error stream by default when it is attached to a terminal, unless -q is specified. This flag forces progress status even if the standard error stream is not directed to a terminal.-qが指定されていない限り、進行状況は端末に接続されたときにデフォルトで標準エラー・ストリームに報告されます。このフラグは、標準エラーストリームが端末に向けられていなくても進行状況を強制します。

-o <option> -o <オプション>
--server-option=<option> --server-option = <オプション>

Transmit the given string to the server when communicating using protocol version 2. The given string must not contain a NUL or LF character. When multiple --server-option=<option> are given, they are all sent to the other side in the order listed on the command line.プロトコルバージョン2を使用して通信するときに、指定された文字列をサーバーに送信します。指定された文字列にNULまたはLF文字を含めることはできません。複数指定されて--server-option=<option>いる場合、それらはすべてコマンドラインにリストされた順序で反対側に送信されます。

-4
--ipv4

Use IPv4 addresses only, ignoring IPv6 addresses.IPv6アドレスを無視して、IPv4アドレスのみを使用してください。

-6
--ipv6

Use IPv6 addresses only, ignoring IPv4 addresses.IPv4アドレスを無視して、IPv6アドレスのみを使用してください。

<repository> <リポジトリ>

The "remote" repository that is the source of a fetch or pull operation. This parameter can be either a URL (see the section GIT URLS below) or the name of a remote (see the section REMOTES below).フェッチまたはプル操作のソースである「リモート」リポジトリ。このパラメータは、URL（後述のGIT URLを参照）またはリモートの名前（下記のREMOTESを参照）のいずれかになります。

<group> <グループ>

A name referring to a list of repositories as the value of remotes.<group> in the configuration file. (See git-config[1]).構成ファイル内のremotes。<group>の値としてリポジトリーのリストを参照する名前。（git-config [1]を見てください）。

<refspec> <参照仕様>

Specifies which refs to fetch and which local refs to update. When no <refspec>s appear on the command line, the refs to fetch are read from remote.<repository>.fetch variables instead (see CONFIGURED REMOTE-TRACKING BRANCHES below).どの参照をフェッチし、どのローカル参照を更新するかを指定します。コマンドラインに<refspec>が表示されていない場合は、remote.<repository>.fetch代わりにフェッチする参照が変数から読み込まれます（後述の「設定されたリモートトラッキングブランチ」を参照）。

The format of a <refspec> parameter is an optional plus +, followed by the source <src>, followed by a colon :, followed by the destination ref <dst>. The colon can be omitted when <dst> is empty. <src> is typically a ref, but it can also be a fully spelled hex object name.<reffspec>パラメータの形式は、オプションのプラス+、その後にソース<src>、コロン:、さらに宛先ref <dst>が続きます。<dst>が空の場合、コロンは省略できます。<src>は通常refですが、完全なスペルの16進数のオブジェクト名にすることもできます。

tag <tag> means the same as refs/tags/<tag>:refs/tags/<tag>; it requests fetching everything up to the given tag.tag <tag>と同じ意味refs/tags/<tag>:refs/tags/<tag>です。与えられたタグまでの全てを取得することを要求します。

The remote ref that matches <src> is fetched, and if <dst> is not an empty string, an attempt is made to update the local ref that matches it.<src>に一致するリモート参照が取得され、<dst>が空の文字列でない場合は、それに一致するローカル参照を更新しようとします。

Whether that update is allowed without --force depends on the ref namespace it’s being fetched to, the type of object being fetched, and whether the update is considered to be a fast-forward. Generally, the same rules apply for fetching as when pushing, see the <refspec>... section of git-push[1] for what those are. Exceptions to those rules particular to git fetch are noted below.その更新が許可されているかどうかは、--forceそれがフェッチされているref名前空間、フェッチされているオブジェクトのタイプ、および更新が早送りであると見なされるかどうかに依存します。一般的に、プッシュ時と同じ規則がフェッチに適用されます。それらについて<refspec>...はgit-push [1]のセクションを参照してください。git fetchに特有のこれらの規則の例外は以下に記されています。

Until Git version 2.20, and unlike when pushing with git-push[1], any updates to refs/tags/* would be accepted without + in the refspec (or --force). When fetching, we promiscuously considered all tag updates from a remote to be forced fetches. Since Git version 2.20, fetching to update refs/tags/* works the same way as when pushing. I.e. any updates will be rejected without + in the refspec (or --force).Gitバージョン2.20まで、そしてgit-push [1]でプッシュするときとは異なり、への更新はrefspec（または）refs/tags/*なし+で受け入れられます--force。取得時に、リモートからのすべてのタグ更新を強制的な取得と無差別に考慮しました。Gitバージョン2.20以降、updateへのフェッチはrefs/tags/*pushのときと同じように機能します。+つまり、更新はrefspec（または--force）に含まれずに拒否されます。

Unlike when pushing with git-push[1], any updates outside of refs/{tags,heads}/* will be accepted without + in the refspec (or --force), whether that’s swapping e.g. a tree object for a blob, or a commit for another commit that’s doesn’t have the previous commit as an ancestor etc.git-push [1]でプッシュするときとは異なり、それ以外の更新はrefspec（または）をrefs/{tags,heads}/*使わず+に受け付けられ--forceます。先祖などとしてコミットする

Unlike when pushing with git-push[1], there is no configuration which’ll amend these rules, and nothing like a pre-fetch hook analogous to the pre-receive hook.git-push [1]でプッシュするときとは異なり、これらの規則を修正するような設定はなく、pre-fetchフックに似たフックのようなものもありませんpre-receive。

As with pushing with git-push[1], all of the rules described above about what’s not allowed as an update can be overridden by adding an the optional leading + to a refspec (or using --force command line option). The only exception to this is that no amount of forcing will make the refs/heads/* namespace accept a non-commit object.押すと同様にGitのプッシュ[1] 、更新として許可されていない何について上述した規則の全ては、主要オプションを追加することによって無効にすることができる+refspecに（または使用--forceコマンドラインオプション）。これに対する唯一の例外は、refs/heads/*名前空間がコミットされていないオブジェクトを受け入れるように強制しないことです。

Note When the remote branch you want to fetch is known to be rewound and rebased regularly, it is expected that its new tip will not be descendant of its previous tip (as stored in your remote-tracking branch the last time you fetched). You would want to use the + sign to indicate non-fast-forward updates will be needed for such branches. There is no way to determine or declare that a branch will be made available in a repository with this behavior; the pulling user simply must know this is the expected usage pattern for a branch. あなたがフェッチしたいリモートブランチが定期的に巻き戻されリベースされていることがわかっている場合、その新しいチップは前のチップの子孫にはならないことが予想されます。この+ようなブランチでは、早送り以外の更新が必要になることを示すためにこの記号を使用します。この振る舞いでブランチがリポジトリで利用可能になることを決定または宣言する方法はありません。引っ張ってくるユーザは単にこれがブランチの予想される使用パターンであることを知っていなければならない。

GIT URLSGIT URL

In general, URLs contain information about the transport protocol, the address of the remote server, and the path to the repository. Depending on the transport protocol, some of this information may be absent.一般に、URLにはトランスポートプロトコル、リモートサーバーのアドレス、およびリポジトリへのパスに関する情報が含まれています。トランスポートプロトコルによっては、この情報の一部が欠落している可能性があります。

Git supports ssh, git, http, and https protocols (in addition, ftp, and ftps can be used for fetching, but this is inefficient and deprecated; do not use it).Gitはssh、git、http、およびhttpsプロトコルをサポートしています（さらに、ftp、およびftpsをフェッチに使用できますが、これは非効率的で非推奨です。使用しないでください）。

The native transport (i.e. git:// URL) does no authentication and should be used with caution on unsecured networks.ネイティブトランスポート（つまりgit：// URL）は認証を行わないため、セキュリティ保護されていないネットワークでは注意して使用する必要があります。

The following syntaxes may be used with them:以下の構文がそれらと共に使用されるかもしれません：

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

  • git://host.xz[:port]/path/to/repo.git/git：//host.xz [：port] /path/to/repo.git/

  • http[s]://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/ftp [s]：//host.xz [：port] /path/to/repo.git/

An alternative scp-like syntax may also be used with the ssh protocol:sshプロトコルでは、scpに似た代替構文も使用できます。

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

This syntax is only recognized if there are no slashes before the first colon. This helps differentiate a local path that contains a colon. For example the local path foo:bar could be specified as an absolute path or ./foo:bar to avoid being misinterpreted as an ssh url.この構文は、最初のコロンの前にスラッシュがない場合にのみ認識されます。これは、コロンを含むローカルパスを区別するのに役立ちます。たとえば、ローカルパスをfoo:bar絶対パスとして指定したり./foo:bar、sshのURLとして誤って解釈されないようにすることができます。

The ssh and git protocols additionally support ~username expansion:sshおよびgitプロトコルはさらに〜ユーザー名の展開をサポートします。

  • ssh://[user@]host.xz[:port]/~[user]/path/to/repo.git/ssh：// [ユーザー@] host.xz [：ポート] /〜[ユーザー] /path/to/repo.git/

  • git://host.xz[:port]/~[user]/path/to/repo.git/git：//host.xz [：port] /〜[ユーザー] /path/to/repo.git/

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

For local repositories, also supported by Git natively, the following syntaxes may be used:同じくGitによってサポートされているローカルリポジトリのために、以下の構文が使用されるかもしれません：

  • /path/to/repo.git/

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

These two syntaxes are mostly equivalent, except when cloning, when the former implies --local option. See git-clone[1] for details.これら2つの構文は、前者が--localオプションを暗黙指定している場合を除いて、クローン作成時を除いてほぼ同等です。詳細はgit-clone [1]をご覧ください。

When Git doesn’t know how to handle a certain transport protocol, it attempts to use the remote-<transport> remote helper, if one exists. To explicitly request a remote helper, the following syntax may be used:Gitが特定のトランスポートプロトコルの扱い方を知らない場合、remote- <transport>リモートヘルパーがあればそれを使用しようとします。リモートヘルパーを明示的に要求するには、次の構文が使用されます。

  • <transport>::<address><トランスポート> :: <アドレス>

where <address> may be a path, a server and path, or an arbitrary URL-like string recognized by the specific remote helper being invoked. See gitremote-helpers[1] for details.ここで、<address>はパス、サーバーとパス、または呼び出されている特定のリモートヘルパーによって認識される任意のURLのような文字列です。詳細はgitremote-helpers [1]を見てください。

If there are a large number of similarly-named remote repositories and you want to use a different format for them (such that the URLs you use will be rewritten into URLs that work), you can create a configuration section of the form:同じ名前のリモートリポジトリが多数あり、それらに異なるフォーマットを使用する場合（使用するURLが機能するURLに書き換えられるなど）は、次の形式の構成セクションを作成できます。

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

For example, with this:たとえば、これで：

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

a URL like "work:repo.git" or like "host.xz:/path/to/repo.git" will be rewritten in any context that takes a URL to be "git://git.host.xz/repo.git"."work：repo.git"や "host.xz：/path/to/repo.git"のようなURLは、URLが "git：//git.host.xz/repo"になるような任意のコンテキストで書き換えられます。 "git"。

If you want to rewrite URLs for push only, you can create a configuration section of the form:プッシュ専用のURLに書き換えたい場合は、次の形式の構成セクションを作成できます。

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

For example, with this:たとえば、これで：

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

a URL like "git://example.org/path/to/repo.git" will be rewritten to "ssh://example.org/path/to/repo.git" for pushes, but pulls will still use the original URL."git：//example.org/path/to/repo.git"のようなURLはプッシュのために "ssh：//example.org/path/to/repo.git"に書き換えられますが、プルは依然として元のURL

REMOTESリモート

The name of one of the following can be used instead of a URL as <repository> argument:<repository>引数としてURLの代わりに次のいずれかの名前を使用できます。

  • a remote in the Git configuration file: $GIT_DIR/config,Gitの設定ファイルのリモート：$GIT_DIR/config、

  • a file in the $GIT_DIR/remotes directory, or$GIT_DIR/remotesディレクトリ内のファイル

  • a file in the $GIT_DIR/branches directory.$GIT_DIR/branchesディレクトリ内のファイル

All of these also allow you to omit the refspec from the command line because they each contain a refspec which git will use by default.これらはすべてgitがデフォルトで使用するrefspecを含んでいるので、コマンドラインからrefspecを省略することもできます。

Named remote in configuration file構成ファイルで名前付きリモート

You can choose to provide the name of a remote which you had previously configured using git-remote[1], git-config[1] or even by a manual edit to the $GIT_DIR/config file. The URL of this remote will be used to access the repository. The refspec of this remote will be used by default when you do not provide a refspec on the command line. The entry in the config file would appear like this:あなたは以前にgit-remote [1]、git-config [1]を使って、あるいは手動編集によって、あなたが以前に設定したリモートの名前を提供することを選ぶことができます$GIT_DIR/config。このリモートのURLはリポジトリへのアクセスに使用されます。コマンドラインでrefspecを指定しないと、このリモートのrefspecがデフォルトで使用されます。設定ファイルのエントリは次のようになります。

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

The <pushurl> is used for pushes only. It is optional and defaults to <url>.<pushurl>だけプッシュするために使用されています。これはオプションであり、デフォルトはです<url>。

Named file in $GIT_DIR/remotes名前付きファイル $GIT_DIR/remotes

You can choose to provide the name of a file in $GIT_DIR/remotes. The URL in this file will be used to access the repository. The refspec in this file will be used as default when you do not provide a refspec on the command line. This file should have the following format:でファイルの名前を提供することを選択できます$GIT_DIR/remotes。このファイルのURLはリポジトリへのアクセスに使用されます。コマンドラインでrefspecを指定しないと、このファイルのrefspecがデフォルトとして使用されます。このファイルの形式は次のとおりです。

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

Push: lines are used by git push and Pull: lines are used by git pull and git fetch. Multiple Push: and Pull: lines may be specified for additional branch mappings.Push:linesはgit pushによって使われ、Pull:linesはgit pullとgit fetchによって使われます。追加のブランチマッピングには、複数行Push:とPull:行を指定できます。

Named file in $GIT_DIR/branches名前付きファイル $GIT_DIR/branches

You can choose to provide the name of a file in $GIT_DIR/branches. The URL in this file will be used to access the repository. This file should have the following format:でファイルの名前を提供することを選択できます$GIT_DIR/branches。このファイルのURLはリポジトリへのアクセスに使用されます。このファイルの形式は次のとおりです。

	<url>#<head>

<url> is required; #<head> is optional.<url>必要とされている; #<head>オプションです。

Depending on the operation, git will use one of the following refspecs, if you don’t provide one on the command line. <branch> is the name of this file in $GIT_DIR/branches and <head> defaults to master.操作に応じて、コマンドラインで指定しない場合、gitは以下のいずれかの参照仕様を使用します。<branch>このファイルの名前で$GIT_DIR/branches、<head>デフォルトはmasterです。

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

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

git push uses:git pushは使用します：

	HEAD:refs/heads/<head>

CONFIGURED REMOTE-TRACKING BRANCHES設定されたリモートトラッキングブランチ

You often interact with the same remote repository by regularly and repeatedly fetching from it. In order to keep track of the progress of such a remote repository, git fetch allows you to configure remote.<repository>.fetch configuration variables.同じリモートリポジトリから定期的に繰り返し取得することで、頻繁にやりとりをします。このようなリモートリポジトリの進捗状況を追跡するために、設定変数git fetchを設定することができremote.<repository>.fetchます。

Typically such a variable may look like this:通常、そのような変数は次のようになります。

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

This configuration is used in two ways:この設定は2つの方法で使用されます。

  • When git fetch is run without specifying what branches and/or tags to fetch on the command line, e.g. git fetch origin or git fetch, remote.<repository>.fetch values are used as the refspecs—​they specify which refs to fetch and which local refs to update. The example above will fetch all branches that exist in the origin (i.e. any ref that matches the left-hand side of the value, refs/heads/*) and update the corresponding remote-tracking branches in the refs/remotes/origin/* hierarchy.ときにgit fetch枝および/またはタグは、コマンドライン、例えば上でフェッチするかを指定せずに実行されたgit fetch originかgit fetch、remote.<repository>.fetch値がフェッチするために、地域どのレフリー更新へのREF、彼らが指定refspecs-として使用されています。上記の例では、その中に存在するすべてのブランチorigin（つまり、値の左側に一致するすべての参照）が取得さrefs/heads/*れ、refs/remotes/origin/*階層内の対応するリモートトラッキングブランチが更新されます。

  • When git fetch is run with explicit branches and/or tags to fetch on the command line, e.g. git fetch origin master, the <refspec>s given on the command line determine what are to be fetched (e.g. master in the example, which is a short-hand for master:, which in turn means "fetch the master branch but I do not explicitly say what remote-tracking branch to update with it from the command line"), and the example command will fetch only the master branch. The remote.<repository>.fetch values determine which remote-tracking branch, if any, is updated. When used in this way, the remote.<repository>.fetch values do not have any effect in deciding what gets fetched (i.e. the values are not used as refspecs when the command-line lists refspecs); they are only used to decide where the refs that are fetched are stored by acting as a mapping.場合git fetch、コマンドラインでフェッチする明示的な分岐及び/又はタグで実行され、例えばgit fetch origin master、<refspec>は、コマンドラインで与えられたsは、例えば（フェッチされるべきかを決定masterするための短い手であり、実施例ではmaster:、これ次に、「マスターブランチを取得しますが、どのリモート追跡ブランチをコマンドラインから更新するかは明示的には指定しません」という意味で、コマンド例ではマスターブランチのみを取得します。remote.<repository>.fetch、更新された場合の値は、どのリモート追跡ブランチを決定します。このように使用した場合、remote.<repository>.fetch値は何を決定するのにも効果がありません。取得されます（つまり、コマンドラインでrefspecsが指定されている場合、値はrefspecsとして使用されません）。これらは、マッピングとして機能することによって、取得された参照がどこに格納されるかを決定するためにのみ使用されます。

The latter use of the remote.<repository>.fetch values can be overridden by giving the --refmap=<refspec> parameter(s) on the command line.後者のremote.<repository>.fetch値の使用は--refmap=<refspec>、コマンドラインでパラメータを指定することで上書きできます。

PRUNING剪定

Git has a default disposition of keeping data unless it’s explicitly thrown away; this extends to holding onto local references to branches on remotes that have themselves deleted those branches.Gitには、データが明示的に捨てられない限り、データを保持するというデフォルトの性質があります。これは、自分自身がそれらのブランチを削除したリモート上のブランチへのローカル参照を保持することにまで及びます。

If left to accumulate, these stale references might make performance worse on big and busy repos that have a lot of branch churn, and e.g. make the output of commands like git branch -a --contains <commit> needlessly verbose, as well as impacting anything else that’ll work with the complete set of known references.蓄積することを余儀なくされた場合、これらの古くなった参照はブランチチャーンが多い大規模で忙しいリポジトリではパフォーマンスを悪化させるかもしれません、そして例えばgit branch -a --contains <commit>不必要に冗長なようなコマンドの出力を作る。既知の参考文献の。

These remote-tracking references can be deleted as a one-off with either of:これらのリモートトラッキング参照は、次のいずれかを使用して1回限りで削除できます。

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

To prune references as part of your normal workflow without needing to remember to run that, set fetch.prune globally, or remote.<name>.prune per-remote in the config. See git-config[1].それを実行することを忘れずに、通常のワークフローの一部として参照を整理する、fetch.pruneグローバルに設定する、または設定でremote.<name>.pruneリモートごとに設定する。参照のgit-config設定を[1]。

Here’s where things get tricky and more specific. The pruning feature doesn’t actually care about branches, instead it’ll prune local <→ remote-references as a function of the refspec of the remote (see <refspec> and CONFIGURED REMOTE-TRACKING BRANCHES above).これが、事がトリッキーでより具体的になるところです。剪定機能がなく、実際にそれがリモートのrefspecの関数としてのリモート参照（参照→<ローカル剪定よ、枝を気にしない<refspec>と設定されているリモート追跡ブランチ上で）。

Therefore if the refspec for the remote includes e.g. refs/tags/*:refs/tags/*, or you manually run e.g. git fetch --prune <name> "refs/tags/*:refs/tags/*" it won’t be stale remote tracking branches that are deleted, but any local tag that doesn’t exist on the remote.したがって、たとえばrefs/tags/*:refs/tags/*、リモートのrefspecに含まれている、または手動で実行した場合git fetch --prune <name> "refs/tags/*:refs/tags/*"など、削除された古いリモートトラッキングブランチは削除されませんが、リモートに存在しないローカルタグは削除されません。

This might not be what you expect, i.e. you want to prune remote <name>, but also explicitly fetch tags from it, so when you fetch from it you delete all your local tags, most of which may not have come from the <name> remote in the first place.これは、あなたが期待するものもリモート剪定したくすなわちないかもしれません<name>が、また、明示的にあなたがそれからフェッチするときので、あなたはすべてのあなたの地元のタグを削除し、そこからタグを取得し、そのほとんどはから来ていない可能性があり<name>、最初の場所での遠隔。

So be careful when using this with a refspec like refs/tags/*:refs/tags/*, or any other refspec which might map references from multiple remotes to the same local namespace.したがって、これをrefspecのようなものrefs/tags/*:refs/tags/*、または複数のリモートからの参照を同じローカル名前空間にマッピングする可能性のあるその他のrefspecと一緒に使用するときは注意してください。

Since keeping up-to-date with both branches and tags on the remote is a common use-case the --prune-tags option can be supplied along with --prune to prune local tags that don’t exist on the remote, and force-update those tags that differ. Tag pruning can also be enabled with fetch.pruneTags or remote.<name>.pruneTags in the config. See git-config[1].リモートでブランチとタグの両方を最新の状態に保つことは一般的なユースケースであるため、リモートに存在しないローカルタグを整理し、異なるタグを強制的に更新するための--prune-tagsオプションを一緒に提供でき--pruneます。タグプルーニングはconfigで、fetch.pruneTagsまたはremote.<name>.pruneTagsconfigで有効にすることもできます。参照のgit-config設定を[1]。

The --prune-tags option is equivalent to having refs/tags/*:refs/tags/* declared in the refspecs of the remote. This can lead to some seemingly strange interactions:この--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

The reason it doesn’t error out when provided without --prune or its config versions is for flexibility of the configured versions, and to maintain a 1=1 mapping between what the command line flags do, and what the configuration versions do.--prune設定バージョンなしで、あるいは設定バージョンを指定してもエラーにならないのは、設定バージョンの柔軟性、およびコマンドラインフラグの動作と設定バージョンの動作との間の1 = 1マッピングを維持するためです。

It’s reasonable to e.g. configure fetch.pruneTags=true in ~/.gitconfig to have tags pruned whenever git fetch --prune is run, without making every invocation of git fetch without --prune an error.たとえば、エラーを発生させることなくすべての呼び出しを行わずに、実行されるたびにタグを整理するようにfetch.pruneTags=truein ~/.gitconfigを設定するのが妥当です。git fetch --prunegit fetch--prune

Pruning tags with --prune-tags also works when fetching a URL instead of a named remote. These will all prune tags not found on origin:--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/*'

OUTPUT出力

The output of "git fetch" depends on the transport method used; this section describes the output when fetching over the Git protocol (either locally or via ssh) and Smart HTTP protocol."git fetch"の出力は、使用されている転送方法によって異なります。このセクションでは、Gitプロトコル（ローカルまたはssh経由）とSmart HTTPプロトコルを介してフェッチするときの出力について説明します。

The status of the fetch is output in tabular form, with each line representing the status of a single ref. Each line is of the form:フェッチのステータスは表形式で出力され、各行は単一のrefのステータスを表します。各行は次の形式です。

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

The status of up-to-date refs is shown only if the --verbose option is used.最新の参照のステータスは、--verboseオプションが使用されている場合にのみ表示されます。

In compact output mode, specified with configuration variable fetch.output, if either entire <from> or <to> is found in the other string, it will be substituted with * in the other string. For example, master -> origin/master becomes master -> origin/*.構成変数fetch.outputで指定されたコンパクト出力モードでは、全体<from>または<to>他の文字列で見つかると、他の文字列で置き換えられ*ます。たとえばにmaster -> origin/masterなりmaster -> origin/*ます。

flag 旗

A single character indicating the status of the ref:参照のステータスを示す1文字

(space) （スペース）

for a successfully fetched fast-forward;早送りの早送りに。

+

for a successful forced update;強制アップデートが成功した場合

-

for a successfully pruned ref;剪定に成功した文献

t

for a successful tag update;タグの更新が成功した。

*

for a successfully fetched new ref;新しいrefの取得に成功しました。

!

for a ref that was rejected or failed to update; and拒否された、または更新に失敗した参照用。そして

=

for a ref that was up to date and did not need fetching.最新のもので、フェッチする必要がない参照用。

summary 概要

For a successfully fetched ref, the summary shows the old and new values of the ref in a form suitable for using as an argument to git log (this is <old>..<new> in most cases, and <old>...<new> for forced non-fast-forward updates).正常に取得されたrefの場合、サマリーにはrefの新旧の値がの引数として使用するのに適した形式で表示されますgit log（これは<old>..<new>ほとんどの場合、<old>...<new>強制的な早送りではありません）。

from から

The name of the remote ref being fetched from, minus its refs/<type>/ prefix. In the case of deletion, the name of the remote ref is "(none)".取り出し元のリモート参照の名前から、そのrefs/<type>/接頭部を除いたもの。削除の場合、リモート参照の名前は "（なし）"です。

to に

The name of the local ref being updated, minus its refs/<type>/ prefix.更新されるローカル参照の名前から、そのrefs/<type>/接頭辞を除いたもの。

reason 理由

A human-readable explanation. In the case of successfully fetched refs, no explanation is needed. For a failed ref, the reason for failure is described.人間が読める説明 正常に取得された参照の場合、説明は不要です。参照が失敗した場合は、失敗の理由が説明されています。

EXAMPLES例

  • Update the remote-tracking branches:リモート追跡ブランチを更新します。

    $ git fetch origin

    The above command copies all branches from the remote refs/heads/ namespace and stores them to the local refs/remotes/origin/ namespace, unless the branch.<name>.fetch option is used to specify a non-default refspec.上記のコマンドは、branch。<name> .fetchオプションを使用してデフォルト以外のrefspecを指定しない限り、リモートのrefs / heads /ネームスペースからすべてのブランチをコピーしてローカルのrefs / remotes / origin /ネームスペースに格納します。

  • Using refspecs explicitly:参照仕様を明示的に使用する：

    $ git fetch origin +pu:pu maint:tmp

    This updates (or creates, as necessary) branches pu and tmp in the local repository by fetching from the branches (respectively) pu and maint from the remote repository.これは、（それぞれ）ブランチから、そしてリモートリポジトリからフェッチすることによって、ブランチpuとtmpローカルリポジトリ内のブランチを更新（または必要に応じて作成）puしmaintます。

    The pu branch will be updated even if it is does not fast-forward, because it is prefixed with a plus sign; tmp will not be.puブランチは、それがプラス記号が付いているので、それは、早送りない場合であっても更新されます。tmpならないだろう。

  • Peek at a remote’s branch, without configuring the remote in your local repository:ローカルリポジトリでリモートを設定せずに、リモートのブランチを覗いてみます。

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

    The first command fetches the maint branch from the repository at git://git.kernel.org/pub/scm/git/git.git and the second command uses FETCH_HEAD to examine the branch with git-log[1]. The fetched objects will eventually be removed by git’s built-in housekeeping (see git-gc[1]).最初のコマンドmaintはでリポジトリからブランチを取得しgit://git.kernel.org/pub/scm/git/git.git、2番目のコマンドはgit-log [1]でFETCH_HEADブランチを調べるために使用します。取得したオブジェクトは、gitの組み込みハウスキーピングによって最終的に削除されます（git-gc [1]を参照）。

SECURITYセキュリティ

The fetch and push protocols are not designed to prevent one side from stealing data from the other repository that was not intended to be shared. If you have private data that you need to protect from a malicious peer, your best option is to store it in another repository. This applies to both clients and servers. In particular, namespaces on a server are not effective for read access control; you should only grant read access to a namespace to clients that you would trust with read access to the entire repository.フェッチとプッシュのプロトコルは、一方の側が他方のリポジトリから共有することを意図していないデータを盗むのを防ぐようには設計されていません。悪意のある相手から保護する必要があるプライベートデータがある場合、最善の選択肢はそれを別のリポジトリに保存することです。これはクライアントとサーバーの両方に当てはまります。特に、サーバー上の名前空間は読み取りアクセス制御には効果的ではありません。リポジトリ全体への読み取りアクセスで信頼できるクライアントには、ネームスペースへの読み取りアクセスのみを許可する必要があります。

The known attack vectors are as follows:既知の攻撃方法は次のとおりです。

  1. The victim sends "have" lines advertising the IDs of objects it has that are not explicitly intended to be shared but can be used to optimize the transfer if the peer also has them. The attacker chooses an object ID X to steal and sends a ref to X, but isn’t required to send the content of X because the victim already has it. Now the victim believes that the attacker has X, and it sends the content of X back to the attacker later. (This attack is most straightforward for a client to perform on a server, by creating a ref to X in the namespace the client has access to and then fetching it. The most likely way for a server to perform it on a client is to "merge" X into a public branch and hope that the user does additional work on this branch and pushes it back to the server without noticing the merge.)被害者は、共有することを明示的に意図していないが、相手がそれらを持っている場合は転送を最適化するために使用できるオブジェクトのIDをアドバタイズする "have"行を送信します。攻撃者は盗むためにオブジェクトID Xを選び、Xにrefを送りますが、犠牲者が既に持っているのでXの内容を送るために要求されません。これで、被害者は攻撃者にXがあると考え、Xの内容を後で攻撃者に送り返します。（この攻撃は、クライアントがアクセスできる名前空間にXへの参照を作成し、それをフェッチすることによって、クライアントがサーバー上で実行するのが最も簡単です。サーバーがクライアント上でそれを実行するための最も可能性の高い方法です。 "Xをパブリックブランチにマージし、ユーザーがこのブランチに対して追加の作業を行い、マージに気付かずにサーバーにプッシュすることを期待します。）

  2. As in #1, the attacker chooses an object ID X to steal. The victim sends an object Y that the attacker already has, and the attacker falsely claims to have X and not Y, so the victim sends Y as a delta against X. The delta reveals regions of X that are similar to Y to the attacker.＃1と同様に、攻撃者は盗むためにオブジェクトID Xを選びます。被害者は攻撃者が既に持っているオブジェクトYを送り、攻撃者は誤ってXではなくXを持っていると主張するので、被害者はYをXに対するデルタとして送ります。デルタはYに似たXの領域を攻撃者に明らかにします。

BUGSバグ

Using --recurse-submodules can only fetch new commits in already checked out submodules right now. When e.g. upstream added a new submodule in the just fetched commits of the superproject the submodule itself can not be fetched, making it impossible to check out that submodule later without having to do a fetch again. This is expected to be fixed in a future Git version.--recurse-submodulesを使用すると、現在チェックアウト済みのサブモジュールに新しいコミットを取り込むことしかできません。例えば上流がスーパープロジェクトのちょうど取り出されたコミットに新しいサブモジュールを追加したとき、サブモジュール自体は取り出されることができず、再び取り出さなければならないことなしにそのサブモジュールを後でチェックアウトすることは不可能です。これは将来のGitバージョンで修正される予定です。

SEE ALSO関連項目

git-pull[1]git-pull [1]

GIT

Part of the git[1] suite一部のgit [1]スイート

関連記事

スポンサーリンク

最小版のファイル一覧

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る