最近、git switch -c という書き方を見て、正直「git checkout -b で良くない?」と思っていました。昔から読んできた記事も、手元の記憶も、だいたい checkout だったからです。

ただ、checkout が持っていた役割を知ると、かなり納得しました。checkout はブランチを切り替えるコマンドでもあり、ファイルを元に戻すコマンドでもありました。つまり、1 つの単語に複数の意味が乗っていたわけです。

自分はここを初めてちゃんと理解して、今後の手順ではブランチ操作は switch、ファイル復元は restore と書くほうが分かりやすいなと思いました。この記事は、その気づきのメモです。

checkout は悪いコマンドではない

昔の記事に多いのは自然

まず前提として、git checkout が悪いわけではありません。昔からあるコマンドなので、既存の記事や手順に多いのは自然です。自分も長く checkout -b を使っていました。

git checkout develop
git checkout -b feature/foo

これでブランチ移動も、新規ブランチ作成もできます。手元の Git が古い環境や、チームの手順が checkout で揃っている場合は、無理に置き換える必要はないと思います。

ただ、初学者や久しぶりに Git を触る人に説明するときは、checkout という単語の広さが少し引っかかります。

同じ checkout でファイルも戻せる

checkout はブランチ操作だけではなく、ファイルを戻す用途にも使われてきました。

git checkout -- path/to/file

これは、作業ツリー上のファイルを戻す操作です。ブランチ移動の checkout と、ファイル復元の checkout が同じコマンドに入っています。

慣れていれば問題ないのですが、後から読むと「これはブランチの話?ファイルの話?」となる余地があります。ここで switchrestore が効いてきます。

switchrestore は意図が見える

ブランチ移動は switch

ブランチを切り替えるだけなら、今は git switch と書けます。

git switch develop

新しくブランチを作って、そのまま移動するなら -c です。

git switch -c feature/foo

switch は名前の通り、ブランチを切り替えるためのコマンドです。checkout -b よりも、コマンドを見た瞬間に「ブランチ操作だな」と分かります。ここが自分には刺さりました。

ファイル復元は restore

一方で、ファイルを戻す操作は git restore と書けます。

git restore path/to/file

この名前もかなり直感的です。ファイルを戻すなら restore。ブランチを切り替えるなら switch。コマンド名だけで役割が分かれるので、手順書やブログに書いたときの読みやすさが上がります。

対応関係を並べる

自分の中では、次の対応で覚えるのが一番分かりやすかったです。

# 既存ブランチへ移動
git checkout develop
git switch develop

# 新規ブランチを作って移動
git checkout -b feature/foo
git switch -c feature/foo

# ファイルを戻す
git checkout -- path/to/file
git restore path/to/file

やっていることは大きく変わりません。ただ、switchrestore に分けると、操作の対象がブランチなのかファイルなのかをコマンド名から読めます。

これは小さい差ですが、Git の手順はコピペされやすいので、後から読む人にとっては結構大事だと思います。

古い環境では checkout も現役

Git 2.23 より前なら使えない

switchrestore は Git 2.23 で追加されたコマンドです。なので、閉じた古いオンプレ環境や、古い Git が入ったままのサーバーでは使えない可能性があります。

そういう場所では、checkout を使うのが現実的です。古い記事や古い手順に checkout が残っているのも、それ自体はおかしくありません。

手順を書くなら併記もあり

自分が今後ブログや README に書くなら、基本は switch / restore を使いつつ、必要に応じて checkout も併記するのが良さそうです。

# Git 2.23 以降
git switch -c feature/foo

# 古い環境ではこちらでも同じ
git checkout -b feature/foo

チームの手元の Git バージョンが揃っていないなら、無理に新しいコマンドだけに寄せないほうがいいです。大事なのは、コマンドの新旧よりも「何をする操作なのか」が伝わることだと思います。

これから自分はどう書くか

ブランチ操作は switch に寄せる

自分は今後、新しく手順を書くときはブランチ操作を switch に寄せます。

git switch main
git switch -c feature/foo

理由は単純で、ブランチ移動専用だと分かるからです。checkout を知っている人にも意味は伝わるし、初めて読む人にも「ブランチを切り替えているんだな」と見えやすいです。

ファイルを戻すなら restore と書く

ファイルを戻す操作は、restore と書きます。

git restore src/example.ts

特に、記事や手順書ではここを分けたいです。checkout でも動くけれど、restore のほうが意図がそのまま名前に出ます。

この差は大きな機能差ではありません。でも、Git のコマンドは一つ間違えると怖さがあります。だからこそ、コマンド名の時点で意図が見える書き方に寄せるのは、地味に良い改善だと思いました。

参考