Git

git-checkout は 2.44.0 で最後に更新されました

名前

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 が指定されている場合、<新しいブランチ> が存在しない場合は作成され、存在する場合はリセットされます。これは以下のトランザクショナルな等価物です。

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

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

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

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

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

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

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

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

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

パス指定に一致するファイルの内容を上書きします。<ツリーish>（ほとんどの場合コミット）が指定されていない場合、インデックスの内容で作業ツリーを上書きします。<ツリーish> が指定されている場合、<ツリーish> の内容でインデックスと作業ツリーの両方を上書きします。

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

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

これは前のモードに似ていますが、「diff」出力を表示し、結果に使用するハンクを選択するインタラクティブインターフェースを使用できます。--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（つまり「その上での1人の貢献者の作業」）となります。

-b <新しいブランチ>

<新しいブランチ> という名前の新しいブランチを作成し、<開始点> で開始し、結果のブランチをチェックアウトします。git-branch[1] を参照してください。

-B <新しいブランチ>

ブランチ <新しいブランチ> を作成し、<開始点> で開始します。すでに存在する場合は、<開始点> にリセットします。そして、結果のブランチをチェックアウトします。これは、「git branch」を「-f」で実行し、そのブランチの「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*リモートに存在する場合は、常にそこからリモートブランチをチェックアウトします。checkout.defaultRemoteについては、git-config[1]も参照してください。

--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>という名前の新しい未作成ブランチを作成して切り替えます。この新しいブランチで行われる最初のコミットには親がなく、他のすべてのブランチやコミットから完全に切り離された新しい履歴のルートになります。

インデックスと作業ツリーは、以前に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

ブランチを切り替える際に、現在のブランチと切り替えるブランチとの間で異なるファイルにローカルな変更がある場合、変更をコンテキスト内で保持するために、コマンドはブランチの切り替えを拒否します。ただし、このオプションを使用すると、現在のブランチ、作業ツリーの内容、新しいブランチ間の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]の「対話モード」セクションを参照してください。

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

--ignore-other-worktrees

必要なrefが別のワークツリーによって既にチェックアウトされている場合、git checkoutは拒否します。このオプションを使用すると、とにかく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はデタッチされます。

--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は「デタッチ」され、どのブランチにも属さなくなります（詳細については下記を参照）。

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

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

<new-branch>

新しいブランチの名前。

<start-point>

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

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

<tree-ish>

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

--

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

<pathspec>…

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

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

DETACHED HEAD

HEADは通常、名前付きブランチ（例：master）を参照します。一方、各ブランチは特定のコミットを参照します。タグ付きのコミットが3つあり、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状態であることが知られています。これは単に、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からまだ移動していない場合は、これらのいずれかでコミットfへの参照を作成できます。

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

コミットfを参照する新しいブランチfooを作成し、その後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方マージが試行されます。

$ git checkout -m mytopic
Auto-merging frotz

この3方マージの後、ローカルの変更はインデックスファイルに登録されません。そのため、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>参照を持つリモートが2つ以上あるとすぐに機能しなくなります。この設定により、曖昧さを解消する際に常に優先されるリモートの名前を設定できます。一般的なユースケースは、これを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は、チェックアウトを実行するすべてのコマンドに影響します。例：チェックアウト、クローン、リセット、スパースチェックアウトなど。

注：並列チェックアウトは、SSD上またはNFS経由で配置されたリポジトリでは通常、パフォーマンスが向上します。回転ディスク上、またはコア数の少ないマシン上のリポジトリの場合、デフォルトのシーケンシャルチェックアウトの方がパフォーマンスが良いことがよくあります。リポジトリのサイズと圧縮レベルも、並列バージョンのパフォーマンスに影響を与える可能性があります。
checkout.thresholdForParallelism: 少量のファイルで並列チェックアウトを実行する場合、サブプロセスの生成とプロセス間通信のコストが並列化による利点を上回る可能性があります。この設定により、並列チェックアウトを試行するファイルの最小数を定義できます。デフォルトは100です。

git[1]スイートの一部

設定と構成

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

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

ブランチとマージ

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

検査と比較

パッチ

デバッグ

メール

外部システム

サーバー管理

ガイド

管理

内部コマンド

名前

概要

説明