ブランチを理解する — checkoutとswitchの使い分け
ブランチは、Gitの機能の中でもっとも強力で、もっとも使うものです。ブランチを使いこなせるかどうかで、チーム開発の生産性が大きく変わります。
ブランチとは何か
ブランチを一言で言うと「独立した作業の流れ」です。
たとえば、以下のような状況を考えます。
mainブランチで開発を進めている- 新機能Aの開発を始めたいが、途中でリリースが必要になるかもしれない
- 新機能Aの作業中に、別のバグ修正も並行してやりたい
これを main ブランチだけでやると、リリースしたいときに未完成の新機能Aがコードに混ざってしまいます。ブランチを使えば、新機能A用の作業を main から切り離して進め、完成してから合流させられます。
main から分岐した feature ブランチで作業し、完成後に main に取り込む(マージする)のが基本パターンです。
ブランチの正体は「コミットへのポインタ」
Gitのブランチは、他のバージョン管理システムと比べて極端に軽いと言われます。その理由は、ブランチが単に「あるコミットを指すポインタ(付箋のようなもの)」だからです。
新しいブランチを作るのは、コミットに付箋を貼るだけの操作。ファイルのコピーは一切発生しません。だからGitでは「まずブランチを切る」が日常的なスタイルになります。
ブランチを確認する
現在あるブランチの一覧を確認します。
git branch
# * main* が付いているのが、今いるブランチです。
リモートのブランチも含めて見たい場合は -a を付けます。
git branch -a
# * main
# remotes/origin/main
# remotes/origin/feature/loginブランチを作成して切り替える
新しいブランチを作って、そこに移動する操作は頻繁に行います。いくつか書き方があります。
# 新しい書き方(推奨)
git switch -c feature/login
# 従来の書き方
git checkout -b feature/login-c は create の略です。これで現在のブランチから feature/login という新しいブランチが作られ、そこに切り替わります。
既存のブランチに切り替えるだけなら -c は不要です。
# 新しい書き方
git switch main
# 従来の書き方
git checkout maincheckout と switch の違い
Gitには歴史的な経緯があって、ブランチ操作は長らく git checkout で行われてきました。しかし checkout は「ブランチを切り替える」以外にも「ファイルを過去の状態に戻す」など複数の役割を兼ねているため混乱しやすい、という問題がありました。
そこでGit 2.23(2019年)で、checkout の機能を分割した新しいコマンドが導入されました。
| 操作 | 従来(checkout) | 新しい書き方 |
|---|---|---|
| ブランチ切り替え | git checkout main | git switch main |
| ブランチ作成+切り替え | git checkout -b feat | git switch -c feat |
| ファイルを元に戻す | git checkout -- file | git restore file |
新しく覚えるなら switch と restore を使うのが推奨です。ただし、ネットの記事や古いドキュメントでは checkout が使われていることが多いので、両方読めるようにしておきましょう。
ブランチの命名規則
ブランチ名は自由に付けられますが、チームで一貫した命名規則を持つのが一般的です。よく見るパターンは以下です。
| プレフィックス | 用途 | 例 |
|---|---|---|
feature/ | 新機能開発 | feature/user-login |
fix/ | バグ修正 | fix/header-layout |
hotfix/ | 本番の緊急修正 | hotfix/payment-error |
chore/ | 雑務(依存更新など) | chore/update-deps |
docs/ | ドキュメント | docs/setup-guide |
ブランチ名には / を含めることができますが、これは単なる命名慣習で、ディレクトリのような階層構造があるわけではありません(表示上は階層に見えるツールもあります)。
ブランチを削除する
作業が終わって不要になったブランチは削除します。
# マージ済みのブランチを削除
git branch -d feature/login
# マージしていないブランチを強制削除
git branch -D feature/login大文字の -D は「マージされていなくても強制的に削除」なので、誤って使うと未マージの作業を失います。基本は小文字の -d を使い、Gitが「マージされていないので削除できません」と止めてくれる安全側に倒しましょう。
リモートのブランチを削除するには以下のコマンドです。
git push origin --delete feature/login現在の状態を図で確認する
ブランチが増えてくると、自分がどこにいるのか分からなくなります。以下のコマンドでグラフィカルに履歴を見られます。
git log --oneline --graph --all --decorate--oneline— コミット1つを1行で表示--graph— 枝分かれをアスキーアートで表示--all— すべてのブランチを表示--decorate— ブランチ名やタグ名を表示
このコマンドはよく使うので、エイリアスを設定しておくと便利です。
git config --global alias.graph "log --oneline --graph --all --decorate"
# 以後 `git graph` で実行できるよくあるハマりどころ
1. 違うブランチで作業してしまった
git switch を忘れて main で作業を始めてしまった場合、まだコミットしていなければ git stash で退避してからブランチを切り替え、git stash pop で戻せます(stashの詳細は9章で扱います)。
2. ブランチ名を間違えた
git branch -m old-name new-name-m で名前を変更できます。現在いるブランチなら git branch -m new-name だけでOK。
3. マージしたブランチが大量に残っている
不要なローカルブランチをまとめて削除するワンライナー:
git branch --merged | grep -v "main" | xargs git branch -dmain 以外のマージ済みブランチをすべて削除します。
ちゃんと使うためのポイント
- ブランチは「独立した作業の流れ」、物理的なコピーではない
- 新しく覚えるなら
switchとrestoreを使う - ブランチ名は
feature/xxxのような命名規則で統一 - 削除は
-d(安全) を基本、-D(強制)は慎重に git log --oneline --graph --allで全体像を把握する
次の章では、ブランチで作業した内容を main に取り込む2つの方法、merge と rebase の違いを学びます。