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 [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] [--] <pathspec>…
git checkout [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] --pathspec-from-file=<file> [--pathspec-file-nul]
git checkout (-p|--patch) [<tree-ish>] [--] [<pathspec>…]

DESCRIPTION

作業ツリー内のファイルを、インデックスまたは指定されたツリー内のバージョンと一致するように更新します。 pathspecが指定されていない場合、 git checkout は HEAD も更新して、指定されたブランチを現在のブランチとして設定します。

git checkout [<branch>]

<branch> での作業の準備をするために、インデックスと作業ツリーのファイルを更新し、 HEAD をブランチに向けることで、<branch> に切り替わります。作業ツリーのファイルに対するローカルな変更は保持され、 <branch> にコミットできるようになります。

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

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

あなたは <branch> を省略できます。この場合、コマンドは「現在のブランチをチェックアウトする」ことになり、(もし存在すれば)現在のブランチの追跡情報だけを表示するという、かなり高価な副作用のある、見栄えの良いノー・オペレーション(no-op)となります。

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

-b を指定すると、git-branch(1) が呼び出されてチェックアウトされたかのように新しいブランチが作成されます。 この場合、 git branch に渡される --track または --no-track オプションを使用できます。便利にするために -b のない --track はブランチの作成を意味します。後述の --track の説明を参照してください。

-B を指定すると、存在しない場合は <new-branch> が作成されます。 それ以外の場合はリセットされます。これは、以下の取引(transaction)と同等です

$ git branch -f <branch> [<start-point>]
$ git checkout <branch>

つまり、 git checkout が成功しない限り、ブランチは リセット/作成 されません。

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

<commit> の上で作業する準備をします。その上で、 HEAD を切り離し(「DETACHED HEAD」セクションを参照)、作業ツリーのインデックスとファイルを更新します。 作業ツリー内のファイルへのローカルの変更は保持されるため、結果の作業ツリーは、コミットに記録された状態と、ローカルの変更になります。

<commit> 引数がブランチ名の場合、 --detach オプションを使用して、ブランチの先端にある HEAD をデタッチできます(git checkout <branch> は、 HEAD をデタッチせずにそのブランチをチェックアウトします)。

<branch> を省略すると、現在のブランチの先端にある HEAD が切り離されます。

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

pathspecにマッチするファイルの内容を上書きします。 <tree-ish> (ほとんどの場合コミット)が指定されていない場合は、作業ツリーをインデックスの内容で上書きします。 <tree-ish> が指定された場合、インデックスと作業ツリーの両方を <tree-ish> の内容で上書きします。

以前にマージに失敗したため、インデックスがマージされていないエントリを含んでいる可能性があります。デフォルトでは、インデックスからそのようなエントリをチェックアウトしようとすると、チェックアウト操作は失敗し、何もチェックアウトされません。 -f を使用すると、これらのマージされていないエントリは無視されます。マージの特定の側からのコンテンツは、 --ours または --theirs を使用してインデックスからチェックアウトできます。 -m を使用すると、作業ツリーファイルに加えられた変更を破棄して、元の競合するマージ結果を再作成できます。

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

これは以前のモードと似ていますが、対話的インターフェイスを使用して「diff」出力を表示し、その結果において使用するハンクを選択できます。 --patch オプションの説明については、以下を参照してください。

OPTIONS

-q
--quiet

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

--progress
--no-progress

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

-f
--force

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

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

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

ブランチ <new-branch> を作成し、 そのブランチを <start-point> から開始します。 すでに存在する場合は、 そのブランチを <start-point> に再設定します。 そして、 結果のブランチをチェックアウトします。 これは、 -f を伴って git branch を実行し、続いてそのブランチに対して git checkout を実行するのと同じです。 詳細については、 git-branch(1) を参照してください。

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

新しいブランチを作成するときは、「アップストリーム構成」(upstream configuration)をセットアップします。 詳細については、 git-branch(1)の --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> という名前の新しい「孤立した」(orphan) ブランチを作成し、それに切り替えます。 この新しいブランチで行われた最初のコミットには親がなく、他のすべてのブランチとコミットから完全に切断された新しい履歴のルートになります。

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

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

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

--ignore-skip-worktree-bits

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

-m
--merge

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

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

インデックスからパスをチェックアウトする場合、このオプションを使用すると、指定したパスで競合するマージを再作成できます。

--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 も参照)。現在はオーバーレイモードをサポートしていないことに注意してください。

--ignore-other-worktrees

git checkout は、必要なrefが別のワークツリーによってすでにチェックアウトされている場合に拒否します。このオプションを使用すると、とにかくrefをチェックアウトできます。つまり、refを複数のワークツリーで保持できます。

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

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

--pathspec-file-nul

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

<branch>

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

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

特殊なケースとして、マージベースが1つしかない場合は、 A と B のマージベースのショートカットとして A...B を使用できます。 最大で A と B のどちらかを省略できます。その場合、デフォルトで HEAD になります。

<new-branch>

新しいブランチの名前。

<start-point>

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

特殊なケースとして、マージベースが1つしかない場合は、 A と B のマージベースのショートカットとして A...B を使用できます。 最大で A と B のどちらかを省略できます。その場合、デフォルトで HEAD になります。

<tree-ish>

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

特殊なケースとして、マージベースが1つしかない場合は、 A と B のマージベースのショートカットとして A...B を使用できます。 最大で A と 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')

使用するcheckoutコマンドに関係なく、 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(引数の曖昧性解消)

与えられた引数が1つだけで、それが -- ではない場合(例: git checkout abc)や、引数が有効な <tree-ish> (例:ブランチ abc が存在する)や、有効な <pathspec> (たとえば、 "abc" という名前のファイルまたはディレクトリが存在する)な場合、Gitは通常、明確にするように求めます。ただし、ブランチのチェックアウトは非常に一般的な操作であるため、このような状況では、 git checkout abc は "abc" を <tree-ish> と見なします。これらのパスをインデックスからチェックアウトする場合は、 git checkout -- <pathspec> を使用します。

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, などです。

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

checkout.thresholdForParallelism

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

SEE ALSO

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

GIT

Part of the git(1) suite