Git
日本語 ▾ トピック ▾ 最新バージョン ▾ git-pull は 2.46.2 で最終更新

名前

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

概要

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

説明

リモートリポジトリからの変更を現在のブランチに組み込みます。現在のブランチがリモートより遅れている場合、デフォルトでは、現在のブランチをリモートに合わせて早送りします。現在のブランチとリモートが分岐している場合、ユーザーは --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 から分岐した時点 (つまり、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

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

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

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

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

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

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

--commit
--no-commit

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

--no-commit を使用すると、マージを実行し、マージコミットを作成する直前で停止して、コミットする前にユーザーがマージ結果を検査してさらに微調整する機会を与えます。

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

--edit
-e
--no-edit

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

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

--cleanup=<mode>

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

--ff-only

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

--ff
--no-ff

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

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

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

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

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

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

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

--no-log を指定すると、マージされる実際のコミットの一行の説明はリストされません。

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

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

マージ時にのみ有効です。

--summary
--no-summary

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

--autostash
--no-autostash

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

--allow-unrelated-histories

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

マージ時にのみ有効です。

-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 を参照してください。

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

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

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

--[no-]all

remote.<name>.skipFetchAll 構成変数が設定されているものを除く、すべてのリモートをフェッチします。これは構成変数 fetch.all` をオーバーライドします。

-a
--append

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

--atomic

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

--depth=<depth>

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

--deepen=<depth>

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

--shallow-since=<date>

shallow リポジトリの履歴を深めたり短縮したりして、<date> 以降に到達可能なすべてのコミットを含めます。

--shallow-exclude=<revision>

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

--unshallow

ソースリポジトリが完全な場合、shallow リポジトリを完全なリポジトリに変換し、shallow リポジトリによって課せられたすべての制限を取り除きます。

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

--update-shallow

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

--negotiation-tip=<commit|glob>

デフォルトでは、Git は、受信する packfile のサイズを削減するために、すべてのローカル refs から到達可能なコミットをサーバーに報告し、共通のコミットを見つけようとします。指定した場合、Git は指定された tips から到達可能なコミットのみを報告します。これは、ユーザーがフェッチされる上流 ref と共通のコミットを持つ可能性が高いローカル ref を知っている場合に、フェッチを高速化するのに役立ちます。

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

このオプションの引数には、ref 名の glob、ref、またはコミットの（場合によっては省略された）SHA-1 を指定できます。glob を指定することは、一致する各 ref 名に対してこのオプションを複数回指定することと同じです。

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 を 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 のみに依存します。詳細については、「設定されたリモート追跡ブランチ」セクションを参照してください。

-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 を使用して通信する際、指定された文字列をサーバーに送信します。指定された文字列には、NUL または LF 文字を含めることはできません。サーバーオプションの処理は、不明なものを含め、サーバー固有です。複数の --server-option=<option> が指定されている場合、それらはすべてコマンドラインにリストされた順序で相手側に送信されます。

--show-forced-updates

デフォルトでは、git はフェッチ中にブランチが強制的に更新されたかどうかを確認します。これは fetch.showForcedUpdates を介して無効にできますが、--show-forced-updates オプションはこのチェックが実行されることを保証します。git-config[1] を参照してください。

--no-show-forced-updates

デフォルトでは、git はフェッチ中にブランチが強制的に更新されたかどうかを確認します。パフォーマンス上の理由からこのチェックをスキップするには、--no-show-forced-updates を渡すか、fetch.showForcedUpdates を false に設定します。git-pull 中に使用した場合、--ff-only オプションは、高速転送更新を試行する前に、強制更新があるかどうかをチェックします。git-config[1] を参照してください。

-4
--ipv4

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

-6
--ipv6

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

<repository>

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

<refspec>

どの参照をフェッチし、どのローカル参照を更新するかを指定します。コマンドラインに <refspec> がない場合、フェッチする参照は remote.<repository>.fetch 変数から読み取られます (git-fetch[1] の「設定されたリモート追跡ブランチ」セクションを参照)。

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

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

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

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

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

--force なしでその更新が許可されるかどうかは、フェッチ先の参照ネームスペース、フェッチされるオブジェクトのタイプ、および更新が高速転送と見なされるかどうかによって異なります。一般に、フェッチにはプッシュ時と同じルールが適用されます。それらが何であるかについては、git-push[1] の <refspec>... セクションを参照してください。git fetch に特有のこれらのルールの例外は、以下に示します。

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

git-push[1] でプッシュする場合とは異なり、refs/{tags,heads}/* 以外の更新は、refspec (または --force) に + がなくても受け入れられます。これは、例えば、ツリーオブジェクトを blob にスワップしたり、前のコミットを祖先として持たない別のコミットをコミットにスワップしたりする場合です。

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

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

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

GIT URLS

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

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

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

以下の構文をそれらで使用できます

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

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

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

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

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

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

この構文は、最初のコロンの前にスラッシュがない場合にのみ認識されます。これは、コロンを含むローカルパスを区別するのに役立ちます。たとえば、ローカルパス foo:bar は、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 によってネイティブにサポートされており、以下の構文を使用できます

これらの 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 が引き続き使用されます。

REMOTES

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

  • 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> です。リモートへのプッシュは、定義されたすべての pushurl、または pushurl が定義されていない場合は、定義されたすべての 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 ウェイマージアルゴリズムを使用して 2 つのヘッドのみを解決できます。3 ウェイマージに使用できる共通の祖先が複数ある場合、共通の祖先のマージされたツリーを作成し、それを 3 ウェイマージの参照ツリーとして使用します。これにより、Linux 2.6 カーネルの開発履歴から取得した実際のマージコミットでテストを行うことで、マージミスを引き起こすことなく、マージの競合が少なくなることが報告されています。さらに、この戦略では、名前の変更を伴うマージを検出して処理できます。検出されたコピーは使用しません。このアルゴリズムの名前は頭字語 ("Ostensibly Recursive's Twin") であり、以前のデフォルトアルゴリズムである recursive の代替として作成されたことに由来します。

ort 戦略は、次のオプションを使用できます。

ours

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

これは、他のツリーに何が含まれているかをまったく調べない *ours* マージ戦略と混同しないでください。他のツリーが行ったすべてを破棄し、*私たちの* 歴史にはそこで起こったすべてが含まれていると宣言します。

theirs

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

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

3 ウェイマージのために、指定されたタイプの空白の変更がある行を変更なしとして扱います。行への他の変更と混ざった空白の変更は無視されません。git-diff[1] の -b、-w、--ignore-space-at-eol、および --ignore-cr-at-eol も参照してください。

  • もし *彼らの* バージョンが行に空白の変更のみを加えた場合、 *私たちの* バージョンが使用されます。

  • もし *私たちの* バージョンが空白の変更を加え、 *彼らの* バージョンに実質的な変更が含まれている場合、 *彼らの* バージョンが使用されます。

  • それ以外の場合、マージは通常どおりに進行します。

renormalize

これは、3 ウェイマージを解決する際に、ファイルの 3 つのステージすべてを仮想的にチェックアウトおよびチェックインします。このオプションは、クリーンフィルターまたは行末の正規化ルールが異なるブランチをマージするときに使用することを目的としています。詳細は、gitattributes[5] の「異なるチェックイン/チェックアウト属性を持つブランチのマージ」を参照してください。

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

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 ウェイマージアルゴリズムを使用して 2 つのヘッド (つまり、現在のブランチとプルした別のブランチ) のみを解決できます。交差マージのあいまいさを注意深く検出しようとします。名前変更は処理しません。

octopus

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

ours

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

subtree

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

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

デフォルトの動作

多くの場合、人々はパラメータを指定せずに 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 形式に加えて、次のような globbing refspec を持つことができます。

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

globbing 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 が globbing のものである場合、何もマージされません。

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

例

  • クローンしたリポジトリのリモート追跡ブランチを更新し、それらのいずれかを現在のブランチにマージします

    $ 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. 被害者は、明示的に共有する意図はないが、ピアも持っている場合に転送を最適化するために使用できるオブジェクトの ID を通知する「have」行を送信します。攻撃者は盗むオブジェクト ID X を選択し、X への参照を送信しますが、被害者がすでに持っているため、X のコンテンツを送信する必要はありません。これで、被害者は攻撃者が X を持っていると信じ、後で X のコンテンツを攻撃者に送り返します。（この攻撃は、クライアントがアクセスできるネームスペースに X への参照を作成してフェッチすることにより、クライアントがサーバーで実行するのが最も簡単です。サーバーがクライアントで実行する最も可能性の高い方法は、X を公開ブランチに「マージ」し、ユーザーがこのブランチで追加の作業を行い、マージに気づかずにサーバーにプッシュバックすることを期待することです。）

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

バグ

--recurse-submodules を使用すると、現在、すでにチェックアウトされているサブモジュールで新しいコミットをフェッチできるだけです。たとえば、上流がスーパープロジェクトのフェッチされたばかりのコミットに新しいサブモジュールを追加した場合、サブモジュール自体をフェッチすることはできず、後で再度フェッチせずにそのサブモジュールをチェックアウトすることはできません。これは将来の Git バージョンで修正される予定です。

参照

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

GIT

git[1] スイートの一部

scroll-to-top