日本語 ▾ トピック ▾ 最新バージョン ▾ git-checkout は 2.50.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 [<branch>]

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

<branch> が見つからないが、完全に1つのリモート (これを <remote> と呼ぶ) に同じ名前の追跡ブランチが存在し、--no-guess が指定されていない場合、以下と同等に扱われます。

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

<branch> を省略することもできます。その場合、コマンドは「現在のブランチをチェックアウトする」に退化します。これは、現在のブランチの追跡情報が存在する場合にのみ表示される、やや高価な副作用を伴う、華麗なノーオペレーションです。

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

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

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

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

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

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

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

これは以前のモードに似ていますが、インタラクティブなインターフェースを使用して「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 (つまり「その上に構築された一人の貢献者の作業」) として表示する必要があります。

-b <new-branch>

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

-B <new-branch>

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

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

新しいブランチを作成する際、「アップストリーム」設定を行います。git-branch[1] の --track を参照してください。

-b オプションが指定されていない場合、新しいブランチの名前は、対応するリモートに設定されたリフスペックのローカル部分を見て、先頭の「*」までの部分を取り除くことで、リモートトラッキングブランチから導き出されます。これにより、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> がすべてのリモートで一意でなくても、そのブランチを曖昧さ解消のために使用します。例えば、<branch> が曖昧だが origin リモートに存在する場合、常にそこからリモートブランチをチェックアウトするように checkout.defaultRemote=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> という名前の新しい無関係なブランチを作成し、それに切り替えます。この新しいブランチで行われる最初のコミットには親がなく、他のすべてのブランチやコミットから完全に切り離された新しい履歴のルートになります。

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

これは、コミットからツリーを公開するが、その完全な履歴を公開したくない場合に役立つことがあります。プロジェクトの現在のツリーは「クリーン」だが、その完全な履歴には独自のコードやその他の制約のあるコードが含まれているような、オープンソースブランチを公開したい場合にこれを行うことができます。

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

--ignore-skip-worktree-bits

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

-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 は拒否します。このオプションを使用すると、それでもブランチをチェックアウトします。つまり、ブランチは複数の作業ツリーで使用できます。

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

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

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

特別なケースとして、<rev-a> と <rev-b> のマージベースが正確に1つだけの場合、<rev-a>...<rev-b> をショートカットとして使用できます。<rev-a> と <rev-b> のうち最大で1つを省略でき、その場合はデフォルトで HEAD になります。

<new-branch>

新しいブランチの名前。

<start-point>

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

特別なケースとして、<rev-a> と <rev-b> のマージベースが正確に1つだけの場合、<rev-a>...<rev-b> をショートカットとして使用できます。<rev-a> と <rev-b> のうち最大で1つを省略でき、その場合はデフォルトで HEAD になります。

<tree-ish>

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

特別なケースとして、<rev-a> と <rev-b> のマージベースが正確に1つだけの場合、<rev-a>...<rev-b> をショートカットとして使用できます。<rev-a> と <rev-b> のうち最大で1つを省略でき、その場合はデフォルトで HEAD になります。

--

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

<pathspec>...

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

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

デタッチされた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 は新しいコミット 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)

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

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

  3. コミット 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)

  1. ブランチを切り替える

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

  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> 参照を持つリモートが複数あると機能しなくなります。この設定により、曖昧さ解消において常に優先されるべきリモートの名前を設定できます。典型的な使用例は、これを 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です。

関連項目

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

GIT

git[1]スイートの一部

scroll-to-top