English ▾ トピック ▾ 最新バージョン ▾ git-pull の最終更新日: 2.50.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) までフェッチしてリプレイし、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-ff と --no-commit を一緒に使用してください。

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

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

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

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

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

結果のマージコミットにGPG署名します。<key-id> 引数はオプションで、コミッターの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 トレーラーを追加します。サインオフの意味は、コミットするプロジェクトによって異なります。例えば、コミッターがプロジェクトのライセンスの下で作業を提出する権利を持っていることを証明したり、Contributor License Agreement (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 の場合、リベースの対話モードを有効にします。

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

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

--atomic

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

--depth=<depth>

各リモートブランチ履歴の先端から指定された数のコミットにフェッチを制限します。--depth=<depth> オプションで git clone によって作成されたシャローリポジトリにフェッチする場合 (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> リファレンスで使用される場合、git-fetch[1] ドキュメントの <refspec> 部分で説明されているように、ローカルブランチの更新を拒否する場合があります。このオプションはこのチェックを上書きします。

-k
--keep

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

--prefetch

設定されたリファレンスを修正し、すべての参照を refs/prefetch/ 名前空間に配置します。git-maintenance[1] の prefetch タスクを参照してください。

-p
--prune

フェッチする前に、リモートに存在しなくなったリモートトラッキング参照を削除します。タグは、デフォルトのタグ自動追跡または --tags オプションによってのみフェッチされた場合、剪定の対象にはなりません。ただし、明示的なリファレンス (コマンドラインまたはリモート設定、例えば --mirror オプションでリモートがクローンされた場合) によってタグがフェッチされた場合、それらも剪定の対象となります。--prune-tags を指定することは、タグのリファレンスを提供する省略形です。

--no-tags

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

--refmap=<refspec>

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

-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を使用して通信するときに、指定された文字列をサーバーに送信します。指定された文字列には、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 URLS セクションを参照) またはリモートの名前 (REMOTES セクションを参照) のいずれかです。

<refspec>

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

<refspec> パラメータの形式は、オプションのプラス + の後にソース <src>、その後にコロン :、その後に宛先 <dst> が続きます。<dst> が空の場合、コロンは省略できます。<src> は通常、参照、または一連の参照に一致するために使用される単一の * を持つグロブパターンですが、完全なスペルを持つ16進オブジェクト名であることもあります。

<refspec> は、単純なパターンマッチを示すために <src> に * を含めることができます。このような refspec は、パターンに一致する任意の ref に一致するグロブのように機能します。パターン <refspec> は、<src> と <dst> の両方に1つだけ * を持たなければなりません。これは、* をソースから一致した内容に置き換えることで、ref を宛先にマップします。

リファレンスが ^ で始まる場合、それは負のリファレンスとして解釈されます。そのようなリファレンスは、どのリファレンスをフェッチするか、またはどのローカルリファレンスを更新するかを指定するのではなく、除外するリファレンスを指定します。リファレンスは、少なくとも1つの正のリファレンスに一致し、かつどの負のリファレンスにも一致しない場合に一致すると見なされます。負のリファレンス自体もパターンリファレンスであることができます。ただし、それらは <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/* への更新はリファレンスに + (または --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/* 名前空間が非コミットオブジェクトを受け入れないことです。

注
 フェッチしたいリモートブランチが定期的に巻き戻され、リベースされることが知られている場合、その新しい先端は以前の先端 (前回フェッチしたときにリモートトラッキングブランチに保存されていたもの) の子孫ではないと予想されます。そのようなブランチには、非 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>

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がネイティブにサポートしているローカルリポジトリの場合、以下の構文が使用できます。

  • /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> です。リモートへのプッシュは、定義されているすべてのプッシュURL、またはプッシュURLが定義されていない場合は定義されているすべてのURLに影響します。ただし、フェッチは、複数のURLが定義されている場合でも、最初に定義されているURLからのみフェッチします。

$GIT_DIR/remotes 内の名前付きファイル

$GIT_DIR/remotes 内のファイルの名前を指定できます。このファイル内の URL はリポジトリにアクセスするために使用されます。コマンドラインでリファレンスを指定しない場合、このファイル内のリファレンスがデフォルトで使用されます。このファイルは次の形式である必要があります。

	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> はオプションです。

操作に応じて、コマンドラインでリファレンスを指定しない場合、Git は次のいずれかのリファレンスを使用します。<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 オプションでバックエンドのマージ戦略を選択できます。一部の戦略は独自のオプションも受け入れることができ、それらは -X<option> 引数を git merge および/または git pull に与えることで渡すことができます。

ort

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

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

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] の「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> の非推奨の同義語です。

no-renames

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

histogram

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

patience

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

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

マージ中に異なる diff アルゴリズムを使用します。これにより、重要でない一致行 (異なる関数のブレースなど) によって発生する誤ったマージを回避するのに役立ちます。git-diff[1] の --diff-algorithm も参照してください。なお、ort はデフォルトで diff-algorithm=histogram を使用しますが、通常の diff は現在 diff.algorithm 設定に従います。

subtree[=<path>]

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

recursive

これは現在 ort の同義語です。v2.49.0 まで代替の実装でしたが、v2.50.0 で ort を意味するようにリダイレクトされました。以前の再帰戦略は、Git v0.99.9k から v2.33.0 までの2つのヘッドを解決するためのデフォルト戦略でした。

resolve

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

octopus

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

ours

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

subtree

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

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

デフォルトの動作

多くの人がパラメータを指定せずに 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: 行が使用されます。OPTIONS セクションで説明されているリファレンス形式に加えて、次のようなグロビングリファレンスを持つことができます。

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

グロビング refspec は、空ではない 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

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

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

    $ git pull origin next

    これにより、FETCH_HEAD に next のコピーが一時的に残り、リモート追跡ブランチ origin/next が更新されます。同じことは、フェッチとマージを呼び出すことで行うことができます。

    $ git fetch origin
$ git merge origin/next

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

セキュリティ

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

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

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

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

バグ

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

関連項目

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

GIT

git[1]スイートの一部

scroll-to-top