SYNOPSIS

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

DESCRIPTION

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

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

<repository> は、 git-fetch(1) に渡されるリモートリポジトリの名前である必要があります。 <refspec>は、任意のリモートref(たとえば、タグの名前)、または、対応するリモート追跡ブランチを持つrefのコレクション(例: refs/heads/*:refs/remotes/origin/* )に名前を付けることができますが、通常はリモートリポジトリ内のブランチの名前です。

<repository>と<branch>のデフォルト値は、 git-branch(1) の --track によって設定された現在のブランチの「リモート」および「マージ」構成から読み取られます。

次の履歴が存在し、現在のブランチが master であると想定します:

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

次に、 git pull は、リモートの master ブランチから変更をフェッチしてリプレイします。これは、ローカルの master (つまり、 E)から分岐してから、 master 上の現在のコミット(C)までです。 そして、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) を使用してそれらを隠しておく前に、作業対象のローカルの変更を取得するのが最善です。

OPTIONS

-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) を参照)。

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

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

Options related to merging

--commit
--no-commit

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

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

注意: 早送り(fast-forward)更新はマージコミットを作成しないため、 --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-only

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

--ff
--no-ff

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

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

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

-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

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

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

--stat
-n
--no-stat

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

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

--squash
--no-squash

(マージ情報を除く)実際のマージが発生したかのように作業ツリーとインデックスの状態を生成しますが、実際にコミットしたり、 HEAD を移動したり、 (次の git commit コマンドでマージコミットを作成する、) $GIT_DIR/MERGE_HEAD を記録したりしないでください。 これにより、現在のブランチの上に単一のコミットを作成できます。その効果は、別のブランチ(または 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

操作を開始する前に一時的なスタッシュエントリを自動的に作成し、それを特別なref MERGE_AUTOSTASH に記録し、操作の終了後にapplyします。 これは、ダーティワークツリーで操作を実行できることを意味します。 ただし、注意して使用してください。マージが成功した後の最後の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 を参照してください。

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

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

Options related to fetching

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

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

--unshallow

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

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

--update-shallow

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

--negotiation-tip=<commit|glob>

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

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

このオプションの引数は、ref名またはrefまたはコミットの(おそらく省略された)SHA-1のグロブである可能性があります。グロブを指定することは、一致するref名ごとに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を変更して、すべてのrefを 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>

コマンドラインにリストされているrefをフェッチするときは、リモートリポジトリの remote.*.fetch 構成変数の値の代わりに、指定されたrefspec(複数回指定可能)を使用してrefをリモート追跡ブランチにマップします。 空の <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) 参照)。

通常、並列再帰フェッチとマルチリモートフェッチの方が高速です。デフォルトでは、フェッチは並列ではなく順次実行されます。

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

-4
--ipv4

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

-6
--ipv6

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

<repository>

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

<refspec>

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

<refspec> パラメータの組織は、オプションのプラス + に続いて ソースの <src> 、コロン : 宛先refの <dst> の順です。 <dst> が空の場合、コロン(:)は省略できます。 <src> は通常、refですが、フルスペルの16進オブジェクト名にすることもできます。

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

refspecの前に ^ が付いている場合、それはネガティブのrefspecとして解釈されます。このようなrefspecは、フェッチするrefや更新するローカルrefを指定するのではなく、除外するrefを指定します。 refは、少なくとも1つのポジティブ(通常)の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であると見なされるかどうかによって異なります。一般に、プッシュする場合と同じルールがフェッチに適用されます。それらが何であるかについては、 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/* 名前空間が非コミットオブジェクトを受け入れるように強制することはないということです。

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

GIT URLS

一般に、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 として指定して、 ssh url として誤って解釈されないようにすることができます。

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が特定のトランスポートプロトコルを処理する方法を知らない場合、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> はプッシュでのみ使用されます。 これはオプションであり、 デフォルトは <URL> です。 リモートへのプッシュは、 定義されているすべての pushurl に影響します。 pushurl が定義されていない場合は、 すべての定義された url に影響します。 ただし、 複数の url が定義されている場合、 Fetch は最初に定義された url からのみ取得します。

Named file in $GIT_DIR/remotes

あなたは、 $GIT_DIR/remotes でファイル名を指定できます。このファイルのURLは、リポジトリへのアクセスに使用されます。コマンドラインでrefspecを指定しない場合、このファイルのrefspecがデフォルトとして使用されます。このファイルの形式は以下のとおりです:

        URL: one of the above URL format
        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>

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」の代わりとして作成されたという事実に由来しています。

ort 戦略は、以下のオプションを取ることができます:

ours

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

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

theirs

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

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

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

no-renormalize

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

find-renames[=<n>]

名前変更(rename)の検出をオンにし、オプションで類似性のしきい値(similarity threshold)を設定します。これがデフォルトです。 これは、 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]

マージ中に別の差分アルゴリズムを使用すると、重要でない一致行(異なる関数の中括弧など)が原因で発生するミスマージを回避できます。 git-diff(1) --diff-algorithm も参照してください。注意: 特に、「ort」は diff-algorithm=histogram を使用しますが、「recursive」はデフォルトで 「diff.algorithm」 設定を使う事に注意して下さい。

no-renames

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

resolve

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

octopus

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

ours

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

subtree

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

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

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 が更新されます。 フェッチとマージを呼び出すことで同じことができます:

    $ git fetch origin
$ git merge origin/next

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

SECURITY

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

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

  1. 被害者は、明示的に共有することを意図していないオブジェクトのIDをアドバタイズする "have" 行を送信しますが、他にもIDを持っている者が居る場合は、転送を最適化するために使用できます。攻撃者はオブジェクトID Xを選択して盗み、refをXに送信しますが、被害者はすでに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