英語 ▾ トピック ▾ 最新バージョン ▾ git-pull は 2.49.0 で最終更新されました

名前

git-pull - 別のリポジトリまたはローカルブランチからフェッチして統合する

書式

git pull [<options>] [<repository> [<refspec>…​]]

説明

リモートリポジトリからの変更を現在のブランチに組み込みます。現在のブランチがリモートより遅れている場合、デフォルトでは現在のブランチがリモートと一致するようにfast-forwardされます。現在のブランチとリモートが分岐している場合、ユーザーは ` --rebase ` または ` --no-rebase ` (または ` pull.rebase ` の対応する設定オプション) を使用して、分岐したブランチをどのように調整するかを指定する必要があります。

より正確には、`git pull` は指定されたパラメータで `git fetch` を実行し、その後、設定オプションまたはコマンドラインフラグに応じて、分岐したブランチを調整するために `git rebase` または `git merge` を呼び出します。

<repository> は git-fetch[1] に渡されるリモートリポジトリの名前であるべきです。<refspec> は任意のリモート参照 (例えば、タグの名前) または対応するリモート追跡ブランチを持つリファレンスのコレクション (例: refs/heads/*:refs/remotes/origin/*) を指定できますが、通常はリモートリポジトリ内のブランチの名前です。

<repository> と <branch> のデフォルト値は、git-branch[1] の ` --track ` で設定された現在のブランチの「remote」および「merge」設定から読み込まれます。

以下の履歴が存在し、現在のブランチが「`master`」であると仮定します。

	  A---B---C master on origin
	 /
    D---E---F---G master
	^
	origin/master in your repository

すると「`git pull`」は、リモートの `master` ブランチがローカルの `master` (つまり `E`) から分岐してからの変更をフェッチし、現在のコミット (`C`) まで `master` の上にリプレイし、その結果を2つの親コミットの名前と、ユーザーが変更を記述したログメッセージとともに新しいコミットとして記録します。

	  A---B---C origin/master
	 /         \
    D---E---F---G---H master

競合がどのように表示され、処理されるかを含む詳細は、git-merge[1] を参照してください。

Git 1.7.0 以降では、競合するマージをキャンセルするには `git reset --merge` を使用します。警告: 古いバージョンのGitでは、コミットされていない変更がある状態で *git pull* を実行することは推奨されません。可能ではありますが、競合が発生した場合に元に戻すのが難しい状態になる可能性があります。

リモートの変更がローカルのコミットされていない変更と重複する場合、マージは自動的にキャンセルされ、作業ツリーは変更されません。一般に、プルする前にローカルの変更を整理するか、git-stash[1] を使用して退避させることが最善です。

オプション

-q
--quiet

これは、転送中のレポートを抑制するために基盤となる git-fetch に、およびマージ中の出力を抑制するために基盤となる git-merge の両方に渡されます。

-v
--verbose

git-fetch および git-merge に --verbose を渡します。

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

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

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

更新がマージ経由で行われる場合、サブモジュールの競合は解決され、チェックアウトされます。

マージに関連するオプション

--commit
--no-commit

マージを実行し、結果をコミットします。このオプションは --no-commit を上書きするために使用できます。マージ時にのみ役立ちます。

--no-commit を指定すると、マージを実行し、マージコミットを作成する直前で停止します。これにより、ユーザーはコミットする前にマージ結果を検査し、さらに調整する機会が得られます。

fast-forward 更新はマージコミットを作成しないため、--no-commit でそれらのマージを停止する方法はありません。したがって、マージコマンドによってブランチが変更または更新されないようにしたい場合は、--no-commit と共に --no-ff を使用してください。

--edit
-e
--no-edit

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

古いスクリプトは、ユーザーがマージログメッセージを編集できないという過去の動作に依存している場合があります。それらが `git merge` を実行するとエディタが開くでしょう。そのようなスクリプトを更新された動作に調整しやすくするために、それらの冒頭で環境変数 `GIT_MERGE_AUTOEDIT` を `no` に設定することができます。

--cleanup=<mode>

このオプションは、コミットする前にマージメッセージがどのようにクリーンアップされるかを決定します。詳細は git-commit[1] を参照してください。さらに、*<mode>* に `scissors` の値が指定された場合、マージ競合の際には、コミット機構に渡される前に `MERGE_MSG` にハサミが追加されます。

--ff-only

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

--ff
--no-ff

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

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

` --no-ff ` を指定すると、マージがfast-forwardとして解決できる場合でも、常にマージコミットを作成します。

-S[<keyid>]
--gpg-sign[=<keyid>]
--no-gpg-sign

結果のマージコミットにGPG署名します。` keyid ` 引数はオプションで、デフォルトはコミッターの識別情報です。指定する場合は、スペースなしでオプションに付加する必要があります。` --no-gpg-sign ` は、` commit.gpgSign ` 設定変数と以前の ` --gpg-sign ` の両方を無効にするのに役立ちます。

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

ブランチ名に加えて、マージされる実際のコミットから最大 <n> 個の1行説明をログメッセージに追加します。git-fmt-merge-msg[1] も参照してください。マージ時にのみ役立ちます。

--no-log を指定すると、実際にマージされるコミットからの1行の説明は表示されません。

` --signoff `
` --no-signoff `

コミットログメッセージの最後に、コミッターによる ` Signed-off-by ` トレーラーを追加します。サインオフの意味は、コミット先のプロジェクトによって異なります。例えば、コミッターがプロジェクトのライセンスの下で作業を提出する権利を持っていること、またはDeveloper Certificate of Originのような貢献者の表明に同意することなどを証明する場合があります。(LinuxカーネルおよびGitプロジェクトで使用されているものについては、https://developercertificate.org を参照してください)。あなたが貢献するプロジェクトのドキュメントまたはリーダーシップを参照して、そのプロジェクトでサインオフがどのように使用されているかを理解してください。

` --no-signoff ` オプションは、コマンドライン上の以前の ` --signoff ` オプションを無効にするために使用できます。

--stat
-n
--no-stat

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

-n または --no-stat を指定すると、マージの最後に diffstat は表示されません。

--squash
--no-squash

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

--no-squash を指定すると、マージを実行し、結果をコミットします。このオプションは --squash を上書きするために使用できます。

--squash を指定すると、--commit は許可されず、失敗します。

マージ時にのみ役立ちます。

--[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を持つキーであることを検証します。これは署名キーが信頼されたキーによって署名されていることを意味します。サイドブランチの先端コミットが有効なキーで署名されていない場合、マージは中断されます。

マージ時にのみ役立ちます。

--summary
--no-summary

--stat および --no-stat の同義語です。これらは非推奨であり、将来削除される予定です。

--autostash
--no-autostash

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

--allow-unrelated-histories

デフォルトでは、`git merge` コマンドは共通の祖先を共有しない履歴のマージを拒否します。このオプションは、独立して開始された2つのプロジェクトの履歴をマージする際に、この安全機能を上書きするために使用できます。これは非常にまれなケースであるため、これをデフォルトで有効にする設定変数は存在せず、今後も追加されません。

マージ時にのみ役立ちます。

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

true の場合、フェッチ後に現在のブランチをアップストリームブランチの上にリベースします。アップストリームブランチに対応するリモート追跡ブランチがあり、そのアップストリームブランチが前回フェッチされてからリベースされている場合、リベースはその情報を使用して非ローカルの変更をリベースしないようにします。

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

false の場合、アップストリームブランチを現在のブランチにマージします。

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

常にマージではなく ` --rebase ` を使用するように `git pull` を設定したい場合は、git-config[1] の ` pull.rebase `、` branch.<name>.rebase `、および ` branch.autoSetupRebase ` を参照してください。

注記
 これは潜在的に*危険な*操作モードです。履歴を書き換えるため、すでにその履歴を公開している場合には好ましくありません。git-rebase[1] を注意深く読まない限り、このオプションは**使用しないでください**。
--no-rebase

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

フェッチに関連するオプション

--[no-]all

` remote.<name>.skipFetchAll ` 設定変数が設定されているリモートを除く、すべてのリモートをフェッチします。これは設定変数 ` fetch.all ` を上書きします。

-a
--append

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

--atomic

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

--depth=<depth>

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

--deepen=<depth>

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

--shallow-since=<date>

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

--shallow-exclude=<ref>

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

--unshallow

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

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

--update-shallow

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

--negotiation-tip=<commit|glob>

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

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

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

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 オプションによってのみフェッチされた場合、プルーニングの対象にはなりません。ただし、タグが明示的な refspec (コマンドラインまたはリモート設定、例えばリモートが --mirror オプションでクローンされた場合など) によってフェッチされた場合、それらもプルーニングの対象となります。` --prune-tags ` を指定することは、タグ refspec を提供する省略形です。

--no-tags

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

--refmap=<refspec>

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

-t
--tags

リモートからすべてのタグをフェッチします (つまり、リモートタグ ` refs/tags/* ` を同じ名前のローカルタグにフェッチします)。これは、それ以外にフェッチされるものに加えて行われます。このオプションを単独で使用しても、--prune を使用した場合でもタグはプルーニングの対象になりません (ただし、明示的な refspec の宛先でもある場合、タグはプルーニングされる可能性があります。` --prune ` を参照)。

-j
--jobs=<n>

すべての種類のフェッチに使用される並列子プロセスの数。

` --multiple ` オプションが指定された場合、異なるリモートが並行してフェッチされます。複数のサブモジュールがフェッチされる場合、それらも並行してフェッチされます。それらを独立して制御するには、設定 ` fetch.parallel ` および ` submodule.fetchJobs ` を使用します (git-config[1] を参照)。

通常、並列再帰および複数リモートのフェッチは高速になります。デフォルトでは、フェッチは並列ではなくシーケンシャルに実行されます。

--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を使用して通信する場合、指定された文字列をサーバーに送信します。指定された文字列には、NULLまたは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

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

-6
--ipv6

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

<repository>

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

<refspec>

どの参照をフェッチし、どのローカル参照を更新するかを指定します。コマンドラインに <refspec> が表示されない場合、フェッチする参照は代わりに ` remote.<repository>.fetch ` 変数から読み込まれます (git-fetch[1] の「CONFIGURED REMOTE-TRACKING BRANCHES」セクションを参照)。

<refspec> パラメータの形式は、オプションのプラス ` + ` に続き、ソース <src>、コロン ` : `、そしてデスティネーション <dst> です。<dst> が空の場合、コロンは省略できます。<src> は通常、参照、または参照のセットに一致するために使用される単一の ` * ` を持つグロブパターンですが、完全に記述された16進オブジェクト名でも構いません。

<refspec> は、単純なパターンマッチを示すために <src> に ` * ` を含む場合があります。そのような refspec は、パターンを持つ任意の参照に一致するグロブのように機能します。パターン <refspec> は、<src> と <dst> の両方に1つだけ ` * ` を持たなければなりません。これは、` * ` をソースから一致した内容に置き換えることによって、参照をデスティネーションにマッピングします。

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

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

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

その更新が ` --force ` なしで許可されるかどうかは、フェッチ先の参照名前空間、フェッチされるオブジェクトの種類、および更新がfast-forwardと見なされるかどうかに依存します。一般的に、フェッチにはプッシュ時と同じルールが適用されます。それらのルールについては、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/* ` 名前空間が非コミットオブジェクトを受け入れるようにすることはないということです。

注記
 フェッチしたいリモートブランチが定期的に巻き戻しおよびリベースされることがわかっている場合、その新しい先端は以前の先端 (前回のフェッチ時にリモート追跡ブランチに保存されたもの) の子孫ではないと予想されます。そのようなブランチには、非fast-forward更新が必要であることを示すために ` + ` 記号を使用したいでしょう。この動作を持つブランチがリポジリトリで利用可能になることを決定または宣言する方法はありません。プルするユーザーは、これがブランチの期待される使用パターンであることを単に知っている必要があります。
注記
 *git pull* コマンドラインに複数の <refspec> を直接リストすることと、<repository> の設定に複数の ` remote.<repository>.fetch ` エントリがあり、明示的な <refspec> パラメータなしで *git pull* コマンドを実行することには違いがあります。コマンドラインに明示的にリストされた <refspec> は、フェッチ後に常に現在のブランチにマージされます。言い換えれば、複数のリモート参照をリストすると、*git pull* は Octopus マージを作成します。一方、コマンドラインに明示的な <refspec> パラメータをリストしない場合、*git pull* は ` remote.<repository>.fetch ` 設定で見つかったすべての <refspec> をフェッチし、最初に見つかった <refspec> のみを現在のブランチにマージします。これは、リモート参照からOctopusを作成することはまれである一方、一度に複数のリモートヘッドを追跡することはしばしば有用であるためです。

GIT URL

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

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

ネイティブトランスポート (つまり ` git:// ` URL) は認証を行わず、安全でないネットワークでは注意して使用すべきです。

以下のような構文が使用できます

  • ssh://[<user>@]<host>[:<port>]/<path-to-git-repo>

  • git://<host>[:<port>]/<path-to-git-repo>

  • http[s]://<host>[:<port>]/<path-to-git-repo>

  • ftp[s]://<host>[:<port>]/<path-to-git-repo>

ssh プロトコルでは、代替の scp 風の構文も使用できます

  • [<user>@]<host>:/<path-to-git-repo>

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

ssh および git プロトコルは、さらに ` ~<username> ` 展開をサポートしています

  • ssh://[<user>@]<host>[:<port>]/~<user>/<path-to-git-repo>

  • git://<host>[:<port>]/~<user>/<path-to-git-repo>

  • [<user>@]<host>:~<user>/<path-to-git-repo>

Git がネイティブにサポートしているローカルリポジトリでは、以下の構文が使用できます

  • /path/to/repo.git/

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

これらの2つの構文はほとんど同等ですが、クローン時を除き、前者は ` --local ` オプションを意味します。詳細は git-clone[1] を参照してください。

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

Git が特定のトランスポートプロトコルの処理方法を知らない場合、` remote-<transport> ` リモートヘルパーが存在すれば、それを使用しようとします。リモートヘルパーを明示的に要求するには、以下の構文を使用できます。

  • <transport>::<address>

ここで *<address>* は、パス、サーバーとパス、または呼び出される特定のリモートヘルパーによって認識される任意のURLライクな文字列である場合があります。詳細は gitremote-helpers[7] を参照してください。

似たような名前のリモートリポジトリが多数あり、それらに対して異なる形式を使用したい場合 (使用するURLが機能するURLに書き換えられるように)、以下のような設定セクションを作成できます。

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

例えば、これを使用すると

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

「work:repo.git」や「host.xz:/path/to/repo.git」のようなURLは、URLを受け入れるどのようなコンテキストにおいても、「git://git.host.xz/repo.git」に書き換えられます。

プッシュ専用にURLを書き換えたい場合は、以下のような設定セクションを作成できます。

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

例えば、これを使用すると

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

「git://example.org/path/to/repo.git」のようなURLは、プッシュ時には「ssh://example.org/path/to/repo.git」に書き換えられますが、プル時には元のURLが引き続き使用されます。

リモート

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

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

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

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

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

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

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

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

` <pushurl> ` はプッシュにのみ使用されます。これはオプションであり、デフォルトは ` <URL> ` です。リモートへのプッシュは、定義されているすべてのプッシュ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> ` はオプションです。

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

git fetch はこれを使用します

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

git push はこれを使用します

	HEAD:refs/heads/<head>

マージ戦略

マージメカニズム (`git merge` および `git pull` コマンド) は、バックエンドの*マージ戦略*を ` -s ` オプションで選択することを可能にします。一部の戦略は独自のオプションも取ることができ、それらは `git merge` および/または `git pull` に ` -X<option> ` 引数を与えることによって渡すことができます。

ort

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

パスがサブモジュールである場合、マージの一方の側で使用されるサブモジュールコミットがマージのもう一方の側で使用されるサブモジュールコミットの子孫である場合、Git は子孫へのfast-forwardを試みます。そうでない場合、Git はこのケースを競合として扱い、競合するサブモジュールコミットの子孫であるサブモジュールコミットが1つでも存在する場合は、それを解決策として提案します。

The *ort* strategy can take the following options

ours

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

これは、他のツリーに何が含まれているかさえ見ない *ours* マージ戦略と混同してはなりません。それは、他のツリーが行ったすべてを破棄し、*我々の*履歴にその中で起こったすべてが含まれていると宣言します。

theirs

これは *ours* の反対です。*ours* とは異なり、このマージオプションと混同するような *theirs* マージ戦略は存在しないことに注意してください。

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

指定された種類の空白変更を持つ行を、3-way マージのために変更なしとして扱います。行への他の変更と混じった空白変更は無視されません。git-diff[1] の ` -b `、` -w `、` --ignore-space-at-eol `、および ` --ignore-cr-at-eol ` も参照してください。

  • *相手の*バージョンが行に空白変更のみを導入した場合、*我々の*バージョンが使用されます。

  • *我々の*バージョンが空白変更を導入し、*相手の*バージョンが実質的な変更を含む場合、*相手の*バージョンが使用されます。

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

renormalize

これは、3-way マージを必要とするすべてのファイルの3つのステージすべてに対して、仮想的なチェックアウトとチェックインを実行します。このオプションは、異なるクリーンフィルターまたは行末正規化ルールを持つブランチをマージする場合に使用することを意図しています。詳細は gitattributes[5] の「Merging branches with differing checkin/checkout attributes」を参照してください。

no-renormalize

` renormalize ` オプションを無効にします。これは ` merge.renormalize ` 設定変数を上書きします。

find-renames[=<n>]

名前変更検出をオンにし、オプションで類似度閾値を設定します。これがデフォルトです。これは *merge.renames* 設定変数を上書きします。git-diff[1] の ` --find-renames ` も参照してください。

rename-threshold=<n>

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

subtree[=<path>]

このオプションは、*subtree* 戦略のより高度な形式です。この戦略では、マージ時に2つのツリーを互いに一致させるためにどのようにシフトする必要があるかを推測します。代わりに、指定されたパスが接頭辞として追加されるか (または先頭から削除されるか) して、2つのツリーの形状を一致させます。

recursive

これは、3-way マージアルゴリズムを使用して2つのヘッドのみを解決できます。3-way マージに使用できる共通の祖先が複数ある場合、共通の祖先のマージされたツリーを作成し、それを3-way マージの参照ツリーとして使用します。Linux 2.6 カーネル開発履歴から取得された実際のマージコミットに対するテストにより、これによりマージ競合が少なくなり、誤ったマージが引き起こされないことが報告されています。さらに、これは名前変更を伴うマージを検出および処理できます。検出されたコピーは使用しません。これは Git v0.99.9k から v2.33.0 までの2つのヘッドを解決するデフォルト戦略でした。

サブモジュールであるパスの場合、*ort* と同じ注意がこの戦略にも適用されます。

*recursive* 戦略は *ort* と同じオプションを取ります。ただし、*ort* が無視する (上記では文書化されていない) 3つの追加オプションがあり、これらは *recursive* 戦略で潜在的に役立ちます。

patience

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

diff-algorithm=[patience|minimal|histogram|myers]

マージ中に異なる diff アルゴリズムを使用します。これにより、重要でない一致行 (異なる関数の括弧など) が原因で発生する誤ったマージを回避するのに役立ちます。git-diff[1] の ` --diff-algorithm ` も参照してください。` ort ` は具体的に ` diff-algorithm=histogram ` を使用し、` recursive ` は ` diff.algorithm ` 設定にデフォルトで従うことに注意してください。

no-renames

名前変更検出をオフにします。これは ` merge.renames ` 設定変数を上書きします。git-diff[1] の ` --no-renames ` も参照してください。

resolve

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

octopus

これは2つ以上のヘッドを持つケースを解決しますが、手動での解決が必要な複雑なマージは拒否します。主にトピックブランチのヘッドをまとめるために使用されます。これは、複数のブランチをプルまたはマージするときのデフォルトのマージ戦略です。

ours

これは任意の数のヘッドを解決しますが、マージの結果のツリーは常に現在のブランチヘッドのものであり、他のすべてのブランチからのすべての変更を事実上無視します。これは、サイドブランチの古い開発履歴を置き換えるために使用することを意図しています。これは *recursive* マージ戦略の -Xours オプションとは異なることに注意してください。

subtree

これは変更された ` ort ` 戦略です。ツリー A と B をマージする際に、B が A のサブツリーに対応する場合、B はまず A のツリー構造に一致するように調整されます。これは、同じレベルのツリーを読み取るのではなく行われます。この調整は、共通の祖先ツリーにも適用されます。

3-way マージを使用する戦略 (デフォルトの *ort* を含む) では、両方のブランチで変更が行われ、その後一方のブランチで元に戻された場合、その変更はマージ結果に存在します。一部の人はこの動作を混乱させると感じています。これは、マージを実行する際に、個々のコミットではなく、ヘッドとマージベースのみが考慮されるために発生します。したがって、マージアルゴリズムは元に戻された変更をまったく変更なしと見なし、代わりに変更されたバージョンを置き換えます。

デフォルトの動作

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

フェッチ元のURLを決定するために、` remote.<origin>.url ` 設定の値が参照され、そのような変数が存在しない場合は、` $GIT_DIR/remotes/<origin> ` 内の ` URL: ` 行の値が使用されます。

コマンドラインで refspec パラメータなしでコマンドが実行されたときに、どのリモートブランチをフェッチするか (そしてオプションでリモート追跡ブランチに保存するか) を決定するために、設定変数 ` 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 のリモートブランチがマージされます。

例

  • クローン元のリポジトリのリモート追跡ブランチを更新し、そのうちの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 ` が更新されます。同じことはフェッチとマージを呼び出すことによって行うこともできます。

    $ git fetch origin
$ git merge origin/next

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

セキュリティ

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

既知の攻撃ベクトルは以下の通りです

  1. 被害者は、「have」行を送信して、明示的に共有することを意図していないが、ピアも持っている場合に転送を最適化するために使用できるオブジェクトのIDを宣伝します。攻撃者は盗むオブジェクトID Xを選択し、Xへの参照を送信しますが、被害者がすでに持っているためXの内容を送信する必要はありません。これで被害者は攻撃者がXを持っていると信じ、後でXの内容を攻撃者に送り返します。(この攻撃は、クライアントがアクセスできる名前空間にXへの参照を作成し、それをフェッチすることで、クライアントがサーバーに対して行うのが最も簡単です。サーバーがクライアントに対してこれを行う最も可能性の高い方法は、Xを公開ブランチに「マージ」し、ユーザーがこのブランチで追加の作業を行い、マージに気づかずにサーバーにプッシュバックすることを期待することです。)

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

バグ

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

関連項目

git-fetch[1], git-merge[1], git-config[1]

GIT

git[1] スイートの一部

scroll-to-top