git-pull

コマンド名

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

概要

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

説明

リモートリポジトリからの変更を現在のブランチに組み込みます。デフォルトモードではgit pullはgit fetchの省略形であり、その後にgit merge FETCH_HEADが続きます。

より正確には「git pull」は指定されたパラメーターを使用して「git fetch」を実行し、「git merge」を呼び出し、取得したブランチヘッドを現在のブランチにマージします。--rebaseを使用すると、「gitmerge」の代わりに「gitrebase」を実行します。

<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）から分岐してから、masterの上の現在のコミット（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 to squelch」レポートと「git-merge tosquelch」出力の両方にパスされます。

-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」を使用してこれらのマージを停止する方法はないことに注意してください。したがって、「merge」コマンドによってブランチが変更または更新されないようにする場合、「-no-ff」と「–no-commit」を使用します。

--edit
-e
--no-edit

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

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

--cleanup=<mode>

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

--ff
--no-ff
--ff-only

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

--ffを使用すると、可能な場合、マージをファーストフォワードして解決します（マージされたブランチに一致するようにブランチポインターを更新するだけです。マージコミットは作成しないでください）。 不可能な場合（マージされた履歴が現在の履歴の子孫でない場合）、マージコミットを作成します。

--no-ffを使用すると、マージがファーストフォワードで解決できる場合でもすべての場合にマージコミットを作成します。

--ff-onlyを使用して、可能な場合はマージをファーストフォワードして解決します。不可能な場合は、マージを拒否し、ゼロ以外のステータスで終了します。

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

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

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

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

「–no-log」を使用すると、マージされる実際のコミットからの1ラインの説明を一覧表示しません。

--signoff
--no-signoff

コミットログメッセージの最後にコミッターによるサインオフラインを追加します。サインオフの意味はプロジェクトによって異なりますが、通常、コミッターが同じライセンスの下でこのワークを提出する権利を持ち、開発者の証明書に同意することを意味します（詳細についてはhttp://developercertificate.org/を参照）。

「–no-signoff」を使用して、「Signed-off-by line」を追加しません。

--stat
-n
--no-stat

マージの最後に「diffstat」を表示します。「diffstat」は構成オプション「merge.stat」によってもコントロールされます。

「-n」または「–no-stat」を使用するとマージの最後に「diffstat」が表示されなくなります。

--squash
--no-squash

実際のマージが発生したかのようにワークツリーとインデックスの状態を作成します（マージ情報を除く）が、実際にコミットしたり、HEADを移動したり、GIT_DIR/MERGE_HEAD を記録したりしません（次のgit commitコマンドで マージコミットします）。これにより現在のブランチの上にシングルコミットを作成できます。その効果は別のブランチをマージするのと同じです（オクトパスの場合はそれ以上となります）。

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

「–squash」を使用すると、「-commit」は許可されず、失敗します。

--no-verify

このオプションは「pre-merge」フックと「commit-msg」フックをバイパスします。githooks[5]も参照してください。

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

指定されたマージストラテジーを使用します。トライする順序で指定するため、複数回指定できます。-sオプションがない場合、代わりのストラテジーの組み込みリストが使用されます（シングルヘッドをマージする場合は「git merge-recursive」、それ以外の場合は「git merge-octopus」となります）。

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

マージストラテジー固有のオプションをマージストラテジーにパスします。

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

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

--summary
--no-summary

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

--autostash
--no-autostash

オペレーションを開始する前に一時的なスタッシュエントリを自動的に作成し、オペレーションの終了後に適用します。これはダーティワークツリーでオペレーションを実行できることを意味します。ただし、注意して使用してください。マージが成功した後の最後のスタッシュアプリケーションは重要なコンフリクトを引き起こす可能性があります。

--allow-unrelated-histories

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

-r
--rebase[=false|true|merges|preserve|interactive]

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

mergesに設定されている場合、git rebase --rebase-merges を使用してリベースし、ローカルマー

ジコミットがリベースに含まれるようにします（詳細についてはgit-rebase[1] を参照してください）。

preserveに設定されている場合（mergesを優先して非推奨）、ローカルで作成されたマージコミットがフラット化されないように、--preserve-mergesオプションをgit rebase にパスしてリベースします。

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

interactiveな場合、リベースのインタラクティブモードを有効にします。

git pull をマージする代わりに常に--rebase を使用するようにする場合、git-config[1]のpull.rebase、branch.<name>.rebase 、branch.autoSetupRebase を参照してください。

注記 これは潜在的に危険なオペレーションモードです。それはあなたがすでにその履歴を公開した時に良い前兆ではない履歴を書き換えます。git-rebase[1]を注意深く読んでいない限り、このオプションを使用しないでください。

--no-rebase

以前の「–rebase」を上書きします。

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

--all

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

-a
--append

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

--depth=<depth>

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

--deepen=<depth>

「–depth」に似ていますが、各リモートブランチ履歴の末端からではなく、現在の浅いバウンダリーからのコミット数を指定する点が異なります。

--shallow-since=<date>

浅いリポジトリの履歴を深くするか短くして、<date>以降の到達可能なすべてのコミットを含めます。

--shallow-exclude=<revision>

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

--unshallow

ソースリポジトリが完全な場合、浅いリポジトリを完全なリポジトリに変換し、浅いリポジトリによって課せられるすべての制限を取り除きます。
ソースリポジトリが浅い場合、現在のリポジトリがソースリポジトリと同じ履歴を持つように、可能な限りフェッチします。

--update-shallow

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

--negotiation-tip=<commit|glob>

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

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

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

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

--dry-run

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

-f
--force

「git fetch」を<src>:<dst> 参照スペックとともに使用すると、git-fetch[1]ドキュメントの<refspec>の部分で説明されているように、ローカルブランチの更新を拒否する場合があります。 このオプションはそのチェックを上書きします。

-k
--keep

ダウンロードしたパックを保管します。

-p
--prune

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

--no-tags

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

--refmap=<refspec>

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

-t
--tags

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

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

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

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

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

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

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

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

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

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

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

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

注記 複数の<refspec>を「gitpull」コマンドラインに直接一覧表示することと<repository>の構成に複数のremote.<repository>.fetch エントリを含めることと、明示的な<refspec>パラメーターなしでgitpullコマンドを実行することには違いがあります。コマンドラインに明示的にリストされている<refspec>はフェッチ後に常に現在のブランチにマージされます。つまり複数のリモート参照をリストする場合、「gitpull」はオクトパスマージを作成します。一方、コマンドラインに明示的な<refspec>パラメーターをリストしない場合、「git pull」はremote.<repository>.fetch 構成で見つかったすべての<refspec>をフェッチし、現在のブランチから見つけることができる最初の<refspecのみをマージします。これはリモート参照からオクトパスを作成することはめったに行われないためですが、複数のリモートヘッドを一度に追跡して、複数のリモートヘッドをフェッチすると便利なことがよくあります。

GITのURL

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

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

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

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

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

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

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

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

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

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

Gitでもネイティブにサポートされているローカルリポジトリの場合、次のシンタックスを使用できます。

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

これらの2つのシンタックスは前者が「–local」オプションを意味するクローン作成の場合を除いてほとんど同等です。詳細についてはgit-clone[1]を参照してください。

「git clone」、「git fetch」、「git pull」は「git push」ではなく、適切なバンドルファイルも受け入れます。git-bundle[1]を参照してください。
Gitは特定のトランスポートプロトコルの処理方法を知らない場合、「remote- <transport>」リモートヘルパー（存在する場合）を使用しようとします。リモートヘルパーを明示的に要求するには次のシンタックスを使用できます。

  • <transport>::<address>

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

同様の名前のリモートリポジトリが多数あり、それらに異なるフォーマットを使用する場合（使用するURLが機能するURLに書き換えられるように）、次のフォーマットの構成セクションを作成できます。

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

例えば、次のような場合です。

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

「work：repo.git」や「host.xz：/path/to/repo.git」のようなURLはURLが「git：//git.host.xz/repo.git」になるコンテキストで書き換えられます。

プッシュ専用のURLを書き換えたい場合は次の形式の構成セクションを作成できます。

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

例えば、次のような場合です。

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

「git：//example.org/path/to/repo.git」のようなURLはプッシュの場合は「ssh：//example.org/path/to/repo.git」に書き換えられますが、プルは引き続き オリジナルのURLとなっています。

リモート

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

  • Git構成ファイル内のリモートである$GIT_DIR/config
  • $GIT_DIR/remotesディレクトリ内のファイル
  • $GIT_DIR/branches ディレクトリ内のファイル

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

構成ファイルでの名付けられたリモート

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

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

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

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

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

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

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

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

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

<url>#<head>

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

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

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

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

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

HEAD:refs/heads/<head>

マージストラテジー

マージメカニズム（git merge およびgit pull コマンド）を使用すると、-sオプションを使用してバックエンドのマージストラテジーを選択できます。一部のストラテジーでは独自のオプションを使用することもできます。これはgit merge および/もしくは git pullに-X<option> 引数を指定することでパスすることができます。

resolve

これは3方向マージアルゴリズムを使用して、2つのヘッド（つまり現在のブランチとプルした別のブランチ）のみを解決できます。交差するマージのあいまいさを注意深く検出しようとし、一般的に安全で高速であると見なされています。

recursive

これは3方向マージアルゴリズムを使用して2つのヘッドのみを解決できます。3方向マージに使用できる共通の祖先が複数ある場合、共通の祖先のマージされたツリーを作成し、それを3方向マージの参照ツリーとして使用します。これによりLinux 2.6カーネル開発履歴から取得した実際のマージコミットで実行されたテストによって、ミスマージを引き起こすことなく、マージのコンフリクトが少なくなることが報告されています。さらにこれは名前変更を含むマージを検出して処理できますが、現在、検出されたコピーを利用することはできません。これは1つのブランチをプルまたはマージするときのデフォルトのマージストラテジーです。

再帰的ストラテジーでは次のオプションを選択できます。

ours

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

これを他のツリーに何が含まれているのかをまったく調べないマージストラテジーと混同すべきではありません。それは他のツリーが行ったすべてを破棄し、「ours」履歴にはその中で起こったすべてが含まれていると宣言しています。

theirs

これは「ours」の反対のことです。「ours」 とは異なり、このマージオプションは「theirs」のマージストラテジーはないことに注意してください。

patience

このオプションを使用すると「merge-recursive」は重要でない一致するライン（例えば、別個の関数からの中括弧）が原因で発生することがある誤マージを回避するために、時間を使います。マージするブランチが大きく分岐している場合に使用します。git-diff[1] --patienceも参照してください。

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

異なる差分アルゴリズムを使用するように「merge-recursive」に指示します。これにより重要でない一致するライン（個別の関数からの中括弧など）が原因で発生するミスマージを回避できます。git-diff[1] の--diff-algorithmも参照してください。

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

  • 「their」バージョンが行に空白の変更のみを導入する場合、「our」のバージョンが使用されます。
  • 「our」バージョンで空白の変更が導入されていますが、「their」バージョンに大幅な変更が含まれている場合、「their」バージョンが使用されます。
  • それ以外の場合、マージは通常の方法で進行します。

renormalize

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

no-renormalize

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

no-renames

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

find-renames[=<n>]

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

rename-threshold=<n>

find-renames=<n>の非推奨の同義語となります。

subtree[=<path>]

このオプションはサブツリーストラテジーのより高度な形式であり、このストラテジーはマージ時に2つのツリーを互いに一致させるためにどのようにシフトする必要があるかを推測します。代わりに指定されたパスにプレフィックスが付けられ（または最初から削除され）、2つのツリーの形状が一致するようになります。

octopus

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

ours

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

subtree

これは修正された再帰的ストラテジーです。ツリーAとBをマージする時、BがAのサブツリーに対応する場合、Bは同じレベルのツリーを読み取るのではなく、最初にAのツリー構造に一致するように調整されます。この調整は共通の祖先ツリーに対しても行われます。

3方向マージ（デフォルト、再帰を含む）を使用するストラテジーでは両方のブランチで変更が行われますが、後でブランチの1つで元に戻された場合、その変更はマージされた結果に表示されます。この動作に混乱する人もいます。これは個々のコミットではなく、ヘッドとマージベースのみがマージの実行時に考慮されるために発生します。したがってマージアルゴリズムは元に戻された変更をまったく変更なしと見なし、代わりに変更されたバージョンに置き換えます。

デフォルトの動作

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

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

コマンドラインに参照スペックパラメーターを指定せずにコマンドを実行したときにフェッチする（およびオプションでリモートトラッキングブランチに格納する）リモートブランチを決定するために、remote.<origin>.fetch 構成変数の値を参照し、 存在しない場合、$GIT_DIR/remotes/<origin>;が参照され、そのPull:ラインが使用されます。オプションのセクションで説明されている参照スペック形式に加えて、次のようなグロブの参照スペックを作成できます。

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

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

下位互換性を壊さないためにフェッチ後にマージするリモートブランチを決定するルールは少し複雑です。
明示的な参照スペックがgit pullのコマンドラインで指定された場合、それらはすべてマージされます。

コマンドラインで参照スペックが指定されていない場合、git pullは構成またはGIT_DIR/remotes/<origin>からの参照スペックを使用します。 このような場合、次のルールが適用されます。

  1. 現在のブランチ<name> のbranch.<name>.merge 構成が存在する場合、それはマージされるリモートサイトのブランチの名前です。
  2. 参照スペックがグロブのものである場合、何もマージされません。
  3. それ以外の場合、最初の参照スペックのリモートブランチがマージされます。

例

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

    通常、マージされるブランチはリモートリポジトリのヘッドですが、選択は「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

    プルを試みた結果、複雑なコンフリクトが発生し、最初からやり直したい場合、「gitreset」でリカバリーできます。

セキュリティ

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

既知の攻撃ベクトルは次のとおりです。

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

バグ

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

参照

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

GIT

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

git公式ドキュメント

pull