SYNOPSIS

git checkout [-q] [-f] [-m] [<branch>]
git checkout [-q] [-f] [-m] --detach [<branch>]
git checkout [-q] [-f] [-m] [--detach] <commit>
git checkout [-q] [-f] [-m] [[-b|-B|--orphan] <new-branch>] [<start-point>]
git checkout <tree-ish> [--] <pathspec>...
git checkout <tree-ish> --pathspec-from-file=<file> [--pathspec-file-nul]
git checkout [-f|--ours|--theirs|-m|--conflict=<style>] [--] <pathspec>...
git checkout [-f|--ours|--theirs|-m|--conflict=<style>] --pathspec-from-file=<file> [--pathspec-file-nul]
git checkout (-p|--patch) [<tree-ish>] [--] [<pathspec>...]

DESCRIPTION

git checkout には主に 2 つのモードがあります:

  1. ブランチの切り替え は、 git checkout <branch> とします。

  2. ファイルの異なるバージョンを復元 は、 例えば git checkout <commit> <filename> や git checkout <filename> とします。

Git がどちらを実行するかを決定する方法については、 下記「ARGUMENT DISAMBIGUATION」(引数の曖昧さの解消)を参照してください。

git checkout [<branch>]

指定の <branch> に切り替えます。 これにより、 現在のブランチが <branch> に設定され、 あなたの作業ディレクトリ内のファイルがそのブランチの状態に更新されます。 ただし、 <branch> と現在のコミット間で内容が異なるファイルに未コミットの変更(uncommitted changes)が存在する場合、 チェックアウトは失敗します。 未コミットの変更がそれ以外のファイルに存在する場合は、 その変更は保持されたまま切り替えが行われます。

<branch> が見つからないが、 一致する名前を持つ1つのリモート(<remote> と呼びます)に追跡ブランチが存在し、 --no-guess が指定されてい無い場合は、 以下と同等として扱います

$ git checkout -b <branch> --track <remote>/<branch>

git checkout にブランチを指定せずに実行した場合、 現在のブランチの追跡情報(tracking information)を表示する以外に何の効果もありません。

git checkout -b <new-branch> [<start-point>]

新しいブランチ <new-branch> を作成し、 それを <start-point> (デフォルトは現在のコミット)から開始して、 その新しいブランチにチェックアウトします。 --track または --no-track オプションを使うことで、 このブランチの上流(upstream)追跡情報を設定できます。

この操作は、 <new-branch> のチェックアウトにエラーが発生した場合は失敗します。 例えば、 <start-point> コミットをチェックアウトしようとしたときに、 未コミットの変更(uncommitted changes)を上書きしてしまうような場合などです。

git checkout -B <branch> [<start-point>]

-b と同じ振る舞いですが、 ブランチがすでに存在する場合に失敗するのではなく、 <branch> を <start-point> (デフォルトは現在のコミット)にリセット(強制的に移動)します。

git checkout --detach [<branch>]
git checkout [--detach] <commit>

git checkout <branch> と同じ振る舞いですが、 HEAD をブランチではなく直接コミットIDを指すようにします(detached HEAD 状態)。

<branch> を省略すると、 現在のブランチの先端で切り離された HEAD (detached HEAD)になります。

git checkout <tree-ish> [--] <pathspec>...
git checkout <tree-ish> --pathspec-from-file=<file> [--pathspec-file-nul]

指定のコミットやツリーぽい何か(<tree-ish>)から、 指定の ファイル/ディレクトリ(<pathspec>) のバージョンを取り出して作業ツリーに置き換え、 同時にインデックスにも追加します。

たとえば git checkout main file.txt とすると main ブランチの file.txt を現在の作業ツリーとインデックスに復元します。

git checkout [-f|--ours|--theirs|-m|--conflict=<style>] [--] <pathspec>...
git checkout [-f|--ours|--theirs|-m|--conflict=<style>] --pathspec-from-file=<file> [--pathspec-file-nul]

インデックスから指定した ファイル/ディレクトリ のバージョンを作業ツリーに復元します。

たとえば、 コミットをチェックアウトして file.txt を編集し、 それらの変更が間違いであったと判断した場合、 git checkout file.txt は file.txt に対するステージングされていない変更をすべて破棄します。

ファイルにマージ競合があり、 解決済みとしてマークするために git add file.txt (または同等のもの)をまだ実行していない場合、 これは失敗します。 未マージのエントリを無視して強制復元するには -f を使用します。 マージの特定側のバージョンに置き換えるには --ours または --theirs を使用します。 または、 競合した元のマージ結果に置き換える(競合状態を再現)には -m を使用できます。

git checkout (-p|--patch) [<tree-ish>] [--] [<pathspec>...]

これは直前の2つのモードと似ていますが、 対話的なインターフェイスを使って diff の出力を表示し、 結果に取り入れるハンク(hunk)を選択できる点が異なります。 --patch オプションの詳細については下記参照。

OPTIONS

-q
--quiet

静かにします。フィードバックメッセージを抑制します。

--progress
--no-progress

--quiet が指定されていない限り、進行状況は、端末に接続されている場合、デフォルトで標準エラーストリームに報告されます。 このフラグは、 --quiet に関係なく、端末に接続されていない場合でも進行状況のレポートを有効にします。

-f
--force

ブランチを切り替えるとき、インデックスや作業ツリーが HEAD と異なっていても、また、邪魔な未追跡のファイルがあっても進行します。 これは、ローカルの変更や、邪魔な未追跡のファイルやディレクトリを捨てるために使用します。

インデックスからパスをチェックアウトするときは、マージされていないエントリ(unmerged entries)はエラーにせず、代わりに無視します。

--ours
--theirs

インデックスからパスをチェックアウトするときは、ステージ#2(ours)または#3(theirs)でマージされていないパスをチェックアウトしてください。

注意: git rebase と git pull --rebase での作業中、 ours と theirs が入れ替わっているように見える場合があることに注意してください。 --ours は、変更がリベースされるブランチからのバージョンを提供し、 --theirs は、リベースされる作業を保持するブランチからのバージョンを提供します。

これは、リモートでの履歴を共有の正規の履歴として扱うワークフローで rebase が使用されているためです。リベースするブランチで行われた作業を、統合されるサードパーティの作業として扱います。そして、あなたは一時的にリベース中に正規の歴史の管理者の役割を引き受けています。正規の履歴の管理者として、リモートからの履歴を「私たち」(ours; つまり、「私達の共有された正規の履歴」)として表示する必要があり、サイドブランチで行ったことは「彼ら」(theirs;つまり「その上での貢献者の作品」)として表示する必要があります。

-b <new-branch>

<start-point> から開始する <new-branch> という名前の新しいブランチを作成し、 作成したブランチをチェックアウトします。 詳細については git-branch(1) を参照してください。

-B <new-branch>

-b と同じ振る舞いですが、 ブランチがすでに存在する場合に失敗するのではなく、 <branch> を <start-point> (デフォルトは現在のコミット)にリセット(強制的に移動)します。

-t
--track[=(direct|inherit)]

新しいブランチを作成するときは、「上流構成」(upstream configuration)をセットアップします。 詳細については、 git-branch(1)の --track を参照してください。 便宜のため、 -b なしで --track を指定した場合も、 ブランチの作成を意味します。

-b オプションが指定されていない場合、新しいブランチの名前は、対応するリモート用に構成されたrefspecのローカル部分を調べ、最初の部分を * まで削除することにより、リモート追跡ブランチから派生させます。これにより、 origin/hack (または remotes/origin/hack、 あるいは refs/remotes/origin/hack) から分岐するときに、ローカルブランチとして hack を使用するように指示されます。指定された名前にスラッシュ(/)がない場合、または上記の推測の結果が空の名前になる場合、推測は中止されます。このような場合は、 -b を使用して明示的に名前を付けることができます。

--no-track

branch.autoSetupMerge 構成変数がtrueであっても、「上流構成」を設定しないでください。

--guess
--no-guess

<branch> が見つからないが、 一致する名前を持つ1つのリモート(<remote> と呼びます)に追跡ブランチが存在する場合は、 以下と同等として扱います 

$ git checkout -b <branch> --track <remote>/<branch>

ブランチが複数のリモートに存在し、 そのうちの1つが checkout.defaultRemote 構成変数で名付けられている場合、 <branch> がすべてのリモートで一意でなくても、曖昧さ回避の目的でそのブランチを使用します。 例えば checkout.defaultRemote=origin と設定すると、 <branch> があいまいだが origin リモート上に存在する場合、 常にそこからリモート・ブランチをチェックアウトします。 git-config(1) の checkout.defaultRemote も参照してください。

--guess がデフォルトの振る舞いです。無効にするには、 --no-guess を使用します。

デフォルトの振る舞いは、checkout.guess 構成変数を介して設定できます。

-l

新しいブランチのreflogを作成します。詳細については、 git-branch(1) を参照してください。

-d
--detach

ブランチをチェックアウトして作業するのではなく、 検査と破棄可能な実験のためのコミットをチェックアウトします。 これは、 <commit> がブランチ名でない場合の、 git checkout <commit> のデフォルトの動作です。 詳細については、 下記「DETACHED HEAD」セクションを参照してください。

--orphan <new-branch>

<start-point> から開始された <new-branch> という名前の未誕生ブランチ(unborn branch)を新しく作成し、 それに切り替えます。 この新しいブランチで行われた最初のコミットには親がなく、 他のすべてのブランチとコミットから完全に切断された新しい履歴のルートになります。

インデックスと作業ツリーは、以前に git checkout <start-point> を実行した場合と同じように調整されます。これにより、 ルート(root)をコミットするために容易に git commit -a 実行をでき、 <start-point> と同様のパスの組を記録する新しい履歴を開始できます。

これは、ツリーの完全な履歴を公開せずにコミットからツリーを公開する場合に便利です。これは、現在のツリーが「クリーン」であるが、完全な履歴にはプロプライエタリなコードやその他の邪魔なコードが含まれているプロジェクトの、オープンソースブランチを公開するためにこれを行うことができます。

<start-point> のパスとはまったく異なるパスのセットを記録する切断された履歴を開始する場合は、 作業ツリーの最上位から git rm -rf . を実行して、 孤立したブランチ(orphan branch)を作成した直後にインデックスと作業ツリーをクリアする必要があります。 その後に、 新しいファイルを準備したり、 作業ツリーを再作成したり、 他の場所からファイルをコピーしたり、 tarballを抽出したりする準備が整います。

--ignore-skip-worktree-bits

スパース・チェックアウト・モードでは、 git checkout -- <path>... は、 <paths> と一致するエントリと、 $GIT_DIR/info/sparse-checkout のスパースパターン(sparse patterns)のみを更新します。このオプションは、スパースパターンを無視し、 <path>... 内のファイルを追加し直します。

-m
--merge

ブランチを切り替えるときに、現在のブランチと切り替え先のブランチの間で異なる1つ以上のファイルにローカルの変更がある場合、コマンドは、コンテキストでの変更を保持するためにブランチの切り替えを拒否します。ただし、このオプションを使用すると、現在のブランチ、作業ツリーの内容、および新しいブランチの間の3方向のマージを実行してから新しいブランチに移動します。

マージの競合が発生すると、競合するパスのインデックスエントリはマージされないままになります。競合を解決し、解決されたパスを git add（またはマージによってパスが削除される場合は git rm)でマークする必要があります。

インデックスからパスをチェックアウトする場合、このオプションを使用すると、指定したパスで競合するマージを再作成できます。 このオプションは、 ツリーっぽい何か(tree-ish)からパスをチェックアウトする場合には使用できません。

--merge でブランチを切り替えると、ステージされた変更が失われる可能性があります。

--conflict=<style>

上記の --merge オプションと同一ですが、競合するハンクの表示方法を変更し、 merge.conflictStyle 構成変数をオーバーライドします。 可能な値は merge(デフォルト)と diff3 と zdiff3 です。

-p
--patch

<tree-ish> (または指定されていない場合はインデックス)と作業ツリーの間の差分でハンクを対話的に選択します。選択されたハンクは、作業ツリー(<tree-ish> が指定されている場合はインデックス)に逆に適用されます。

これは、 git checkout -p を使用して、現在の作業ツリーから編集を選択的に破棄できることを意味します。 --patch モードの操作方法については、 git-add(1) の「Interactive Mode」セクションを参照してください。

注意: このオプションはデフォルトでオーバーレイなしモードを使用します(--overlay も参照)。現在はオーバーレイモードをサポートしていないことに注意してください。

-U<n>
--unified=<n>

コンテキストの「<n>行」の diff を生成します。 デフォルトは diff.context 、 または構成オプションが設定されていない場合は 3 です。

--inter-hunk-context=<n>

指定の「<number>行」までの diff ハンク間のコンテキストを表示し、 それによって互いに近いハンクを融合します。 デフォルトは diff.interHunkContext 、 または構成オプションが設定されていない場合は 0 です。

--ignore-other-worktrees

git checkout は、 必要なブランチが既にチェックアウト済か、 別のワークツリーによって使用されている場合には拒否されます。 このオプションを使用すると、 とにかくブランチをチェックアウトします。 つまり、 このブランチは1つ以上のワークツリーで使用される可能性があります。

--overwrite-ignore
--no-overwrite-ignore

ブランチを切り替えるときに、無視したファイルを黙って上書きします。これがデフォルトの動作です。新しいブランチに無視したファイルが含まれている場合に操作を中止するには、 --no-overwrite-ignore を使用します。

--recurse-submodules
--no-recurse-submodules

--recurse-submodules を使用すると、スーパープロジェクトに記録されたコミットに従って、すべてのアクティブなサブモジュールのコンテンツが更新されます。サブモジュールのローカル変更が上書きされる場合、 -f が使用されない限り、チェックアウトは失敗します。何も使用されていない場合(または --no-recurse-submodules)、サブモジュールの作業ツリーは更新されません。 git-submodule(1) と同様に、これはサブモジュールの HEAD を切り離します(detach)。

--overlay
--no-overlay

デフォルトのオーバーレイモードでは、 git checkout がインデックスまたは作業ツリーからファイルを削除することはありません。 --no-overlay を指定すると、インデックスと作業ツリーには表示されるが、 <tree-ish> には表示されないファイルが削除され、 <tree-ish> と完全に一致するようになります。

--pathspec-from-file=<file>

パススペックは、コマンドライン引数の代わりに <file> で渡されます。 <file> が正確に - の場合、 標準入力が使用されます。 パススペック要素は、 LFまたは CR/LF で区切られます。 パススペック要素は、構成変数 core.quotePath で説明されているように、 クォートできます(git-config(1) 参照)。 --pathspec-file-nul および グローバル --literal-pathspecs も参照してください。

--pathspec-file-nul

--pathspec-from-file でのみ意味があります。 パススペック要素は NUL 文字で区切られ、 (改行と引用符を含む)他のすべての文字は文字通りに解釈されます。

<branch>

チェックアウトするブランチ。もしそれがブランチ(つまり、 refs/heads/ を前につけたとき、有効なrefである名前)を参照しているなら、そのブランチはチェックアウトされます。そうでない場合、もしそれが有効なコミットを参照していれば、あなたの HEAD は "detached" となり、あなたはもはやどのブランチにもいません(詳しくは以下を参照してください)。

@{-N} 構文を使用して、 git checkout を使って、チェックアウトされた最後からN番目 ブランチ/コミット を参照できます。 @{-1} と同義の - を指定することもできます。

特殊なケースとして、 マージベースが1つしかない場合は、 <rev-a> と <rev-b> のマージベースの省略形として <rev-a>...<rev-b> を使用できます。 最大で <rev-a> と <rev-b> のどちらかを省略できます。 省略した場合のデフォルトは HEAD になります。

<new-branch>

新しいブランチの名前。

<start-point>

新しいブランチを開始するコミットの名前。詳細については、 git-branch(1) を参照してください。デフォルトは HEAD です。

特殊なケースとして、 マージベースが1つしかない場合は、 <rev-a> と <rev-b> のマージベースの省略形として <rev-a>...<rev-b> を使用できます。 最大で <rev-a> と <rev-b> のどちらかを省略できます。 省略した場合のデフォルトは HEAD になります。

<tree-ish>

チェックアウト元のツリー(パスが指定されている場合)。指定しない場合はインデックスが使用されます。

特殊なケースとして、 マージベースが1つしかない場合は、 <rev-a> と <rev-b> のマージベースの省略形として <rev-a>...<rev-b> を使用できます。 最大で <rev-a> と <rev-b> のどちらかを省略できます。 省略した場合のデフォルトは HEAD になります。

--

これ以降の引数をオプションとして解釈しないでください。

<pathspec>...

操作の影響を受けるパスを制限します。

詳細については、 gitglossary(7) の「pathspec」エントリを参照してください。

DETACHED HEAD

HEAD は通常、名前付きブランチ(master など)を指します。一方、各ブランチは特定のコミットを参照します。3つのコミットがあり、そのうちの1つがタグ付けされており、ブランチ master がチェックアウトされているリポジトリを見てみましょう:

           HEAD (refers to branch 'master')
            |
            v
a---b---c  branch 'master' (refers to commit 'c')
    ^
    |
  tag 'v2.0' (refers to commit 'b')

この状態でコミットが作成されると、新しいコミットを参照するようにブランチが更新されます。 具体的には、 git commit は、親がコミット c である新しいコミット d を作成し、ブランチ master を更新して新しい コミット d を参照します。 HEAD は依然としてブランチ master を参照しているので、間接的に コミット d を参照するようになりました:

$ edit; git add; git commit

               HEAD (refers to branch 'master')
                |
                v
a---b---c---d  branch 'master' (refers to commit 'd')
    ^
    |
  tag 'v2.0' (refers to commit 'b')

名前付きブランチの先端にないコミットをチェックアウトしたり、名前付きブランチによって参照されていない新しいコミットを作成したりできると便利な場合があります。 コミット b をチェックアウトするとどうなるか見てみましょう(ここでは、これを行う2つの方法を示します):

$ git checkout v2.0  # or
$ git checkout master^^

   HEAD (refers to commit 'b')
    |
    v
a---b---c---d  branch 'master' (refers to commit 'd')
    ^
    |
  tag 'v2.0' (refers to commit 'b')

どのチェックアウト・コマンドを使用しても、 今や HEAD が直接コミット b を参照することに注目してください。 これは、切り離された HEAD (detached HEAD)状態として知られています。 単に HEAD が名前付きブランチではなく、 特定のコミットを参照することを意味します。 この状態でコミットを作成するとどうなるか見てみましょう:

$ edit; git add; git commit

     HEAD (refers to commit 'e')
      |
      v
      e
     /
a---b---c---d  branch 'master' (refers to commit 'd')
    ^
    |
  tag 'v2.0' (refers to commit 'b')

新しいコミット e がありますが、これは HEAD によってのみ参照されます。 もちろん、この状態でさらに別のコミットを追加できます:

$ edit; git add; git commit

         HEAD (refers to commit 'f')
          |
          v
      e---f
     /
a---b---c---d  branch 'master' (refers to commit 'd')
    ^
    |
  tag 'v2.0' (refers to commit 'b')

実際、私達は通常のGit操作はすべて実行できます。 しかし、ここで私達が master をチェックアウトするとどうなるか見てみましょう:

$ git checkout master

               HEAD (refers to branch 'master')
      e---f     |
     /          v
a---b---c---d  branch 'master' (refers to commit 'd')
    ^
    |
  tag 'v2.0' (refers to commit 'b')

この時点で、コミット f を指しているものは何もないことを理解することが重要です。最終的に、コミット f (および拡張によりコミット e )は、あなたがルーチンのGitガベージコレクションプロセス前に参照を作成しない限り、ルーチンのGitガベージコレクションプロセスによって削除されます。あなたが、まだコミット`f`から離れていない場合、以下のいずれかがそれへの参照を作成します:

$ git checkout -b foo  # or "git switch -c foo"  <1>
$ git branch foo                                 <2>
$ git tag foo                                    <3>

  1. コミット f を参照する新しいブランチ foo を作成し、次にブランチ foo を参照するように`HEAD`を更新します。つまり、このコマンドを実行すると、もはや切り離された`HEAD` (detached HEAD)状態では無くなります。

  2. 同様に、コミット f を参照する新しいブランチ foo を作成しますが、 HEAD は切り離されたままにします。

  3. 新しいタグ foo を作成します。これは、HEAD を切り離したままコミット f を参照します。

私達がうっかり f から離れてしまった場合は、最初にそのオブジェクト名を回復する必要があり(通常は git reflog を使用)、次にそれへの参照を作成できます。 たとえば、 HEAD が参照した最後の2つのコミットを確認するには、以下のいずれかのコマンドを使用できます:

$ git reflog -2 HEAD # or
$ git log -g -2 HEAD

ARGUMENT DISAMBIGUATION(引数の曖昧性解消)

git checkout <something> を実行すると、 Git は <something> がブランチ名なのか、 コミットなのか、 それともファイルのリストなのかを推測しようとします。 そしてその結果に基づいて、 ブランチまたはコミットへの切り替えを行うか、 指定したファイルの復元を行うかを決めます。

曖昧さがある場合、Git は <something> をブランチまたはコミットとして扱いますが、 ダブルダッシュ -- を使うことで、 以下のように Git に「これはファイルやディレクトリのリストだ」と強制的に認識させることができます:

git checkout -- file.txt

EXAMPLES

1. Paths

以下のシーケンスは、 master ブランチをチェックアウトし、 Makefile のリビジョンを2つ戻し、誤って hello.c を削除したので、 hello.c をインデックスから取得します。

$ git checkout master             <1>
$ git checkout master~2 Makefile  <2>
$ rm -f hello.c
$ git checkout hello.c            <3>

  1. ブランチを切り替えます

  2. 別のコミットからファイルを取り出します

  3. インデックスから hello.c を復元します

あなたがインデックスから「すべての」Cソースファイルをチェックアウトしたい場合は、以下のように言うことができます

$ git checkout -- '*.c'

*.c を囲む引用符に注意してください。 ファイル hello.c も、作業ツリーに存在していなくてもチェックアウトされます。これは、(引用符で囲む事で作業ツリーに対してシェル展開するのではなくて)ファイルグロブがインデックスのエントリを照合するために使用されるためです。

hello.c という名前の不幸なブランチがある場合、このステップはそのブランチに切り替えるための指示として混乱を産みます。あなたは代わりに以下のように書く必要があります。

$ git checkout -- hello.c

2. Merge

間違ったブランチで作業した後、正しいブランチへの切り替えは以下を使用して行います:

$ git checkout mytopic

ただし、あなたの「間違った」ブランチと正しい mytopic ブランチは、ローカルで変更したファイルで異なる場合があります。その場合、上記のチェックアウトは以下のように失敗します:

$ git checkout mytopic
error: You have local changes to 'frotz'; not switching branches.

コマンドに -m フラグを指定すると、3方向のマージを試みます:

$ git checkout -m mytopic
Auto-merging frotz

この3方向マージの後、ローカルの変更はインデックスファイルに登録されないため、 git diff は、新しいブランチの先端以降に行った変更を表示します。

3. Merge conflict

-m オプションを使用してブランチを切り替えるときにマージの競合が発生すると、以下のように表示されます:

$ git checkout -m mytopic
Auto-merging frotz
ERROR: Merge conflict in frotz
fatal: merge program failed

この時点で、 git diff は、前の例のようにきれいにマージされた変更と、競合するファイルの変更を示しています。 競合を編集して解決し、通常どおり git add で解決済みのマークを付けます。

$ edit frotz
$ git add frotz

CONFIGURATION

このセクションの以下のすべては、 git-config(1) ドキュメントの抜粋です。 内容は git-config(1) ドキュメント にあるものと同一です:

checkout.defaultRemote

git checkout <something> または git switch <something> を実行し、リモートが1つしかない場合、 origin/<something> のチェックアウトと追跡に暗黙的にフォールバックする可能性があります。 <something> 参照を持つリモートが複数あるとすぐに動作しなくなります。 この設定により、曖昧性解消に関して常に勝利させる優先リモートの名前を設定できます。 典型的なユースケースは、これを origin に設定することです。

現在、これは git-switch(1) と git-checkout(1) によって、 git checkout <something> や git switch <something> が別のリモート上の <something> ブランチをチェックアウトするときに使われています。 また git-worktree(1) は git worktree add がリモート・ブランチを参照しているときに使われています。 この設定は、 将来、 他のチェックアウトのようなコマンドまたは機能に使用される可能性があります。

checkout.guess

git checkout と git switch の、 --guess または --no-guess オプションのデフォルト値を提供します。 git-switch(1) および git-checkout(1) を参照してください。

checkout.workers

作業ツリーを更新するときに使用する並列ワーカーの数。デフォルトは1、つまり順次実行です。 1未満の値に設定すると、Gitは使用可能な論理コアの数と同じ数のワーカーを使用します。 この設定と checkout.thresholdForParallelism は、チェックアウトを実行するすべてのコマンドに影響します。 例えば、 checkout, clone, reset, sparse-checkout, などです。

Note
 並列チェックアウトは通常、 SSD または NFS 上にあるリポジトリーのパフォーマンスを向上させます。 回転するディスクやコアの数が少ないマシン上のリポジトリの場合、 デフォルトのシーケンシャル・チェックアウトの方がパフォーマンスが向上することがよくあります。 リポジトリのサイズと圧縮レベルも、 並列バージョンのパフォーマンスに影響を与える可能性があります。
checkout.thresholdForParallelism

少数のファイルで並列チェックアウトを実行する場合、サブプロセスの生成とプロセス間通信のコストが並列化のメリットを上回る可能性があります。 この設定により、あなたは並列チェックアウトを試行する必要のあるファイルの最小数を定義できます。 デフォルトは100です。

SEE ALSO

git-switch(1), git-restore(1)

GIT

Part of the git(1) suite