`git checkout` はもう迷わない。`git switch` / `git restore` を実例で理解する

Git を使っていると、昔からよく登場するコマンドに git checkout があります。

git checkout main
git checkout -b feature/login
git checkout -- app/Models/User.php
git checkout main -- config/app.php

しかし、git checkout は少し役割が多すぎます。

ブランチを切り替えることもできるし、ブランチを作ることもできるし、ファイルの変更を戻すこともできるし、別ブランチからファイルを取り出すこともできます。

その結果、初心者だけでなく実務経験者でも、

この checkout はブランチ操作？
それともファイルを戻す操作？
作業中の変更は消える？

と迷いやすいコマンドになっています。

そこで Git 2.23 以降では、checkout の役割を分けるために、次の2つのコマンドが追加されました。

git switch   # ブランチを切り替える
git restore  # ファイルを復元する

この記事では、古い git checkout / git reset の使い方と比較しながら、git switch と git restore の使い方を実務目線で整理します。

---

結論

まず結論です。

やりたいこと	古い書き方	新しい書き方
ブランチを切り替える	git checkout main	git switch main
ブランチを作って切り替える	git checkout -b feature/login	git switch -c feature/login
リモートブランチを元に作業開始	git checkout -b feature/login origin/feature/login	git switch -c feature/login origin/feature/login
ファイルの変更を戻す	git checkout -- app.php	git restore app.php
git add を取り消す	git reset HEAD app.php	git restore --staged app.php
別ブランチからファイルを取り出す	git checkout main -- app.php	git restore --source main app.php

ざっくり言うと、こう覚えるとよいです。

# ブランチ操作
git switch

# ファイル操作
git restore

---

1. git switch の使い方

1-1. 既存ブランチへ切り替える

古い書き方

git checkout develop

新しい書き方

git switch develop

develop ブランチへ移動します。

$ git branch
* main
  develop

$ git switch develop
Switched to branch 'develop'

$ git branch
  main
* develop

git switch は、名前の通り「ブランチを切り替える」ためのコマンドです。

checkout よりも意図が明確です。

---

1-2. 新しいブランチを作って切り替える

古い書き方

git checkout -b feature/login

新しい書き方

git switch -c feature/login

-c は create の意味です。

git switch -c feature/login

これは、以下の2つをまとめて実行するイメージです。

git branch feature/login
git switch feature/login

実務では、機能追加を始めるときによく使います。

git switch main
git pull origin main
git switch -c feature/user-profile

この流れで、最新の main から作業ブランチを作れます。

---

1-3. 特定のブランチを起点に新しいブランチを作る

例えば、develop を起点に feature/payment を作りたい場合です。

古い書き方

git checkout -b feature/payment develop

新しい書き方

git switch -c feature/payment develop

実務例です。

git switch develop
git pull origin develop
git switch -c feature/payment

または1行で書けます。

git switch -c feature/payment develop

---

1-4. リモートブランチを元にローカルブランチを作る

チーム開発では、他の人が作ったリモートブランチをローカルに持ってきて作業することがあります。

古い書き方

git checkout -b feature/api origin/feature/api

新しい書き方

git switch -c feature/api origin/feature/api

ただし、Git の設定や状況によっては、次のようにリモートブランチ名を指定するだけで切り替えられることもあります。

git switch feature/api

リモートに origin/feature/api があり、ローカルに同名ブランチがない場合、Git がよしなに追跡ブランチを作ってくれるケースがあります。

明示的に書きたい場合は、こちらのほうが安全です。

git switch -c feature/api --track origin/feature/api

---

1-5. 直前のブランチに戻る

古い書き方

git checkout -

新しい書き方

git switch -

例です。

git switch main
git switch feature/login
git switch -

この場合、feature/login から main に戻ります。

レビューや緊急修正でブランチを行き来するときに便利です。

---

1-6. detached HEAD に切り替える

通常の開発ではあまり多用しませんが、特定のコミットを確認したい場合があります。

古い書き方

git checkout abc1234

新しい書き方

git switch --detach abc1234

--detach を明示することで、「ブランチではなく特定コミットを直接見る」という意図がはっきりします。

git switch --detach v1.0.0

タグや過去コミットの状態を確認するときに使えます。

作業を続けるなら、そこからブランチを作ります。

git switch -c hotfix/from-v1.0.0

---

2. git restore の使い方

git restore はファイルを復元するためのコマンドです。

ここで重要なのは、Git には大きく3つの状態があることです。

HEAD
  ↓
ステージングエリア
  ↓
作業ツリー

ざっくり言うと、

場所	意味
HEAD	最後のコミット
ステージングエリア	次にコミットする予定の内容
作業ツリー	今エディタで編集しているファイル

git restore は、このうち「作業ツリー」や「ステージングエリア」を戻すときに使います。

---

2-1. 作業中のファイル変更を取り消す

例えば、app/Services/UserService.php を編集したけれど、変更を捨てたい場合です。

git status

modified: app/Services/UserService.php

古い書き方

git checkout -- app/Services/UserService.php

新しい書き方

git restore app/Services/UserService.php

これで、作業ツリー上の変更が取り消されます。

git restore app/Services/UserService.php

注意点として、この操作は未コミットの変更を捨てます。

戻した後に「やっぱり必要だった」と思っても、基本的には復元できません。

実行前に差分を確認するのがおすすめです。

git diff app/Services/UserService.php
git restore app/Services/UserService.php

---

2-2. 複数ファイルの変更を戻す

git restore app/Services/UserService.php routes/web.php

ディレクトリ単位でも戻せます。

git restore app/

カレントディレクトリ以下をまとめて戻す場合は、次のように書けます。

git restore .

ただし、これは現在のディレクトリ以下の変更をまとめて捨てるため、実行前に必ず確認しましょう。

git status
git diff
git restore .

---

2-3. git add を取り消す

ファイルを git add した後で、ステージングを取り消したい場合です。

git add app/Services/UserService.php
git status

Changes to be committed:
  modified: app/Services/UserService.php

古い書き方

git reset HEAD app/Services/UserService.php

新しい書き方

git restore --staged app/Services/UserService.php

--staged を付けると、ステージングエリアから外します。

重要なのは、ファイルの編集内容自体は消えないことです。

git restore --staged app/Services/UserService.php

状態はこうなります。

Changes not staged for commit:
  modified: app/Services/UserService.php

つまり、

git restore --staged ファイル名

は、git add の取り消しです。

---

2-4. git add . を取り消す

間違えて全部 add してしまった場合です。

git add .

古い書き方

git reset HEAD

新しい書き方

git restore --staged .

これで、ステージングされていたファイルをすべて unstaged に戻せます。

git restore --staged .

作業ツリーの変更は残ります。

---

2-5. ステージングも作業ツリーも両方戻す

例えば、以下のような状態だとします。

git add app/Services/UserService.php

さらにその後、同じファイルを追加で編集した場合、Git の状態は少し複雑になります。

Changes to be committed:
  modified: app/Services/UserService.php

Changes not staged for commit:
  modified: app/Services/UserService.php

つまり、

• ステージング済みの変更
• まだステージングしていない変更

の両方が存在します。

両方を最後のコミット状態に戻したい場合は、次のようにします。

git restore --staged app/Services/UserService.php
git restore app/Services/UserService.php

または、1回でまとめて戻すこともできます。

git restore --staged --worktree app/Services/UserService.php

--worktree は作業ツリーを対象にするオプションです。

git restore --staged --worktree app/Services/UserService.php

これは強力な操作なので、実行前に必ず確認しましょう。

git status
git diff
git diff --staged

---

2-6. 別ブランチから特定ファイルを取り出す

例えば、main ブランチにある config/app.php だけを現在のブランチに持ってきたい場合です。

古い書き方

git checkout main -- config/app.php

新しい書き方

git restore --source main config/app.php

実務では、以下のような場面で使います。

• main の設定ファイルだけ取り込みたい
• 他ブランチの実装を一部だけ参考にしたい
• 誤って変更したファイルを、特定ブランチの状態に戻したい

例です。

git switch feature/payment
git restore --source main config/app.php

これで、現在のブランチは feature/payment のまま、config/app.php だけが main の内容になります。

---

2-7. 特定コミットからファイルを取り出す

ブランチだけでなく、コミットIDを指定することもできます。

git restore --source abc1234 app/Services/UserService.php

タグも指定できます。

git restore --source v1.2.0 config/app.php

古い書き方だと、次のようになります。

git checkout abc1234 -- app/Services/UserService.php
git checkout v1.2.0 -- config/app.php

restore のほうが「ファイルを復元している」ことが明確です。

---

3. よくある実務シナリオ

シナリオ1: 新機能ブランチを作って作業する

古い書き方

git checkout main
git pull origin main
git checkout -b feature/article-search

新しい書き方

git switch main
git pull origin main
git switch -c feature/article-search

switch を使うと、ブランチ操作だけをしていることが読み取りやすくなります。

---

シナリオ2: 間違えて編集したファイルを元に戻す

git status

modified: resources/views/articles/index.blade.php

古い書き方

git checkout -- resources/views/articles/index.blade.php

新しい書き方

git restore resources/views/articles/index.blade.php

実務では、戻す前に必ず差分を確認しましょう。

git diff resources/views/articles/index.blade.php
git restore resources/views/articles/index.blade.php

---

シナリオ3: 間違えて git add . してしまった

git add .

古い書き方

git reset HEAD

新しい書き方

git restore --staged .

これは「コミット対象から外す」だけです。

ファイルの編集内容は残ります。

git status

Changes not staged for commit:
  modified: app/Http/Controllers/ArticleController.php
  modified: resources/views/articles/index.blade.php

---

シナリオ4: main ブランチのファイルだけ取り込みたい

現在は feature/article-search ブランチで作業中とします。

git branch

* feature/article-search
  main

main にある config/search.php だけを取り込みたい場合です。

古い書き方

git checkout main -- config/search.php

新しい書き方

git restore --source main config/search.php

現在のブランチは変わりません。

git branch

* feature/article-search
  main

ファイルだけが main の内容に置き換わります。

---

シナリオ5: 作業中の変更を全部捨てたい

作業ツリーの変更をすべて捨てる場合です。

古い書き方

git checkout -- .

新しい書き方

git restore .

ただし、これは未コミットの変更をまとめて破棄します。

実行前に確認しましょう。

git status
git diff
git restore .

未追跡ファイル、つまり git status で Untracked files に出ているファイルは、git restore . では削除されません。

未追跡ファイルも削除したい場合は、別途 git clean を使います。

git clean -fd

ただし、git clean -fd も強力なので注意してください。

事前確認するなら -n を使います。

git clean -fdn

---

4. checkout / switch / restore の考え方

checkout は多機能すぎた

git checkout は便利ですが、複数の役割を持っています。

# ブランチを切り替える
git checkout develop

# ブランチを作って切り替える
git checkout -b feature/login

# ファイルを戻す
git checkout -- app.php

# 別ブランチからファイルを取り出す
git checkout main -- app.php

これらはすべて checkout ですが、やっていることはかなり違います。

---

switch と restore は役割が明確

新しい書き方では、目的ごとにコマンドが分かれます。

# ブランチを切り替える
git switch develop

# ブランチを作って切り替える
git switch -c feature/login

# ファイルを戻す
git restore app.php

# 別ブランチからファイルを取り出す
git restore --source main app.php

読みやすさがかなり違います。

特にチーム開発では、README や手順書、Issue コメント、Pull Request の説明にコマンドを書くことがあります。

そのときに、

git switch
git restore

を使うと、コマンドの意図が伝わりやすくなります。

---

5. よく使う対応表

ブランチ操作

やりたいこと	古い書き方	新しい書き方
既存ブランチへ切り替え	git checkout develop	git switch develop
新規ブランチ作成 + 切り替え	git checkout -b feature/login	git switch -c feature/login
特定ブランチから作成	git checkout -b feature/login develop	git switch -c feature/login develop
直前のブランチへ戻る	git checkout -	git switch -
detached HEAD	git checkout abc1234	git switch --detach abc1234

---

ファイル操作

やりたいこと	古い書き方	新しい書き方
ファイルの変更を戻す	git checkout -- app.php	git restore app.php
複数ファイルを戻す	git checkout -- a.php b.php	git restore a.php b.php
現在ディレクトリ以下を戻す	git checkout -- .	git restore .
git add を取り消す	git reset HEAD app.php	git restore --staged app.php
git add . を取り消す	git reset HEAD	git restore --staged .
別ブランチからファイル取得	git checkout main -- app.php	git restore --source main app.php
特定コミットからファイル取得	git checkout abc1234 -- app.php	git restore --source abc1234 app.php

---

6. 注意点

git restore は変更を消すことがある

以下のコマンドは、未コミットの変更を破棄します。

git restore app.php
git restore .
git restore --staged --worktree app.php

不安な場合は、先に差分を見ましょう。

git status
git diff
git diff --staged

また、一時退避したい場合は stash を使う方法もあります。

git stash push -m "WIP: before restore"

---

git restore --staged はファイルの編集内容を消さない

これは重要です。

git restore --staged app.php

このコマンドは、ステージングを取り消すだけです。

作業ツリーの編集内容は残ります。

つまり、以下の古いコマンドと同じような用途です。

git reset HEAD app.php

---

git restore . は未追跡ファイルを消さない

例えば、次のような状態だとします。

modified: app.php
untracked: memo.txt

ここで、

git restore .

を実行すると、app.php の変更は戻りますが、memo.txt は残ります。

未追跡ファイルを削除するには、git clean を使います。

git clean -fdn  # 削除対象の確認
git clean -fd   # 実際に削除

---

7. 個人的なおすすめ運用

私は次のように使い分けるのが分かりやすいと思っています。

ブランチ操作は switch

git switch main
git switch develop
git switch -c feature/login
git switch -

ファイル復元は restore

git restore app.php
git restore --staged app.php
git restore --source main app.php

履歴を動かす操作は reset

git reset --soft HEAD~1
git reset --mixed HEAD~1
git reset --hard HEAD~1

restore が登場したからといって、reset が不要になったわけではありません。

restore は主にファイルやステージングの復元に使い、reset はコミット履歴や HEAD を動かす操作に使う、という整理が実務では分かりやすいです。

---

まとめ

git checkout は今でも使えます。

ただし、現代的な Git の使い方としては、以下のように分けて覚えると安全です。

git switch   # ブランチを切り替える
git restore  # ファイルを復元する

特にチーム開発では、コマンドの意図が明確であることが重要です。

git checkout main
git checkout -- app.php

よりも、

git switch main
git restore app.php

のほうが、何をしているかが読みやすくなります。

最後に、実務でよく使うものだけ再掲します。

# ブランチ切り替え
git switch main

# ブランチ作成 + 切り替え
git switch -c feature/login

# 直前のブランチへ戻る
git switch -

# 作業中の変更を戻す
git restore app.php

# git add を取り消す
git restore --staged app.php

# 別ブランチからファイルを取り出す
git restore --source main app.php

checkout を完全に忘れる必要はありません。

ただ、これから Git を教える・チームの手順書を書く・新人向けドキュメントを整備するなら、switch と restore を基本にするのがおすすめです。

---

参考

• Git - git-switch Documentation
  https://git-scm.com/docs/git-switch
• Git - git-restore Documentation
  https://git-scm.com/docs/git-restore
• Git - git-checkout Documentation
  https://git-scm.com/docs/git-checkout
• Git - git-reset Documentation
  https://git-scm.com/docs/git-reset
• Git 2.23 Release Notes
  https://github.com/git/git/blob/master/Documentation/RelNotes/2.23.0.adoc