Git

git-checkout は 2.47.1 で最終更新されました

名前

git-checkout - ブランチを切り替える、またはワーキングツリーのファイルを復元する

概要

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] <tree-ish> [--] <pathspec>…
git checkout [-f] <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>…]

説明

ワーキングツリーのファイルをインデックスまたは指定されたツリーのバージョンに更新します。パス指定が与えられなかった場合、git checkout は HEAD も更新し、指定されたブランチを現在のブランチとして設定します。

git checkout [<ブランチ>]

<ブランチ>での作業を準備するために、インデックスとワーキングツリーのファイルを更新し、HEADをそのブランチにポイントして、そのブランチに切り替えます。ワーキングツリー内のファイルに対するローカルな変更は保持され、それらが<ブランチ>にコミットできるようになります。

<ブランチ>が見つからず、ただし完全に一致する名前のトラッキングブランチがちょうど1つのリモート（<リモート>と呼ぶ）に存在し、--no-guessが指定されていない場合、以下と同等に扱われます。

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

<ブランチ>を省略することもできます。その場合、このコマンドは「現在のブランチをチェックアウトする」ことに退化し、これは現在のブランチのトラッキング情報（存在する場合）のみを表示するための、むしろコストのかかる副作用を伴う、飾り立てられた何もしない操作となります。

git checkout -b|-B <新しいブランチ> [<開始点>]

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

-B が指定された場合、<new-branch> は存在しない場合は作成され、そうでない場合はリセットされます。これは、以下のトランザクションと等価です。

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

つまり、"git checkout"が成功しない限り、ブランチはリセット/作成されません（例えば、ブランチが別のワークツリーで使用されている場合、現在のブランチは同じままであるだけでなく、ブランチも開始点にリセットされません）。

git checkout --detach [<ブランチ>]

git checkout [--detach] <コミット>

<コミット>の上で作業するための準備として、HEADをそれにデタッチし（「DETACHED HEAD」セクションを参照）、インデックスとワーキングツリーのファイルを更新します。ワーキングツリー内のファイルへのローカルな変更は保持され、結果として得られるワーキングツリーはコミットに記録された状態とローカルな変更の組み合わせになります。

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

<ブランチ>を省略すると、現在のブランチの先端でHEADがデタッチされます。

git checkout [-f|--ours|--theirs|-m|--conflict=<スタイル>] [<tree-ish>] [--] <パス指定>…

git checkout [-f|--ours|--theirs|-m|--conflict=<スタイル>] [<tree-ish>] --pathspec-from-file=<ファイル> [--pathspec-file-nul]

パス指定に一致するファイルのコンテンツを上書きします。<tree-ish>（ほとんどの場合コミット）が与えられていない場合、ワーキングツリーをインデックスのコンテンツで上書きします。<tree-ish>が与えられている場合、インデックスとワーキングツリーの両方を<tree-ish>のコンテンツで上書きします。

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

git checkout (-p|--patch) [<tree-ish>] [--] [<パス指定>…]

これは前のモードに似ていますが、「差分」出力を表示し、結果にどのハンクを使用するかを選択するためにインタラクティブインターフェースを使用できます。--patch オプションの説明については以下を参照してください。

オプション

-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> から開始し、結果のブランチをチェックアウトします。詳細はgit-branch[1] を参照してください。

-B <新しいブランチ>

<new-branch> を作成し、<start-point> から開始します。すでに存在する場合は、<start-point> にリセットします。そして、結果のブランチをチェックアウトします。これは、"-f" 付きで "git branch" を実行し、その後そのブランチを "git checkout" するのと同等です。詳細は git-branch[1] を参照してください。

-t

--track[=(direct|inherit)]

新しいブランチを作成する際、「アップストリーム」設定を行います。詳細は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>から開始された新しい孤立したブランチを作成し、それに切り替えます。この新しいブランチで行われる最初のコミットは親を持たず、他のすべてのブランチやコミットから完全に分離された新しい履歴のルートになります。

インデックスとワーキングツリーは、以前に git checkout <start-point> を実行したかのように調整されます。これにより、git commit -a を簡単に実行してルートコミットを作成することで、<start-point> に似たパスのセットを記録する新しい履歴を開始できます。

これは、コミットのツリーをその完全な履歴を公開せずに公開したい場合に役立ちます。現在のツリーは「クリーン」だが、その完全な履歴にはプロプライエタリまたはその他の制約のあるコードが含まれているプロジェクトのオープンソースブランチを公開したい場合などに、これを行うことができます。

<start-point>とは完全に異なるパスセットを記録する分離された履歴を開始したい場合は、孤立ブランチを作成した後すぐに、ワーキングツリーのトップレベルからgit rm -rf .を実行してインデックスとワーキングツリーをクリアする必要があります。その後、他の場所からファイルをコピーしたり、tarballを展開したりして、新しいファイルを準備し、ワーキングツリーを再構築する準備が整います。

--ignore-skip-worktree-bits

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

-m

--merge

ブランチを切り替える際、現在のブランチと切り替え先のブランチ間で異なる1つ以上のファイルにローカルな変更がある場合、そのコンテキストでの変更を保持するために、コマンドはブランチの切り替えを拒否します。しかし、このオプションを使用すると、現在のブランチ、ワーキングツリーのコンテンツ、新しいブランチの間で3-wayマージが実行され、新しいブランチに移動します。

マージの競合が発生した場合、競合するパスのインデックスエントリはマージされていないままになり、競合を解決して git add で解決済みのパスをマークする（またはマージの結果パスが削除されるべき場合は git rm を使用する）必要があります。

インデックスからパスをチェックアウトする場合、このオプションは指定されたパスで競合したマージを再作成できるようにします。このオプションは、tree-ishからパスをチェックアウトする場合には使用できません。

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

--conflict=<スタイル>

上記の --merge オプションと同じですが、競合するハンクの表示方法を変更し、merge.conflictStyle 設定変数を上書きします。可能な値は「merge」（デフォルト）、「diff3」、「zdiff3」です。

-p

--patch

<tree-ish> (または指定されていない場合はインデックス) とワーキングツリー間の差分において、ハンクをインタラクティブに選択します。選択されたハンクは、ワーキングツリーに逆方向に適用されます (そして、<tree-ish> が指定されていた場合はインデックスにも適用されます)。

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

このオプションはデフォルトでオーバーレイなしモードを使用しており（--overlay も参照）、現在のところオーバーレイモードはサポートしていません。

--ignore-other-worktrees

目的のブランチがすでにチェックアウトされているか、他のワークツリーで使用されている場合、git checkout は拒否します。このオプションを使用すると、それでもブランチをチェックアウトできます。言い換えれば、そのブランチは複数のワークツリーで使用されることができます。

--overwrite-ignore

--no-overwrite-ignore

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

--recurse-submodules

--no-recurse-submodules

--recurse-submodules を使用すると、スーパープロジェクトに記録されたコミットに従って、すべてのアクティブなサブモジュールのコンテンツが更新されます。サブモジュール内のローカルな変更が上書きされる場合、-f が使用されない限り、チェックアウトは失敗します。何も指定しない（または --no-recurse-submodules を使用する）場合、サブモジュールのワーキングツリーは更新されません。git-submodule[1] と同様に、これによりサブモジュールの HEAD がデタッチされます。

--overlay

--no-overlay

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

--pathspec-from-file=<ファイル>

パス指定はコマンドライン引数の代わりに<file>で渡されます。<file>が正確に-の場合、標準入力が使用されます。パス指定要素はLFまたはCR/LFで区切られます。パス指定要素は、設定変数core.quotePathについて説明されているように引用符で囲むことができます（git-config[1]を参照）。--pathspec-file-nulおよびグローバルな--literal-pathspecsも参照してください。

--pathspec-file-nul

--pathspec-from-file と一緒に使用する場合のみ意味があります。パス指定要素は NUL 文字で区切られ、他のすべての文字は文字通りに解釈されます (改行や引用符を含む)。

<ブランチ>

チェックアウトするブランチ。ブランチ（つまり、「refs/heads/」を前に付けたときに有効な参照となる名前）を参照している場合、そのブランチがチェックアウトされます。そうでない場合、有効なコミットを参照している場合、HEAD は「デタッチ」され、どのブランチにも属さなくなります（詳細については以下を参照してください）。

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

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

<新しいブランチ>

新しいブランチの名前。

<開始点>

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

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

<tree-ish>

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

--

これ以上引数をオプションとして解釈しません。

<パス指定>…

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

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

デタッチされたHEAD

HEADは通常、名前付きブランチ（例：master）を指します。一方、各ブランチは特定のコミットを指します。タグ付けされたコミットが1つあり、masterブランチがチェックアウトされている3つのコミットを持つリポジトリを見てみましょう。

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

この状態でコミットが作成されると、ブランチは新しいコミットを参照するように更新されます。具体的には、git commit は新しいコミット d を作成し、その親はコミット c であり、その後ブランチ 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 状態」と呼びます。これは、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ガーベージコレクションプロセスによって削除されます。まだコミット f から移動していない場合、次のいずれかのコマンドで参照が作成されます。

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

新しいブランチ foo を作成し、それはコミット f を参照し、その後 HEAD を更新してブランチ foo を参照するようにします。言い換えれば、このコマンドの後はデタッチされた HEAD 状態ではなくなります。
同様に、コミット f を参照する新しいブランチ foo を作成しますが、HEAD はデタッチされたままになります。
コミット f を参照する新しいタグ foo を作成し、HEAD はデタッチされたままになります。

コミット f から移動してしまった場合は、まずそのオブジェクト名を取得し（通常は git reflog を使用して）、それから参照を作成する必要があります。例えば、HEAD が最後に参照した2つのコミットを見るには、これらのコマンドのいずれかを使用できます。

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

引数の曖昧性解消

1つの引数しか与えられず、それが -- でない場合（例： git checkout abc）、かつその引数が有効な <tree-ish>（例：ブランチ abc が存在する場合）と有効な <pathspec>（例：ファイルまたはディレクトリの名前が「abc」である場合）の両方である場合、Gitは通常、曖昧さを解消するよう求めます。しかし、ブランチのチェックアウトは非常に一般的な操作であるため、そのような状況では git checkout abc は「abc」を <tree-ish> として扱います。インデックスからこれらのパスをチェックアウトしたい場合は、git checkout -- <pathspec> を使用してください。

例

1. パス

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

$ git checkout master             (1)
$ git checkout master~2 Makefile  (2)
$ rm -f hello.c
$ git checkout hello.c            (3)

ブランチを切り替える
別のコミットからファイルを取り出す
インデックスから hello.c を復元する

インデックスから すべて のCソースファイルをチェックアウトしたい場合は、次のように記述できます。

$ git checkout -- '*.c'

*.c の周りの引用符に注意してください。ファイル hello.c は、ワーキングツリーに存在しなくなったとしてもチェックアウトされます。これは、ファイルグロビングがインデックス内のエントリ（シェルによるワーキングツリーではない）に一致するために使用されるためです。

もし不運にも hello.c という名前のブランチがあった場合、この手順はそのブランチへの切り替え命令と混同されます。代わりに、次のように記述する必要があります。

$ git checkout -- hello.c

2. マージ

間違ったブランチで作業した後、正しいブランチに切り替えるには次のようにします。

$ git checkout mytopic

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

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

コマンドに -m フラグを渡すと、3-wayマージが試行されます。

$ git checkout -m mytopic
Auto-merging frotz

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

3. マージの競合

-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

設定

このセクションのこれ以降のすべては、git-config[1] のドキュメントから選択的に含まれています。内容はそちらと同じです。

checkout.defaultRemote: git checkout <something> または git switch <something> を実行し、リモートが1つしかない場合、暗黙的に origin/<something> などのチェックアウトとトラッキングにフォールバックすることがあります。これは、<something> 参照を持つリモートが複数あるとすぐに機能しなくなります。この設定により、あいまいさの解消において常に優先される推奨リモートの名前を設定できます。一般的な使用例は、これを origin に設定することです。

現在、これは git checkout <something> または git switch <something> が別のリモートの <something> ブランチをチェックアウトする場合に git-switch[1] と git-checkout[1] で使用され、git worktree add がリモートブランチを参照する場合に git-worktree[1] で使用されます。この設定は、将来的に他のチェックアウトに似たコマンドや機能で使用される可能性があります。
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です。

参照

git-switch[1], git-restore[1]

git[1] スイートの一部

セットアップと設定

プロジェクトの取得と作成

基本的なスナップショット

ブランチとマージ

プロジェクトの共有と更新

検査と比較

パッチ適用

デバッグ

メール

外部システム

サーバー管理

ガイド

管理

プラミングコマンド

名前

概要

説明