git switchとcheckoutの違い｜切り替え・作成・restore

git switchとcheckoutの違いは、checkoutが「ブランチの切り替え」と「ファイルを元に戻す」の2役を1つで担うのに対し、switchはブランチの切り替えだけ、restoreはファイルを戻すだけ、と役割が分かれている点です。 git switch と git restore は Git 2.23 で追加されたコマンドで、git checkout もこれまでどおり使えます。どちらを使っても結果は同じなので、「これから覚えるなら switch／restore、既存の手順書は checkout のままでも動く」と考えれば十分です。

この記事では、checkoutの用途ごとに「旧コマンド→新コマンド」をそのままコピペできる対応表にまとめました。さらに、未コミットの変更があって切り替えられないエラー、ブランチ名とファイル名が同じときに checkout がどちらに解釈するか、detached HEAD の警告文、restore --staged／--source／--worktree で作業ツリーとインデックスがどう変わるかを、すべて git 2.43.0 で実行した出力つきで確認していきます。オプションの仕様は公式ドキュメント（git-switch、git-restore）を今回開いて確認しました。

checkout→switch／restore 対応早見表

左の列を右の列に置き換えれば、同じ結果になります。

git switchとcheckoutの違いを整理する

checkoutは2つの仕事を持っている

git checkout は、引数の形によって働きが変わります。

1つめと3つめは -- の有無しか違いませんが、前者は「場所を移る」、後者は「編集内容を消す」という性質の異なる操作です。この2つを別のコマンドに分けたのが switch と restore です。

flowchart LR
    C[git checkout] --> S[git switch<br>ブランチを切り替える・作る]
    C --> R[git restore<br>ファイルを元に戻す]
    S --> H[HEADが動く]
    R --> W[作業ツリー／インデックスが変わる]

3つのコマンドの比較表

switch は「コミットへ直接移動するなら --detach を明示する」、restore は「ファイルしか触らない」という作りになっており、打ち間違えたときに意図と違う操作になりにくいのが特長です。公式ドキュメントには以前「実験的」という注記がありましたが、今回開いた git-switch と git-restore のページ（表示は 2.5x 系）にはその注記は見当たりませんでした。

どちらを使うかの判断表

ブランチを切り替える・作る（git switch）

以降は、main・develop の2ブランチと、リモートに feature/search があるリポジトリで実行した結果です。

切り替える・直前のブランチに戻る

$ git switch develop
Switched to branch 'develop'

$ git switch -
Switched to branch 'main'
Your branch is up to date with 'origin/main'.

git switch - は「直前に居たブランチ」へ戻るショートカットです（cd - と同じ発想）。2つのブランチを行き来しながら確認するときに重宝します。

作って切り替える（-c）

$ git switch -c feature/cart
Switched to a new branch 'feature/cart'

同じ名前のブランチが既にあるときは、作成されずにメッセージが出ます。

$ git switch -c feature/cart
fatal: a branch named 'feature/cart' already exists

既存のブランチを指定した位置から作り直したいときは -C（大文字）を使います。-C はブランチの位置を付け替えるため、そのブランチにしか無いコミットがある場合は先に確認してから実行します。

$ git switch -C tmp1 main
Reset branch 'tmp1'

起点を指定する書き方は、ブランチ名の後ろにコミットやブランチを並べるだけです。

$ git switch -c from-dev develop
Switched to a new branch 'from-dev'

リモートのブランチを追跡して切り替える

ローカルに無く、リモートに同名のブランチが1つだけある場合、git switch <名前> だけで追跡ブランチが作られます（--guess が既定で有効なため）。

$ git switch feature/search
Switched to a new branch 'feature/search'
branch 'feature/search' set up to track 'origin/feature/search'.

ローカルの名前を変えたいときは -c と --track を組み合わせます。

$ git switch -c local-search --track origin/feature/search
Switched to a new branch 'local-search'
branch 'local-search' set up to track 'origin/feature/search'.

一方、origin/develop のようにリモート追跡ブランチそのものを指定すると、switch はブランチではないと判断して止まります。

$ git switch origin/develop
fatal: a branch is expected, got remote branch 'origin/develop'
hint: If you want to detach HEAD at the commit, try again with the --detach option.

git switch develop と origin/ を外して実行すれば、追跡ブランチ付きで切り替わります。

switchのオプション一覧

切り替えられないエラーを再現して直す

未コミットの変更があるとき

main で app.txt を編集したまま、app.txt の内容が異なる develop へ切り替えようとすると、次のエラーになります。switch でも checkout でもメッセージは同じでした（文中の「by checkout」も共通です）。

$ git switch develop
error: Your local changes to the following files would be overwritten by checkout:
    app.txt
Please commit your changes or stash them before you switch branches.
Aborting

Git は、切り替えによって編集中の内容が上書きされる場合に限って止めてくれます。切り替え先と内容が同じファイルの変更であれば、変更を持ったまま切り替わります。次の例では README.md を編集していますが、main と develop で README.md に差がないため、そのまま移動できました。

$ git switch develop
Switched to branch 'develop'
M   README.md
$ git status -s
 M README.md

M README.md は「この変更を持ってきました」という表示です。

直し方は4通り

stash を使った流れを実行した結果です。

$ git stash
Saved working directory and index state WIP on main: dfbd774 second
$ git switch develop
Switched to branch 'develop'
$ git switch main
Switched to branch 'main'
Your branch is up to date with 'origin/main'.
$ git stash pop
On branch main
Your branch is up to date with 'origin/main'.

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
    modified:   app.txt

no changes added to commit (use "git add" and/or "git commit -a")
Dropped refs/stash@{0} (cbb867235b8583ff238628bdb2295e08ebf161e3)

--discard-changes と git restore . は編集内容が消える操作です。実行前に git diff で内容を確認しておくと安心です。

そのほかのエラーと対処

過去のコミットへ移動する（detached HEAD）

switchでは--detachを明示する

detached HEAD とは、HEAD がブランチではなくコミットを直接指している状態です。過去の状態を確認したり、ある時点でビルドしてみたりするときに使います。switch ではコミットを指定するだけでは移動せず、--detach を付ける必要があります。

$ git switch HEAD~1
fatal: a branch is expected, got commit 'HEAD~1'
hint: If you want to detach HEAD at the commit, try again with the --detach option.

$ git switch --detach HEAD~1
HEAD is now at 945ef5a first

$ git status
HEAD detached at 945ef5a
nothing to commit, working tree clean

checkout は --detach なしで移動でき、代わりに長めの案内文が表示されます。

$ git checkout HEAD~1
Note: switching to 'HEAD~1'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:

  git switch -c <new-branch-name>

Or undo this operation with:

  git switch -

Turn off this advice by setting config variable advice.detachedHead to false

HEAD is now at 945ef5a first

checkout の案内文の中でも、ブランチ作成の例として git switch -c が紹介されています。

detached HEADでコミットしたあとブランチに戻ると

detached HEAD の状態でもコミットはできます。ただし、そのコミットはどのブランチにも属していないため、ブランチへ戻るときに次の案内が出ます。

$ git switch main
Warning: you are leaving 1 commit behind, not connected to
any of your branches:

  5ae0dd5 experiment

If you want to keep it by creating a new branch, this may be a good time
to do so with:

 git branch <new-branch-name> 5ae0dd5

Switched to branch 'main'
Your branch is up to date with 'origin/main'.

残したいコミットがあるなら、表示されたコマンド（git branch <名前> 5ae0dd5）でブランチを付ければ保持できます。 移動する前に気付いた場合は、その場で git switch -c <名前> を実行するのが手軽です。

$ git switch -c keep-it
Switched to a new branch 'keep-it'

ブランチ名とファイル名が同じときの曖昧さ

checkout は引数を「ブランチかもしれないし、ファイルかもしれない」と解釈します。名前が重なったときの動きを2つのケースで確かめました。

ケース1：ローカルブランチ docs とファイル docs がある

docs というファイルを編集した状態で、ファイルを元に戻すつもりで git checkout docs を実行します。

$ git checkout docs
Switched to branch 'docs'
M   docs
$ cat docs
docs file
edit

ブランチとして解釈され、ブランチが切り替わりました。ファイルの編集は残ったままです。 ファイルを戻すには -- で「ここから後ろはファイル名」と伝える必要があります。

$ git checkout -- docs
$ git status -s
（出力なし＝変更が取り消された）

ケース2：リモートブランチ tools とフォルダ tools がある

ローカルブランチは無く、リモートに origin/tools があり、作業ツリーに tools フォルダがある場合は、Git 自身が判断できずに止まります。

$ git checkout tools
fatal: 'tools' could be both a local file and a tracking branch.
Please use -- (and optionally --no-guess) to disambiguate

$ git checkout tools --
Switched to a new branch 'tools'
branch 'tools' set up to track 'origin/tools'.

tools -- と書けばブランチ、-- tools と書けばファイル、という区別です。

switch／restoreなら迷わない

同じ状況で git switch tools を実行すると、迷わずブランチとして処理されました。

$ git switch tools
Switched to branch 'tools'
Your branch is up to date with 'origin/tools'.

switch はブランチしか、restore はファイルしか受け取らないため、-- の位置を気にする必要がなくなります。 docs、test、build、tools のようにフォルダ名と重なりやすいブランチ名を使うチームでは、この差が効いてきます。

ファイルを元に戻す（git restore）

復元元と復元先の考え方

restore を理解する鍵は、「どこから（復元元）」「どこへ（復元先）」の2点です。Git には作業ツリー（いま見えているファイル）、インデックス（git add した内容、ステージ）、HEAD（最後のコミット）の3つの場所があります。

flowchart LR
    HEAD[HEAD<br>最後のコミット] -- "restore --staged" --> IDX[インデックス<br>ステージ]
    IDX -- "restore（指定なし）" --> WT[作業ツリー]
    SRC[--source で指定したコミット] -- "restore --source" --> WT

git statusの記号の読み方

以降の実行結果では git status -s（短い表示）を使います。左の列がインデックス、右の列が作業ツリーの状態です。

--staged：addを取り消す

app.txt を編集して git add し、さらに追加で編集した状態から始めます。

$ git status -s
 M README.md
MM app.txt

$ git restore --staged app.txt
$ git status -s
 M README.md
 M app.txt

MM が M に変わりました。ステージだけが取り消され、ファイルの編集内容はそのまま残っています。 以前の git reset HEAD app.txt と同じ結果です。

指定なし（--worktree）：編集を取り消す

続けて、作業ツリーの変更を取り消します。

$ git restore app.txt
$ git status -s
 M README.md

app.txt の行が消え、インデックスの内容（この時点では HEAD と同じ）に戻りました。この操作で消えた編集内容は Git の履歴に残っていないため、取り戻せません。 実行前に git diff app.txt で確認する習慣を付けておくと安心です。

--staged --worktree：両方まとめて戻す

$ git status -s
M  README.md

$ git restore --staged --worktree README.md
$ git status -s
（出力なし）

ステージ済みの変更が、インデックスからも作業ツリーからも取り消されました。

--source：過去のコミットや別ブランチの内容に戻す

app.txt は現在2行（v1、v2）で、最初のコミット（HEAD~3）では1行でした。

$ cat app.txt
v1
v2

$ git restore --source=HEAD~3 app.txt
$ cat app.txt
v1
$ git status -s
 M app.txt

--source だけを付けた場合、変わるのは作業ツリーだけです。status は M（未ステージの変更）になります。ここに --staged を加えると、インデックスも指定したコミットの内容になります。

$ git restore --source=HEAD~3 --staged app.txt
$ git status -s
M  app.txt
$ git diff --cached --stat
 app.txt | 1 -
 1 file changed, 1 deletion(-)

別ブランチにしか無いファイルを持ってくることもできます。旧コマンドの git checkout develop -- dev.txt と同じ結果（A：新規ファイルとしてステージ済み）になることを確認しました。

$ git restore --source=develop --staged --worktree dev.txt
$ git status -s
A  dev.txt

$ git checkout develop -- dev.txt
$ git status -s
A  dev.txt

「checkout X -- file」と同じにしたいなら --staged --worktree の両方を付ける、と覚えておくと置き換えで迷いません。

削除したファイルと未追跡ファイル

誤って消したファイルも restore で戻せます。

$ rm README.md
$ git status -s
 D README.md
$ git restore README.md
$ git status -s
（出力なし）

一方、Git がまだ追跡していない新規ファイルは restore の対象外です。

$ git restore new.txt
error: pathspec 'new.txt' did not match any file(s) known to git

新規ファイルを git add したあとで取り消すと、追跡前の状態（??）に戻ります。ファイル自体は残ります。

$ git add new.txt
$ git restore --staged new.txt
$ git status -s
?? new.txt

git statusのヒントはrestoreを案内している

git status を長い表示で実行すると、次に打つコマンドの候補が出ます。ここで案内されるのは restore です。

$ git status
On branch main
（ブランチの進み具合の行は省略）

Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
    modified:   app.txt

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
    modified:   README.md

迷ったら git status を打ち、表示されたとおりに実行する、という進め方ができるのも switch／restore を使う利点です。

restoreのオプション一覧

resetとの使い分け

「元に戻す」系のコマンドとして git reset もあります。対象が違うので、次の表で区別できます。

「ブランチを移る＝switch」「ファイルを戻す＝restore」「コミットを取り消す＝reset」という3分類で考えると、どれを使うかがすぐ決まります。コミットの取り消し手順は別の記事で詳しく扱っています。

よく使う一連の流れ（コピペ用）

# 1. 最新を取得して、作業用ブランチを作る
git switch main
git pull
git switch -c feature/cart

# 2. 途中で別ブランチを確認して戻る
git stash
git switch develop
git switch -
git stash pop

# 3. addしすぎたファイルをステージから外す
git restore --staged config.local.json

# 4. 試し書きを取り消す
git diff app.txt        # 消える内容を確認
git restore app.txt

# 5. 1つ前のコミット時点のファイルを取り出して見比べる
git restore --source=HEAD~1 app.txt
git diff                # いまのコミットとの差分
git restore app.txt     # 元に戻す

# 6. タグの時点を確認して戻る
git switch --detach v1.0
git switch -

よくある質問

Q. git checkoutは今後使えなくなりますか？ A. checkout はこれまでどおり使えます。今回確認した git-switch の公式ドキュメントでも detached HEAD の説明は git-checkout のページを参照する形になっており、switch／restore と併存しています。既存の手順は書き換えなくても動きます。

Q. git switch -c と git checkout -b に違いはありますか？ A. 結果は同じで、ブランチを作成して切り替えます。オプションの文字が -b（branch）から -c（create）に変わっただけです。作り直しの -B は -C に対応します。

Q. git restore で消した変更は元に戻せますか？ A. コミットも git add もしていない編集内容は Git に記録されていないため、restore で取り消すと戻せません。エディタの履歴機能に残っている場合があります。取り消す前に git diff で確認するか、迷うときは git stash で退避しておくと後から取り出せます。

Q. detached HEADになってしまいました。どう戻せばよいですか？ A. git switch - または git switch main でブランチに戻れます。その状態でコミットした内容を残したい場合は、戻る前に git switch -c <ブランチ名> を実行します。

まとめ

• checkout は「ブランチ切り替え」と「ファイルを戻す」の2役、switch と restore はそれを1役ずつに分けたコマンド
• checkout -b → switch -c、checkout - → switch -、checkout -- file → restore file、reset HEAD file → restore --staged file と置き換えられる
• コミットへ直接移動するときは git switch --detach。checkout は引数に書くだけで detached HEAD になる
• 未コミットの変更で切り替えられないときは、コミット・stash・switch -m・取り消しの4通りから選ぶ
• ブランチ名とファイル名が同じとき、checkout は -- の位置で解釈が変わる。switch／restore なら迷わない
• restore は「何も付けない＝作業ツリー」「--staged＝インデックス」「--source＝復元元の指定」。checkout X -- file と同じにするには --staged --worktree を両方付ける
• 迷ったら git status のヒントどおりに実行すればよい

株式会社RJCでは、git switchやrestoreを使ったブランチ操作を仲間と学び合っています。こうした知識を共有しながら、日々技術を磨いています。

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。