SYNOPSIS

'git pull' [<options>] [<repository> [<refspec>...]]

DESCRIPTION

リモートリポジトリからの変更を現在のブランチに統合します。

まず、git pull はマージオプションを除く同じ引数で git fetch を実行し、リモートブランチを取得します。次に、どのリモートブランチを統合するかを決定します。引数を指定せずに git pull を実行した場合、これは現在のブランチの upstream がデフォルトになります。そして、そのブランチを現在のブランチに統合します。

リモートブランチを統合するための主なオプションは4つあります:

  1. git pull --ff-only は「fast-forward」更新のみを行います。ローカルブランチがリモートブランチから分岐している場合は失敗します。これがデフォルトです。

  2. git pull --rebase とすると git rebase を実行します。

  3. git pull --no-rebase とすると git merge を実行します。

  4. git pull --squash とすると git merge --squash を実行します。

設定オプション pull.rebase, pull.squash, pull.ff に希望する振る舞いを設定することもできます。

マージまたはリベース中に処理したくないマージコンフリクトが発生した場合は、git merge --abort または git --rebase abort で安全に中止できます。

OPTIONS

<repository>

取得元となる「remote」リポジトリです。これは、URL(下記の GIT URLS セクションを参照)またはリモートの名前(下記の REMOTES セクションを参照)のいずれかです。

デフォルトは、現在のブランチに設定された上流(upstream)、または origin です。 upstream の設定方法の詳細は、下記の UPSTREAM BRANCHES を参照してください。

<refspec>

現在のブランチに取得・統合するブランチまたはその他の参照で、例えば git pull origin main における main です。デフォルトは、現在のブランチに設定された upstream です。

これは、ブランチ、タグ、またはその他の参照の集合を指定できます。完全な構文については、下記の「Options related to fetching」の <refspec> を、git pull がこの引数を使ってどのリモートブランチを統合するかを決定する方法については、下記の DEFAULT BEHAVIOUR を参照してください。

-q
--quiet

このオプションは git-fetch では転送中のレポートを黙らせる為に、 そして git-merge ではマージ中の出力を黙らせるために、 git-fetch と git-merge の両方に渡されます。

-v
--verbose

--verbose を git-fetch と git-merge に渡します。

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

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

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

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

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[<key-id>]
--gpg-sign[=<key-id>]
--no-gpg-sign

結果のマージコミットに GPG 署名します。 <key-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プロジェクトで使用されるものについては、 https://developercertificate.org を参照してください)。 プロジェクトでsignoffがどのように使用されるかを理解するには、 貢献しているプロジェクトのドキュメントまたはリーダーシップ(leadership)を参照してください。

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

--stat
-n
--no-stat

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

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

--compact-summary

マージの最後に compact-summary を表示します。

--squash
--no-squash

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

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

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

マージする場合にのみ役立ちます。

--verify
--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を持つキーで署名されていることを確認します。デフォルトの信頼モデルでは、これは署名キーが信頼できるキーによって署名されていることを意味します。サイド・ブランチの先端コミットが有効なキーで署名されていない場合、マージは中止(abort)されます。

マージする場合にのみ役立ちます。

--summary
--no-summary

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

--autostash
--no-autostash

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

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

remote.<name>.skipFetchAll 設定変数が設定されているリモートを除く、 すべてのリモートを取得(fetch)します。 これは設定変数 fetch.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=<ref>

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

--unshallow

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

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

--update-shallow

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

--negotiation-tip=<commit|glob>

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

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

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

git-config(1) に記載されている fetch.negotiationAlgorithm と push.negotiate 構成変数、および、以下の --negotiate-only オプションも参照してください。

--negotiate-only

サーバーから何も取得せず、代わりに、サーバーと共通している、提供された --negotiation-tip=* 引数の祖先を出力します。

これは --recurse-submodules=[yes|on-demand] と互換性がありません。 内部的には、これは push.negotiate オプションを実装するために使用されます。 git-config(1) を参照してください。

--dry-run

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

--porcelain

スクリプトがパースしやすい形式で標準出力に出力します。 詳細については、git-fetch(1) のセクション OUTPUT を参照してください。

これは --recurse-submodules=[yes|on-demand] とは互換性がなく、 かつ、 fetch.output 設定オプションよりも優先されます。

-f
--force

git fetch が <src>:<dst> な refspec とともに使用される場合、 git-fetch(1) ドキュメントの「<refspec>」のところで説明されているように、 ローカル ・ブランチの更新が拒否されることがあります。 このオプションはそのチェックをオーバーライドします。

-k
--keep

ダウンロードしたパックを保持してください。

--prefetch

構成されたrefspecを変更して、すべての参照を refs/prefetch/ 名前空間に配置します。 git-maintenance(1)の prefetch タスクを参照してください。

-p
--prune

取得する前に、リモートに存在しなくなったリモート追跡参照を削除します。 タグは、デフォルトのタグの自動追跡または --tags オプションのためにのみフェッチされた場合(コマンドラインまたはリモート構成のいずれかで、たとえば、リモートが --mirror オプションでcloneされた場合)、刈り込み(pruning)の対象にはなりません。 ただし、明示的なrefspecが原因でタグが取得された場合、それらも刈り込み(pruning)の対象になります。 --prune-tags を指定することは、タグrefspecを提供するための省略形です。

--no-tags

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

--refmap=<refspec>

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

通常、並列再帰取得(parallel recursive fetches)やマルチリモート取得(multi-remote fetches)の方が高速です。デフォルトでは、取得は並列ではなく順次実行されます。

--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> が指定されている場合、それらはすべてコマンドラインにリストされている順序で相手側に送信されます。 コマンドラインから --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

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

-6
--ipv6

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

<repository>

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

<refspec>

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

<refspec> パラメータの書式は、 オプションのプラス + に続いて、 ソースの <src> 、コロン : 、 宛先の <dst> の順です。 <dst> が空の場合、 コロン(:)は省略できます。 <src> は通常 ref 、 または一連の refs とマッチさせる使用する単一の * を含むグロブ(glob)パターンですが、 フルスペルの16進オブジェクト名にすることもできます。

<refspec> の <src> には、単純なパターンマッチを示すための * が含まれている場合があります。 このような refspec は、 そのパターンに合致する任意の ref とマッチするグロブのように機能します。 このパターンの <refspec> には、 <src> と <dst> の両方の中でたった 1 つだけ * の箇所が必要です。 * をソース(src)から、 マッチしたコンテンツに置き換えることにより、 ref を宛先(dst)にマッピングします。

refspecの前に ^ が付いている場合、それは否定(negative)のrefspecとして解釈されます。このようなrefspecは、取得するrefや更新するローカルrefを指定するのではなく、除外するrefを指定します。 refは、少なくとも1つの肯定(positive)の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であると見なされるかどうかによって異なります。一般に、 push する場合と同じルールが fetch に適用されます。それらが何であるかについては、 git-push(1)の <refspec>... セクションを参照してください。 以下に git fetch に固有の例外ルールを示します:

Gitバージョン2.20までは、 git-push(1) でプッシュする場合とは異なり、 refs/tags/* の更新は、 refspec に + がなくても(または --force 指定が無くても)受け入れられます。 fetch するとき、リモートからのすべてのタグ更新を強制取得としていました。Gitバージョン2.20以降では、 refs/tags/* を更新するための fetch は、 push する場合と同じように機能します。 つまり 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> は、 fetch 後に常に現在のブランチにマージされます。いいかえると、複数のリモートrefをリストする場合 git pull はOctopusマージを作成します。一方、コマンドラインに明示的な <refspec> パラメータをリストしない場合 git pull は remote.<repository>.fetch 構成で見つかったすべての <refspec> を取得し、最初に見つかった <refspec> のみを現在のブランチにマージします。これはリモートrefからOctopusを作成することはめったに行われない為ですが、複数のリモート・ヘッドを追跡するために複数のリモート・ヘッドを一度に取得すると便利なことがよくあります。

GIT URLS

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

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

ネイティブ・トランスポート(つまり、 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 を、絶対パスまたは ./foo:bar として指定して、 ssh url として誤って解釈されないようにすることができます。

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つの構文はほとんど同等ですが、 clone 時には前者が --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> は push でのみ使用されます。 これはオプションであり、 デフォルトは <URL> です。 リモートへの push は、 定義済の全ての pushurls に影響し、 pushurls が定義されていない場合は全ての定義済の URL に影響します。ただし、 複数の url が定義されている場合、 fetch 用は最初に定義された url のみです。

Named file in $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: 行を指定できます。

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>

UPSTREAM BRANCHES

Git のブランチには、 オプションで上流(upstream)のリモート・ブランチを含めることができます。 Git はデフォルトでは、 リモート操作に上流ブランチを使用します。 以下に例を示します:

  • これは、 引数なしの git pull や git fetch のデフォルトです。

  • これは、引数なしの git push のデフォルトです。 たとえば、 branch.<name>.pushRemote 設定を使うことで、 pull 元とは異なるリモートに push することができ、 また、 デフォルトの push.default=simple の場合には、 設定する上流ブランチの名前は必ずローカル・ブランチのいずれかと同一の名前でなければなりません。

  • git checkout や git status など、 さまざまなコマンドは、 あなたがそのブランチをフォークして以降、 現在いるブランチと上流でそれぞれ何コミット追加されたかを教えてくれます。 たとえば、「あなたのブランチと origin/main は分岐しており、 それぞれ 2 個と 3 個の異なるコミットがあります。」("Your branch and origin/main have diverged, and have 2 and 3 different commits each respectively"). と表示されます。

上流(upstream)は .git/config の「remote」フィールドと「merge」フィールドに保存されます。 たとえば、 main の上流が origin/main の場合以下のようになります:

[branch "main"]
   remote = origin
   merge = refs/heads/main

あなたは git Push --set-upstream <remote> <branch> を使用して上流ブランチを明示的に設定できますが、 多くの場合、 Git は自動的に上流を設定します。 以下に例を示します:

  • あなたがリポジトリーのクローンを作成すると、 Git はデフォルト・ブランチの上流を自動的に設定します。

  • あなたが push.autoSetupRemote 設定オプションを設定している場合、 初めてブランチをプッシュするときに、 git Push が自動的に上流を設定します。

  • git checkout <branch> を使用してリモート追跡ブランチをチェックアウトすると、 その名前でローカル・ブランチが自動的に作成され、 上流が上流ブランチに設定されます。

Note
 上流ブランチは、「ブランチの追跡情報を設定する」(set the branch’s tracking information)と言うように、 「追跡情報」(tracking information)と呼ばれることもあります。

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

パスがサブモジュールの場合、マージの片側で使われているサブモジュールコミットが、もう一方の側で使われているサブモジュールコミットの子孫であれば、Git はその子孫へ早送り(fast-forward)しようとします。そうでない場合、Git はこのケースを競合として扱い、解決策として、(存在すれば) 競合しているコミットの子孫であるサブモジュールコミットを提案します。

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

ours

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

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

theirs

これは ours の反対です。ours とは異なり、このマージオプションを混同する 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> の非推奨の同義語。

no-renames

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

histogram

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

patience

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

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

マージ中に別の差分アルゴリズムを使用します。これは、重要でない一致行(異なる関数の中括弧など)が原因で発生するミスマージを回避するのに役立ちます。 git-diff(1) の --diff-algorithm も参照してください。 注意: ort のデフォルトは diff-algorithm=histogram ですが、通常の差分は現在 diff.algorithm 設定のデフォルトに従います。

subtree[=<path>]

このオプションは「subtree」戦略をさらに発展させたもので、2つの木をマージする際に、どのようにずらせば互いにマッチするかを推測するものである。その代わり、指定されたパスは、2つの木の形が一致するように前置される(または、最初から取り除かれる)。

recursive

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

resolve

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

octopus

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

ours

これは任意の数のヘッドを解決しますが、結果として得られるマージのツリーは常に現在のブランチヘッドのツリーであり、他のすべてのブランチからのすべての変更を事実上無視します。これは、サイドブランチの古い開発履歴に取って代わるために使用されることを意図しています。これは ort マージ戦略の -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 が更新されます。 fetch と merge を呼び出すことで同じことができます:

    $ git fetch origin
$ git merge origin/next

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

SECURITY

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

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

  1. 被害者は have 行を送信して、 所有しているオブジェクトのIDを広告(advertise)します。 これらのIDは明示的に共有されることを意図していませんが、 相手(peer)もそれを持っている場合に転送を最適化するために使用できます。 攻撃者は盗むオブジェクトID Xを選択して、 X への ref 送信しますが、 被害者はすでに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