SYNOPSIS

'git pull' [<options>] [<repository> [<refspec>...]]

DESCRIPTION

Integrate changes from a remote repository into the current branch.

First, git pull runs git fetch with the same arguments (excluding merge options) to fetch remote branch(es). Then it decides which remote branch to integrate: if you run git pull with no arguments this defaults to the upstream for the current branch. Then it integrates that branch into the current branch.

There are 4 main options for integrating the remote branch:

  1. git pull --ff-only will only do "fast-forward" updates: it fails if your local branch has diverged from the remote branch. This is the default.

  2. git pull --rebase とすると git rebase を実行します。

  3. git pull --no-rebase とすると git merge を実行します。

  4. git pull --squash とすると git merge --squash を実行します。

You can also set the configuration options pull.rebase, pull.squash, or pull.ff with your preferred behaviour.

If there’s a merge conflict during the merge or rebase that you don’t want to handle, you can safely abort it with git merge --abort or git --rebase abort.

OPTIONS

<repository>

The "remote" repository to pull from. This can be either a URL (see the section GIT URLS below) or the name of a remote (see the section REMOTES below).

Defaults to the configured upstream for the current branch, or origin. See UPSTREAM BRANCHES below for more on how to configure upstreams.

<refspec>

Which branch or other reference(s) to fetch and integrate into the current branch, for example main in git pull origin main. Defaults to the configured upstream for the current branch.

This can be a branch, tag, or other collection of reference(s). See <refspec> below under "Options related to fetching" for the full syntax, and DEFAULT BEHAVIOUR below for how git pull uses this argument to determine which remote branch to integrate.

-q
--quiet

このオプションは git-fetch では転送中のレポートを黙らせる為に、 そして git-merge ではマージ中の出力を黙らせるために、 git-fetch と git-merge の両方に渡されます。

-v
--verbose

--verbose を git-fetch と git-merge に渡します。

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

このオプションは、入力されたサブモジュールの新しいコミットを取得する必要があるかどうか、およびアクティブなサブモジュールの作業ツリーも更新する必要があるかどうかを制御します(git-fetch(1) 、git-config(1) 、gitmodules(5) を参照)。

チェックアウトがリベースを介して行われる場合、ローカルサブモジュールのコミットもリベースされます。

更新がマージを介して行われる場合、サブモジュールの競合(conflicts)は解決され、チェックアウトされます。

Options related to merging

--commit
--no-commit

Perform the merge and commit the result. This option can be used to override --no-commit. マージする場合にのみ役立ちます。

With --no-commit perform the merge and stop just before creating a merge commit, to give the user a chance to inspect and further tweak the merge result before committing.

Note that fast-forward updates do not create a merge commit and therefore there is no way to stop those merges with --no-commit. Thus, if you want to ensure your branch is not changed or updated by the merge command, use --no-ff with --no-commit.

--edit
-e
--no-edit

機械的なマージが成功する前にエディターを呼び出して、 自動生成されたマージ・メッセージをさらに編集し、 ユーザーがマージについて説明して正当化できるようにします。 --no-edit オプションを使用して、 自動生成されたメッセージを受け入れることができます(これは一般的には推奨されていません)。

古いスクリプトは、 ユーザーにマージ・ログ・メッセージの編集を許さないという過去の振る舞いに依存している可能性があります。 そのような場合に git merge を実行すると、 エディターを拝むハメになります。 このようなスクリプトを簡単に最新の振る舞いに合わせるために、 環境変数 GIT_MERGE_AUTOEDIT をスクリプトの先頭で no に設定できます。

--cleanup=<mode>

This option determines how the merge message will be cleaned up before committing. See git-commit(1) for more details. In addition, if the <mode> is given a value of scissors, scissors will be appended to MERGE_MSG before being passed on to the commit machinery in the case of a merge conflict.

--ff-only

分岐する(divergent)ローカル履歴がない場合にのみ、新しい履歴に更新します。 これは、(--rebase=* フラグを介して)分岐する(divergent)履歴を調整する方法が提供されていない場合のデフォルトです。

--ff
--no-ff

リベースではなくマージする場合、マージされた履歴がすでに現在の履歴の子孫である場合に、マージがどのように処理されるかを指定します。 マージが要求された場合、 refs/tags/ 階層の自然な場所に格納されていない注釈付き(および場合によっては署名された)タグをマージしない限り、 --ff がデフォルトです。マージする場合は --no-ff が想定されます。

--ff を使用すると、可能であれば、マージを早送り(fast-forward)(マージされたブランチに一致するようにブランチポインタを更新するだけです。マージコミットは作成しません)として解決します。 不可能な場合(マージされた履歴が現在の履歴の子孫ではない場合)は、マージコミットを作成します。

--no-ff を使用すると、マージが早送り(fast-forward)として解決できる場合でも、すべての場合にマージコミットを作成します。

-S[<key-id>]
--gpg-sign[=<key-id>]
--no-gpg-sign

GPG-sign the resulting merge commit. The <key-id> argument is optional and defaults to the committer identity; if specified, it must be stuck to the option without a space. --no-gpg-sign is useful to countermand both commit.gpgSign configuration variable, and earlier --gpg-sign.

--log[=<n>]
--no-log

In addition to branch names, populate the log message with one-line descriptions from at most <n> actual commits that are being merged. See also git-fmt-merge-msg(1). マージする場合にのみ役立ちます。

With --no-log do not list one-line descriptions from the actual commits being merged.

--signoff
--no-signoff

コミット・ログ・メッセージの最後に、 コミッターによる「Signed-off-by」トレーラーを追加します。 signoff(訳注: 一般には手紙の(末尾の)署名)の意味は、 コミットしているプロジェクトによって異なります。 たとえば、 コミッターがプロジェクトのライセンスに基づいて作品を提出する権利を持っていることを証明したり、開発者の原産地証明書などの寄稿者の代表に同意したりする場合があります(LinuxカーネルおよびGitプロジェクトで使用されるものについては、 https://developercertificate.org を参照してください)。 プロジェクトでsignoffがどのように使用されるかを理解するには、 貢献しているプロジェクトのドキュメントまたはリーダーシップ(leadership)を参照してください。

コマンドラインで --no-signoff オプションを使用すると、 それ以前の --signoff オプションを無効にすることができます。

--stat
-n
--no-stat

マージの最後にdiffstatを表示します。 diffstatは、構成オプションmerge.statによっても制御されます。

With -n or --no-stat do not show a diffstat at the end of the merge.

--compact-summary

Show a compact-summary at the end of the merge.

--squash
--no-squash

(マージ情報を除く)実際のマージが発生したかのように作業ツリーとインデックスの状態を生成しますが、 実際にコミットしたり、 HEAD を移動したり、 $GIT_DIR/MERGE_HEAD を記録したりしません(つまり、 次の git commit コマンドでマージ・コミットが作成されます)。 これにより、 あなたは現在のブランチの上に単一のコミットを作成できます。その効果は、別のブランチ(または octopus の場合は、 複数のブランチ)をマージするのと同じです。

With --no-squash perform the merge and commit the result. This option can be used to override --squash.

With --squash, --commit is not allowed, and will fail.

マージする場合にのみ役立ちます。

--verify
--no-verify

デフォルトでは、 pre-merge フックと commit-msg フックが実行されます。 --no-verify が指定されている場合、これらはバイパスされます。 githooks(5) も参照してください。 マージする場合にのみ役立ちます。

-s <strategy>
--strategy=<strategy>

指定されたマージ戦略を使用します。 試行する順序を指定するために、複数回指定できます。 -s オプションがない場合は、代わりに組み込みの戦略リストが使用されます(単一のヘッドをマージする場合は ort、それ以外の場合は octopus)。

-X <option>
--strategy-option=<option>

マージ戦略固有のオプションをマージ戦略に渡します。

--verify-signatures
--no-verify-signatures

マージされるサイド・ブランチの先端コミットが有効なキー、つまり有効なuidを持つキーで署名されていることを確認します。デフォルトの信頼モデルでは、これは署名キーが信頼できるキーによって署名されていることを意味します。サイド・ブランチの先端コミットが有効なキーで署名されていない場合、マージは中止(abort)されます。

マージする場合にのみ役立ちます。

--summary
--no-summary

Synonyms to --stat and --no-stat; these are deprecated and will be removed in the future.

--autostash
--no-autostash

操作を開始する前に一時的なスタッシュ・エントリを自動的に作成し、 それを ref MERGE_AUTOSTASH に記録し、 操作の終了後に適用(apply)します。 これは、 ダーティ・ワークツリーで操作を実行できることを意味します。 ただし、 注意して使用してください: マージの成功後に最後のスタッシュを適用すると深刻な競合を引き起こす可能性があります。

--allow-unrelated-histories

By default, git merge command refuses to merge histories that do not share a common ancestor. This option can be used to override this safety when merging histories of two projects that started their lives independently. As that is a very rare occasion, no configuration variable to enable this by default exists or will be added.

マージする場合にのみ役立ちます。

-r
--rebase[=(false|true|merges|interactive)]

trueの場合、 取得後に現在のブランチを上流ブランチの上にリベースします。 上流ブランチに対応するリモート追跡ブランチがあり、上流ブランチが最後に取得されてからリベースされた場合、リベースはその情報を使用して、非ローカル変更のリベースを回避します。

merges に設定すると、 git rebase --rebase-merges を使用してリベースし、ローカルマージコミットがリベースに含まれるようにします(詳細については、 git-rebase(1) を参照してください)。

falseの場合、上流ブランチを現在のブランチにマージします。

interactive の場合、リベースの対話モードを有効にします。

git pull がマージする代わりに、常に --rebase を使用するようにしたいなら、 git-config(1) の pull.rebase と branch.<name>.rebase と branch.autoSetupRebase を参照してください。

Note
 これは潜在的に「危険」な操作モードです。 それは履歴を塗り替えてしまいます。その履歴はすでに公開されているのですから、良くない兆候です。 git-rebase(1) を注意深く読んでいない限り、このオプションを使用しないでください。
--no-rebase

これは --rebase=false の省略形です。

Options related to fetching

--all
--no-all

remote.<name>.skipFetchAll 設定変数が設定されているリモートを除く、 すべてのリモートを取得(fetch)します。 これは設定変数 fetch.all をオーバーライドします。

-a
--append

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

--atomic

アトミック・トランザクションを使用して、ローカル参照を更新します。 すべての参照が更新されるか、あるいは、エラーが発生してすべての参照が更新されないか、のいずれかです。

--depth=<depth>

各リモートブランチ履歴の先端からの指定されたコミット数に取得を制限します。 --depth=<depth> オプションを指定して git clone によって作成された浅いリポジトリー(shallow repository)から取得する場合(git-clone(1) 参照)、指定されたコミット数まで履歴を深くするか浅くするかします。

--deepen=<depth>

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

--shallow-since=<date>

浅い(shallow)リポジトリーの履歴を深くしたり浅くしたりして、<date>以降の到達可能なすべてのコミットを含めます。

--shallow-exclude=<ref>

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

--unshallow

ソース・リポジトリーが完全な場合は、 浅い(shallow)リポジトリーを完全なリポジトリーに変換し、 浅い(shallow)リポジトリーに課せられるすべての制限を取り除きます。

ソース・リポジトリーが浅い(shallow)場合は、現在のリポジトリーがソースリ・ポジトリと同じ履歴を持つように、可能な限り取得します。

--update-shallow

デフォルトでは、 浅い(shallow)リポジトリーから取得する場合、 git fetch は .git/shallow の更新が必要な参照を拒否します。 このオプションは .git/should を更新し、 そのような参照を受け入れます。

--negotiation-tip=<commit|glob>

デフォルトでは、 Gitは、 受信するパック・ファイルのサイズを縮小するために、 すべてのローカル参照から到達可能なコミットをサーバーに報告して、 共通のコミットを見つけます。 指定した場合、 Gitは指定された先端から到達可能なコミットのみを報告します。 これは、 取得される上流の参照と共通のコミットを持つ可能性のあるローカル参照がユーザーにわかっている場合に、 取得を高速化するのに役立ちます。

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

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

git-config(1) に記載されている fetch.negotiationAlgorithm と push.negotiate 構成変数、および、以下の --negotiate-only オプションも参照してください。

--negotiate-only

サーバーから何も取得せず、代わりに、サーバーと共通している、提供された --negotiation-tip=* 引数の祖先を出力します。

これは --recurse-submodules=[yes|on-demand] と互換性がありません。 内部的には、これは push.negotiate オプションを実装するために使用されます。 git-config(1) を参照してください。

--dry-run

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

--porcelain

スクリプトがパースしやすい形式で標準出力に出力します。 詳細については、git-fetch(1) のセクション OUTPUT を参照してください。

これは --recurse-submodules=[yes|on-demand] とは互換性がなく、 かつ、 fetch.output 設定オプションよりも優先されます。

-f
--force

git fetch が <src>:<dst> な refspec とともに使用される場合、 git-fetch(1) ドキュメントの「<refspec>」のところで説明されているように、 ローカル ・ブランチの更新が拒否されることがあります。 このオプションはそのチェックをオーバーライドします。

-k
--keep

ダウンロードしたパックを保持してください。

--prefetch

構成されたrefspecを変更して、すべての参照を refs/prefetch/ 名前空間に配置します。 git-maintenance(1)の prefetch タスクを参照してください。

-p
--prune

取得する前に、リモートに存在しなくなったリモート追跡参照を削除します。 タグは、デフォルトのタグの自動追跡または --tags オプションのためにのみフェッチされた場合(コマンドラインまたはリモート構成のいずれかで、たとえば、リモートが --mirror オプションでcloneされた場合)、刈り込み(pruning)の対象にはなりません。 ただし、明示的なrefspecが原因でタグが取得された場合、それらも刈り込み(pruning)の対象になります。 --prune-tags を指定することは、タグrefspecを提供するための省略形です。

--no-tags

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

--refmap=<refspec>

コマンドラインにリストされている参照を取得するときは、 リモートリポジトリーの remote.*.fetch 構成変数の値の代わりに、指定されたrefspec(複数回指定可能)を使用して参照をリモート追跡ブランチにマップします。 空の <refspec> を --refmap オプションに指定すると、 Gitは構成されたrefspecs を無視し、 コマンドライン引数として提供された refspecs に完全に依存します。 詳細については、「Configured Remote-tracking Branches」セクションを参照してください。

-t
--tags

他の方法で取得されるものに加えて、リモートからすべてのタグを取得します(つまり、リモートタグ refs/tags/* を同じ名前のローカルタグに取得します)。 このオプションを単独で使用しても、 --prune が使用されている場合でも、タグは刈り込み(pruning)の対象にはなりません(ただし、タグが明示的なrefspecの宛先でもある場合は、タグは刈り込み(pruning)される可能性があります。 --prune を参照してください)。

-j
--jobs=<n>

すべての形式の取得に使用されるparallel childrenの数。

--multiple オプションが指定された場合、異なるリモートが並行して取得されます。 複数のサブモジュールが取得される場合、それらは並行して取得されます。 それらを個別に制御するには、構成設定 fetch.parallel と submodule.fetchJobs を使用します(git-config(1) 参照)。

通常、並列再帰取得(parallel recursive fetches)やマルチリモート取得(multi-remote fetches)の方が高速です。デフォルトでは、取得は並列ではなく順次実行されます。

--set-upstream

リモートが正常に取得された場合は、引数のない git-pull(1) およびその他のコマンドで使用される上流(追跡)参照を追加します。 詳細については、 git-config(1) の branch.<name>.merge および branch.<name>.remote を参照してください。

--upload-pack <upload-pack>

このオプションが指定され、 かつ、 取得元のリポジトリーが git fetch-pack によって処理される場合、 --exec=<upload-pack> がコマンドに渡され、もう一方の端で実行されるコマンドのデフォルト以外のパスが指定されます。

--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 オプションは、早送り(fast-forward)更新を試行する前に、強制更新をチェックします。 git-config(1) を参照してください。

-4
--ipv4

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

-6
--ipv6

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

<repository>

fetch または pull 操作のソースである「リモート」リポジトリー。このパラメーターは、URL(以下の GIT URLS セクションを参照)またはリモートの名前(以下の REMOTES セクションを参照)のいずれかです。

<refspec>

取得するrefと更新するローカルrefを指定します。コマンドラインに <refspec> がない場合、取得するrefは代わりに remote.<repository>.fetch 変数から読み取られます。 (git-fetch(1) の 「CONFIGURED REMOTE-TRACKING BRANCHES」セクション参照)

<refspec> パラメータの書式は、 オプションのプラス + に続いて、 ソースの <src> 、コロン : 、 宛先の <dst> の順です。 <dst> が空の場合、 コロン(:)は省略できます。 <src> は通常 ref 、 または一連の refs とマッチさせる使用する単一の * を含むグロブ(glob)パターンですが、 フルスペルの16進オブジェクト名にすることもできます。

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

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

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

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

その更新が --force なしで許可されるかどうかは、取得先のref名前空間、取得されるオブジェクトのタイプ、および更新がfast-forwardであると見なされるかどうかによって異なります。一般に、 push する場合と同じルールが fetch に適用されます。それらが何であるかについては、 git-push(1)の <refspec>... セクションを参照してください。 以下に git fetch に固有の例外ルールを示します:

Gitバージョン2.20までは、 git-push(1) でプッシュする場合とは異なり、 refs/tags/* の更新は、 refspec に + がなくても(または --force 指定が無くても)受け入れられます。 fetch するとき、リモートからのすべてのタグ更新を強制取得としていました。Gitバージョン2.20以降では、 refs/tags/* を更新するための fetch は、 push する場合と同じように機能します。 つまり refspecに + が無い場合(または --force が無い場合)、更新は拒否されます。

git-push(1) でプッシュする場合とは異なり、 refs/{tags,heads}/* の外部での更新は、 refspec に + を指定しなくても(または --force を指定しなくても)受け入れられます。 たとえば、 ツリー・オブジェクトをブロブに置き換えたり、 あるコミットを、 その前のコミットを祖先としない別のコミットに置き換えたりする場合などです。

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

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

Note
 取得するリモート・ブランチが定期的に巻き戻されてリベースされることがわかっている場合、その新しい先端は(最後に取得したときにリモート・トラッキング・ブランチに保存された)以前の先端の子孫ではないことが予想されます。あなたは + 記号を使用して、そのようなブランチにnon-fast-forwardの更新が必要であることを指示します。この操作でブランチがリポジトリーで使用可能になることを決定または宣言する方法はありません。プルするユーザーは、これがブランチの予想される使用パターンであることを知っている必要があります。
Note
 git pull コマンドラインに直接複数の <refspec> をリストすることと、 <repository> の構成に複数の remote.<repository>.fetch エントリを含めることと、明示的な <refspec> パラメーターなしで git pull コマンドを実行することには違いがあります。コマンドラインに明示的にリストされている <refspec> は、 fetch 後に常に現在のブランチにマージされます。いいかえると、複数のリモートrefをリストする場合 git pull はOctopusマージを作成します。一方、コマンドラインに明示的な <refspec> パラメータをリストしない場合 git pull は remote.<repository>.fetch 構成で見つかったすべての <refspec> を取得し、最初に見つかった <refspec> のみを現在のブランチにマージします。これはリモートrefからOctopusを作成することはめったに行われない為ですが、複数のリモート・ヘッドを追跡するために複数のリモート・ヘッドを一度に取得すると便利なことがよくあります。

GIT URLS

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

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

ネイティブ・トランスポート(つまり、 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つの構文はほとんど同等ですが、 clone 時には前者が --local オプションを意味します。 詳細は git-clone(1) を参照してください。

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

Gitが特定のトランスポート・プロトコルを処理する方法を知らない場合、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は、任意のコンテキストで、 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のままです。

REMOTES

<repository> 引数として、URLの代わりに以下のいずれかの名前を使用できます:

  • Git構成ファイル(configuration file)内のリモート(remote)として、 $GIT_DIR/config または

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

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

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

Named remote in configuration file

あなたは、 git-remote(1) を使うか、または git-config(1) を使うか、または $GIT_DIR/config ファイルを手動で編集して、これ以前に構成したリモートの名前から選択できます。このリモートのURLは、リポジトリーへのアクセスに使用されます。コマンドラインでrefspecを指定しない場合、このリモートのrefspecがデフォルトで使用されます。構成ファイルのエントリは以下のようになります:

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

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

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

Named file in $GIT_DIR/branches

$GIT_DIR/branches でファイル名を指定できます。このファイルのURLは、リポジトリーへのアクセスに使用されます。 このファイルの形式は以下のとおりです:

        <URL>#<head>

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

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

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

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

git push は以下を使用します:

        HEAD:refs/heads/<head>

UPSTREAM BRANCHES

Git のブランチには、 オプションで上流(upstream)のリモート・ブランチを含めることができます。 Git はデフォルトでは、 リモート操作に上流ブランチを使用します。 以下に例を示します:

  • これは、 引数なしの git pull や git fetch のデフォルトです。

  • これは、引数なしの git push のデフォルトです。 たとえば、 branch.<name>.pushRemote 設定を使うことで、 pull 元とは異なるリモートに push することができ、 また、 デフォルトの push.default=simple の場合には、 設定する上流ブランチの名前は必ずローカル・ブランチのいずれかと同一の名前でなければなりません。

  • git checkout や git status など、 さまざまなコマンドは、 あなたがそのブランチをフォークして以降、 現在いるブランチと上流でそれぞれ何コミット追加されたかを教えてくれます。 たとえば、「あなたのブランチと origin/main は分岐しており、 それぞれ 2 個と 3 個の異なるコミットがあります。」("Your branch and origin/main have diverged, and have 2 and 3 different commits each respectively"). と表示されます。

上流(upstream)は .git/config の「remote」フィールドと「merge」フィールドに保存されます。 たとえば、 main の上流が origin/main の場合以下のようになります:

[branch "main"]
   remote = origin
   merge = refs/heads/main

あなたは git Push --set-upstream <remote> <branch> を使用して上流ブランチを明示的に設定できますが、 多くの場合、 Git は自動的に上流を設定します。 以下に例を示します:

  • あなたがリポジトリーのクローンを作成すると、 Git はデフォルト・ブランチの上流を自動的に設定します。

  • あなたが push.autoSetupRemote 設定オプションを設定している場合、 初めてブランチをプッシュするときに、 git Push が自動的に上流を設定します。

  • git checkout <branch> を使用してリモート追跡ブランチをチェックアウトすると、 その名前でローカル・ブランチが自動的に作成され、 上流が上流ブランチに設定されます。

Note
 上流ブランチは、「ブランチの追跡情報を設定する」(set the branch’s tracking information)と言うように、 「追跡情報」(tracking information)と呼ばれることもあります。

MERGE STRATEGIES

マージ機構(git merge と git pull コマンド)では、バックエンドの「マージ戦略」を -s オプションで選択することができます。 いくつかの戦略では、独自のオプションを指定することができます。これは、 git merge や git pull に -X<option> 引数として渡すことができます。

ort

これは、1つのブランチをプルまたはマージするときのデフォルトのマージ戦略です。この戦略では、3方向マージアルゴリズムを使用して2つのヘッドのみを解決できます。3方向マージに使用できる共通の祖先が複数ある場合は、共通の祖先のマージされたツリーを作成し、それを3方向のマージの参照ツリーとして使用します。これにより、Linux 2.6カーネルの開発履歴から取得した実際のマージコミットで実行されたテストによって、誤ったマージを引き起こすことなく、マージの競合が少なくなることが報告されています。さらに、この戦略では、名前の変更を伴うマージを検出して処理できます。検出されたコピーは使用しません。このアルゴリズムの名前は "Ostensibly Recursive’s Twin" (表面上は再帰の双子)の頭文字を取ったものであり、以前のデフォルトのアルゴリズムである「recursive」の代わりとして作成されたという事実に由来しています。

In the case where the path is a submodule, if the submodule commit used on one side of the merge is a descendant of the submodule commit used on the other side of the merge, Git attempts to fast-forward to the descendant. Otherwise, Git will treat this case as a conflict, suggesting as a resolution a submodule commit that is descendant of the conflicting ones, if one exists.

The ort strategy can take the following options:

ours

このオプションは、「our」バージョンを優先することにより、競合するハンクをクリーンに自動解決するように強制します。 our側と競合しない他のツリーからの変更は、マージ結果に反映されます。 バイナリファイルの場合、内容全体がour側から取得されます。

This should not be confused with the ours merge strategy, which does not even look at what the other tree contains at all. It discards everything the other tree did, declaring our history contains all that happened in it.

theirs

This is the opposite of ours; note that, unlike ours, there is no theirs merge strategy to confuse this merge option with.

ignore-space-change
ignore-all-space
ignore-space-at-eol
ignore-cr-at-eol

指示されたタイプの空白(whitespace)の変更を含む行を、3方向マージのために変更されていないものとして扱います。行に対する、他の変更と空白(whitespace)の変更との混合は、無視されません。 git-diff(1) の -b と -w と --ignore-space-at-eol と --ignore-cr-at-eol も参照してください。

  • 「their」バージョンが行に空白の変更のみを導入する場合、「our」バージョンが使用されます。

  • 「our」バージョンで空白の変更が導入されたが、「their」バージョンに大幅な変更が含まれている場合は、「their」バージョンが使用されます。

  • それ以外の場合、マージは通常の方法で進行します。

renormalize

This runs a virtual check-out and check-in of all three stages of any file which needs a three-way merge. This option is meant to be used when merging branches with different clean filters or end-of-line normalization rules. See "Merging branches with differing checkin/checkout attributes" in gitattributes(5) for details.

no-renormalize

renormalize オプションを無効にします。 これは、 merge.renormalize 構成変数をオーバーライドします。

find-renames[=<n>]

Turn on rename detection, optionally setting the similarity threshold. This is the default. This overrides the merge.renames configuration variable. See also git-diff(1) --find-renames.

rename-threshold=<n>

find-renames=<n> の非推奨の同義語。

no-renames

名前変更(rename)の検出をオフにします。 これは、merge.renames 構成変数をオーバーライドします。 git-diff(1) の --no-renames も参照してください。

histogram

Deprecated synonym for diff-algorithm=histogram.

patience

diff-algorithm=patience の非推奨の同義語。

diff-algorithm=(histogram|minimal|myers|patience)

Use a different diff algorithm while merging, which can help avoid mismerges that occur due to unimportant matching lines (such as braces from distinct functions). See also git-diff(1) --diff-algorithm. Note that ort defaults to diff-algorithm=histogram, while regular diffs currently default to the diff.algorithm config setting.

subtree[=<path>]

このオプションは「subtree」戦略をさらに発展させたもので、2つの木をマージする際に、どのようにずらせば互いにマッチするかを推測するものである。その代わり、指定されたパスは、2つの木の形が一致するように前置される(または、最初から取り除かれる)。

recursive

This is now a synonym for ort. It was an alternative implementation until v2.49.0, but was redirected to mean ort in v2.50.0. The previous recursive strategy was the default strategy for resolving two heads from Git v0.99.9k until v2.33.0.

resolve

これは、3方向マージアルゴリズムを使用して、2つのヘッド（つまり、現在のブランチとプルした別のブランチ）のみを解決できます。 交差マージ(criss-cross merge)のあいまいさを注意深く検出しようとします。 名前の変更は処理しません。

octopus

これにより、3つ以上のヘッドを持つケースが解決されますが、手動解決が必要な複雑なマージの実行は拒否されます。これは主に、トピックの分岐ヘッドを纏めるために使用されることを意図しています。これは、複数のブランチをプルまたはマージする場合のデフォルトのマージ戦略です。

ours

This resolves any number of heads, but the resulting tree of the merge is always that of the current branch head, effectively ignoring all changes from all other branches. It is meant to be used to supersede old development history of side branches. Note that this is different from the -Xours option to the ort merge strategy.

subtree

これは改造された「ort」戦略です。 ツリーAとBをマージするとき、BがAのサブツリーに対応する場合、同じレベルのツリーを読み取るのではなく、Bは最初にAのツリー構造に一致するように調整されます。 この調整は、共通の祖先ツリーに対しても行われます。

With the strategies that use 3-way merge (including the default, ort), if a change is made on both branches, but later reverted on one of the branches, that change will be present in the merged result; some people find this behavior confusing. It occurs because only the heads and the merge base are considered when performing a merge, not the individual commits. The merge algorithm therefore considers the reverted change as no change at all, and substitutes the changed version instead.

DEFAULT BEHAVIOUR

git pull は多くの場合パラメータを指定せずに使われます。伝統的にこれは git pull origin と言うのと同じです。 ただし、ブランチ <name> に設定 branch.<name>.remote が存在する場合は、 origin の代わりにその値が使用されます。

取得に使用するURLを決定するために、構成 remote.<origin>.url の値が参照され、そのような変数がない場合は、 $GIT_DIR/remotes/<origin> の URL: 行の値が使用されます。

コマンドラインにrefspecパラメーターを指定せずにコマンドを実行したときに取得する(およびオプションでリモート追跡ブランチに格納する)リモートブランチを決定するには、構成変数 remote.<origin>.fetch の値を参照します。 構成変数 remote.<origin>.fetch が存在しない場合は、 $GIT_DIR/remotes/<origin> が参照され、その Pull: 行が使用されます。 「OPTIONS」セクションで説明されているrefspec形式に加えて、以下のようなrefspecグロブを作成できます:

refs/heads/*:refs/remotes/origin/*

グロブの refspec には空でないRHSが必要であり(つまり、リモート追跡ブランチで取得されたものを格納する必要があります)、そのLHSとRHSは /* で終わる必要があります。 上記では、すべてのリモート・ブランチが、同じ名前の refs/remotes/origin/ 階層のリモート追跡ブランチを使用して追跡されることを指定しています。

下位互換性を損なわないために、 取得後にマージするリモート・ブランチを決定するルールは少し複雑です。

git pull のコマンドラインで明示的なrefspecが指定されている場合、それらはすべてマージされます。

コマンドラインでrefspecが指定されていない場合、 git pull は 構成 または $GIT_DIR/remotes/<origin> からのrefspecを使用します。このような場合、以下のルールが適用されます:

  1. 現在のブランチ <name> の branch.<name>.merge 構成が存在する場合、それはマージされるリモートサイトのブランチの名前です。

  2. refspecがグロブのものである場合、何もマージされません。

  3. それ以外の場合は、最初のrefspecのリモートブランチがマージされます。

EXAMPLES

  • クローンを作成したリポジトリのリモート追跡ブランチを更新し、そのうちの1つを現在のブランチにマージします: 

    $ git pull
$ git pull origin

    通常、マージされるブランチはリモートリポジトリのHEADですが、選択は branch.<name>.remote および branch.<name>.merge オプションによって決定されます。 詳細については、 git-config(1) を参照してください。

  • 現在のブランチにリモートブランチ next をマージします: 

    $ git pull origin next

    これにより、 next のコピーが一時的に FETCH_HEAD に残され、 リモート追跡ブランチの origin/next が更新されます。 fetch と merge を呼び出すことで同じことができます:

    $ git fetch origin
$ git merge origin/next

あなたがプルを試みた結果、複雑な競合が発生し、最初からやり直したい場合は、 git reset で回復できます。

SECURITY

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

既知の攻撃ベクトル(attack vectors)は以下のとおりです:

  1. 被害者は have 行を送信して、 所有しているオブジェクトのIDを広告(advertise)します。 これらのIDは明示的に共有されることを意図していませんが、 相手(peer)もそれを持っている場合に転送を最適化するために使用できます。 攻撃者は盗むオブジェクトID Xを選択して、 X への ref 送信しますが、 被害者はすでにXのコンテンツを持っているため、 Xのコンテンツを送信する必要はありません。 これで、 被害者は攻撃者がXを持っていると信じ、 X のコンテンツを後で攻撃者に送り返します。 (この攻撃は、クライアントがアクセスできる名前空間に X への ref を作成してフェッチすることにより、 クライアントがサーバー上で実行するのが最も簡単です。 サーバーがクライアント上で実行する最も可能性の高い方法は、 X をパブリック・ブランチにマージし、ユーザーがこのブランチで追加の作業を行い、マージに気付かずにサーバーにプッシュバックすることを期待します。)

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

BUGS

現在は --recurse-submodules を使用すると、 既にチェックアウトされているサブモジュールでの新しいコミットのみを取得できます。 たとえば、 上流がスーパー・プロジェクトの直前に取得したコミットで新しいサブモジュールを追加した場合、 そのサブモジュール自体を取得できないため、 後でそのサブモジュールをチェックアウトするには再度取得する必要があります。 この問題は、 将来の Git バージョンで修正される予定です。

SEE ALSO

git-fetch(1), git-merge(1), git-config(1)

GIT

Part of the git(1) suite