Gitで作業ブランチを切り替える際、「git switch を使うべきなのか、それとも昔からある git checkout を使うべきなのか？」と迷ったことはないでしょうか。
結論からお伝えすると、ブランチの操作を行うなら今後は「git switch」を使うのが強く推奨されます。
なぜなら、従来の git checkout は「ブランチの切り替え」と「ファイルの変更破棄」という全く異なる2つの役割を1つのコマンドで兼ねており、コマンドの誤操作によって未コミットの作業ファイルを誤って消してしまう危険性があったためです。
この問題を根本から解消するために、Git 2.23（2019年リリース）でブランチ操作に特化したコマンドとして登場したのが「git switch」です。
この記事では、年間を通して多くの開発者が疑問に抱く「switchとcheckoutは何が違うのか」「実務ではどちらを使うべきか」について、機能対比表や具体例を交えてわかりやすく解説します。
この記事で行うこと
前提条件・対象読者
【結論】git switch と git checkout の機能対比表
まず結論として、日常的なGit操作におけるコマンドの対応表をまとめました。
| 行いたい操作 | git switch（推奨） | git checkout（従来） | 備考 |
|---|---|---|---|
| 既存ブランチへの切り替え | git switch <ブランチ名> | git checkout <ブランチ名> | 基本構文は同じ |
| 新規ブランチの作成と切り替え | git switch -c <ブランチ名> | git checkout -b <ブランチ名> | オプションが -c と -b で異なる |
| 直前のブランチへ戻る | git switch - | git checkout - | ハイフン指定で1つ前に戻る |
| リモートブランチを追跡して作成 | git switch <リモートブランチ名> | git checkout <リモートブランチ名> | リモートと同名で作成 |
| 作業中のファイル変更を取り消す | switchでは不可（git restore <ファイル>） | git checkout -- <ファイル名> | ファイル復元はrestoreへ完全分離 |
| 過去のコミットを直接確認する | git switch --detach <コミットID> | git checkout <コミットID> | いわゆるDetached HEAD状態 |
ご覧の通り、ブランチの切り替えや新規作成に関する操作は、すべて git switch でより直感的に行えるようになっています。
一方で、ファイルの変更取り消し操作は git switch から完全に排除されています。この「機能の分離」こそが、git switch が誕生した最大の理由です。
なぜgit switchが導入されたのか（checkoutの役割過多と歴史的背景）
git switch が導入された背景には、従来の git checkout が抱えていた「役割の過多（スイスアーミーナイフ状態）」という構造的な問題がありました。
checkoutが抱えていた危険性
従来の git checkout は、以下のように全く性質の異なる2つの機能を1つのコマンドで引き受けていました。
- 作業ブランチを移動する（HEADのポインタを切り替える）
- 編集中のファイルの変更を破棄して、前回のコミット状態に戻す
この設計には、重大なリスクが潜んでいました。例えば、編集中のファイル名と同じ名前のブランチが存在していた場合です。
# feature という名前のブランチに切り替えたいつもりで実行
git checkout feature
もし作業ディレクトリにたまたま「feature」という名前のファイルやフォルダが存在していた場合、Gitは「ブランチを切り替えたいのか、それともファイルの変更を取り消したいのか」を自動判別しようとします。
引数の指定ミスや解釈の曖昧さによって、意図せず未コミットの大切な作業コードが上書き破棄されてしまう事故が現場で頻発していました。
Git 2.23によるコマンドの役割分離
Gitの開発コミュニティはこの混乱を重く受け止め、Git 2.23（2019年8月）において、肥大化した checkout の機能を以下の2つの専用コマンドへ綺麗に分離しました。
- ブランチ操作の専用コマンド:
git switch - ファイル復元の専用コマンド:
git restore
役割が明確に分かれたことで、「ブランチを切り替えるつもりだったのに、ファイルを吹き飛ばしてしまった」という人為的ミスが原理的に発生しなくなりました。
git switchの基本的な使い方
ここからは、実務で毎日使う git switch の代表的なコマンドパターンを解説します。
1. 既存のブランチへ切り替える
作成済みのブランチに切り替える場合は、引数にブランチ名を指定するだけです。
# develop ブランチへ切り替える
git switch develop
実行結果の例:
$ git branch
* main
develop
$ git switch develop
Switched to branch 'develop'
Your branch is up to date with 'origin/develop'.
$ git branch
main
* develop
2. 新しいブランチを作成して同時に切り替える（-cオプション）
ブランチを新規作成すると同時にそのブランチへ切り替える場合は、-c（createの頭文字）オプションを使用します。
従来の git checkout では -b（branchの頭文字）でしたが、git switch では -c に統一されています。
# feature/login ブランチを新規作成して切り替える
git switch -c feature/login
実行結果の例:
$ git switch -c feature/login
Switched to a new branch 'feature/login'
$ git branch
develop
* feature/login
main
特定のブランチやコミットを分岐元にして新ブランチを作成したい場合は、末尾に分岐元を指定します。
# main ブランチから派生して feature/user-profile を作成する
git switch -c feature/user-profile main
なお、大文字の -C オプションを使用すると、すでに同名のブランチが存在する場合でも強制的に初期化・上書き作成されてしまいます。既存ブランチのコミット履歴を見失う原因になるため、実務では小文字の -c を原則使用してください。
3. 直前の作業ブランチへ戻る（ハイフン指定）
1つ前に作業していたブランチへ素早く戻りたい場合は、ブランチ名のかわりに半角ハイフン - を指定します。
これはシェルの cd -（直前のディレクトリに戻る）と同じ感覚で利用できる非常に便利な機能です。
# 直前にいたブランチへ戻る
git switch -
実行結果の例:
$ git switch main
Switched to branch 'main'
$ git switch feature/login
Switched to branch 'feature/login'
# 再び main ブランチへワンタッチで復帰
$ git switch -
Switched to branch 'main'
作業ブランチとメインブランチを行き来しながら動作確認を行う際に、ブランチ名を毎回入力する手間を大幅に削減できます。
4. リモートブランチをローカルに追跡ブランチとして取得する
GitHubなどのリモートリポジトリに新しくプッシュされたブランチ（例: origin/feature/payment）で作業を始めたい場合、ローカルにそのブランチが存在しなくても、リモートブランチ名をそのまま指定するだけで取得できます。
# リモートの origin/feature/payment を追跡するローカルブランチを自動作成して切り替える
git switch feature/payment
実行結果の例:
Branch 'feature/payment' set up to track remote branch 'feature/payment' from 'origin'.
Switched to a new branch 'feature/payment'
従来の checkout と同様に、リモートのブランチを自動検知して追跡設定（tracking）まで一度に完了してくれます。
git restoreとの関係（ファイルの変更取り消しはrestoreへ分離）
git checkout のもう一つの役割だった「作業ファイルの変更取り消し」は、新設された git restore コマンドが担当します。
switch と restore の関係性を理解しておくと、Gitの操作体系が頭の中でスッキリ整理されます。
ワークツリーの変更を取り消す場合
ファイルを編集したものの、コミット前の変更を破棄して元の状態に戻したい場合の比較です。
- 従来の書き方:
git checkout -- index.html - 現在の推奨:
git restore index.html
ステージングされた変更を解除する場合（git add の取り消し）
誤って git add してしまったファイルを、コミット対象から外したい場合の比較です。
- 従来の書き方:
git reset HEAD index.html - 現在の推奨:
git restore --staged index.html
ブランチの移動は git switch、ファイルの巻き戻しは git restore と使い分けることで、Gitコマンドの意図が誰の目にも一目瞭然になります。
実務ではどちらを使うべきか？（今後の推奨方針と注意点）
日常の開発現場や学習において、今後どちらを使うべきかについて整理します。
個人開発や新規プロジェクトでは「git switch」一択
これからGitを学習する方や、新しいプロジェクトを開始する場合は、迷わず git switch を利用してください。
理由:
現場で checkout が今も使われている理由と注意点
現場に入ると、先輩エンジニアや社内Wikiで今も git checkout が多用されている場面によく遭遇します。
これには以下の背景があります。
- 長年Gitを使ってきた開発者の指が
checkoutに慣れ親しんでいる（指癖・マッスルメモリー） - 過去に作成されたCI/CDパイプラインやデプロイスクリプトが
git checkoutで記述されている - レガシーなサーバー環境などで、Git 2.23未満の古いバージョンが稼働している
なお、Git公式において git checkout コマンドが廃止（削除）される予定はありません。世界中の膨大なスクリプトや互換性を維持するため、今後も利用自体は可能です。
ただし、Git公式ドキュメントでは checkout は過去の互換性のためのコマンドと位置づけられており、人間の手入力による日常操作では switch への移行が推奨されています。
ショートカット（エイリアス）を活用したスムーズな移行
タイピングの手間を減らしたい場合は、Gitの設定ファイルにエイリアス（短縮コマンド）を登録しておくと快適です。
# git sw で git switch を実行できるように登録
git config --global alias.sw switch
このように設定しておけば、git sw develop や git sw -c feature/new のように、短いタイピングで安全にブランチ操作を行えます。
まとめ
本記事で解説した重要ポイントを振り返ります。
日々のブランチ切り替えを switch に切り替えて、より安全でミスのないGit運用を実践してみてください。
次に読むおすすめ記事
Gitの全体像や基本コマンド、ブランチ運用、トラブル解決手順を体系的に学びたい方は、以下の完全ガイドもあわせて参考にしてください。
