Gitでブランチを使う理由｜branch・checkout・mergeの基本
Gitのブランチは、今の作業を壊さずに別の変更を進めるための仕組みです。機能追加、バグ修正、レビュー前の確認を同時に回したい場面で特に効きます。
1本のブランチだけで作業を続けると、途中の変更が混ざりやすくなります。ブランチを分ければ、「本番に近い状態」と「試している変更」を切り離したまま進められます。
git branch: ブランチを作る、一覧を見るgit checkout: ブランチを切り替える。古い書き方として今も広く使われるgit switch: ブランチ切り替えに用途を絞った新しめのコマンドgit merge: 別ブランチの変更を取り込む
ここがポイント: ブランチは“並行作業のための分岐”で、
mergeはその分岐を本流へ戻す操作です。
まず知っておきたい前提
この記事は、GitのCLIを使う前提で説明します。対象は、ローカルリポジトリでの基本操作です。
Gitでは、作業中の場所を HEAD が指します。公式の用語集では、現在のブランチと作業ツリーの関係が整理されています。ここを押さえると、checkout や switch の挙動が理解しやすくなります。
- ブランチ: 開発の流れを分ける線
HEAD: 今いる位置- 作業ツリー: 実際に手元で見えているファイル群
- インデックス: 次のコミットに入る内容の待機場所
checkout と switch の違い
初心者が混乱しやすいのはここです。git checkout は多機能で、ブランチ切り替えにもファイル復元にも使えます。そのぶん、何をしているコマンドなのか見分けにくい場面があります。
一方で git switch は、ブランチ切り替えに役割を絞ったコマンドです。Git 2.23で導入され、公式ドキュメントでも分離された使い方が案内されています。新しく覚えるなら、切り替えは switch を優先すると理解しやすいです。
ブランチを使う理由
ブランチを使う一番の理由は、変更を混ぜないことです。
たとえば、main で公開中のコードを管理しているとします。その状態で新機能を直接書き始めると、途中の未完成コードまで main に乗りやすくなります。そこで feature/login-form のようなブランチを切って作業すると、完成するまで本流を汚さずに済みます。
典型的な使いどころ
- 新機能を試す
- バグ修正だけを先に出す
- レビュー用に変更範囲を分ける
- リリース後の緊急修正を別線で進める
ブランチを使わないと起きやすいこと
- 関係ない修正が同じコミットに混ざる
- 途中作業を戻しにくい
- レビューで差分が読みにくい
- 複数人作業で衝突が増える
git branch の基本
git branch は、ブランチの作成や確認に使います。まずは最小限の形だけ覚えれば十分です。
一覧を見る
git branch
出力例:
* main
feature/login-form
* が付いている行が、今いるブランチです。
新しいブランチを作る
git branch feature/login-form
この時点では、ブランチは作られるだけで、まだその場所へ移動していません。作成と切り替えをまとめてやるなら、次の形が実務ではよく使われます。
git switch -c feature/login-form
古い書き方ならこちらです。
git checkout -b feature/login-form
名前の付け方
ブランチ名は、後から見て意味が分かることが大事です。
feature/login-form: 機能追加fix/header-bug: バグ修正chore/update-docs: 雑務や保守
短すぎる名前より、目的が伝わる名前のほうがレビューで効きます。
checkout と switch で切り替える
ブランチを作ったら、作業先を切り替えます。
基本の切り替え
git switch feature/login-form
checkout ならこうです。
git checkout feature/login-form
直前のブランチに戻る
git switch -
機能ブランチと main を行き来するときに便利です。
切り替えに失敗する典型例
未コミットの変更が残っていて、切り替え先と内容がぶつかるとエラーになります。これはGitが勝手にファイルを壊さないための安全策です。
よくある対処は次の3つです。
- いったんコミットする
git stashで退避する- 不要な変更なら破棄する
git merge の基本
merge は、別ブランチの変更を今いるブランチへ取り込むコマンドです。普通は main 側に移動してから、作業ブランチを取り込みます。
git switch main
git merge feature/login-form
これで、feature/login-form で積み上げたコミットが main に反映されます。
merge が必要になる場面
- 機能が完成して本流へ戻すとき
- 修正ブランチの内容を共有したいとき
- 複数の作業結果を一本にまとめるとき
Fast-forward とマージコミット
分岐後に main 側が進んでいなければ、履歴はそのまま前に進むだけです。これが fast-forward です。
一方、main と作業ブランチの両方で履歴が進んでいると、2つの流れを合流させるためのマージコミットが作られます。ここで「ブランチを分けていた履歴」が後から見ても追いやすくなります。
実務での流れを最小例で確認する
ここでは、1人作業でも再現しやすい最小パターンを示します。
手順
mainから新しいブランチを作る- そのブランチで編集してコミットする
mainに戻るmergeで取り込む
git switch main
git switch -c feature/update-title
# ファイルを編集
git add .
git commit -m "Update page title"
git switch main
git merge feature/update-title
どんな場面で使うか
- Webページの見出しだけを直したい
- バッチ処理の一部だけ変更したい
- 本流に影響を出さずに試したい
変更単位を小さく切り出せるので、レビュー依頼や差し戻しにも対応しやすくなります。
マージ競合はなぜ起きるのか
競合は、同じ場所を別ブランチで別々に変えたときに起きます。Gitは自動で安全に決められないため、人間に判断を戻します。
たとえば同じ app.js の同じ数行を、main と feature の両方で編集していた場合です。git merge 実行時に競合マーカーが入り、内容を確認して手で直す必要があります。
競合時の基本対応
- 競合ファイルを開く
<<<<<<<,=======,>>>>>>>の範囲を確認する- 残す内容に修正する
git addで解決済みにするgit merge --continueで続行する
競合を減らすコツ
- 長期間ブランチを放置しない
- 変更範囲を小さくする
- 役割ごとにファイルを分ける
- 早めにレビューする
よくある失敗と対処
ブランチ運用は便利ですが、初心者がつまずく場所もほぼ決まっています。
branch しただけで切り替わったと思い込む
git branch feature/x は作成だけです。移動していません。今どこにいるか不安なら、git branch で * を確認します。
checkout が多機能すぎて混乱する
ファイル復元とブランチ切り替えが同じコマンドに入っているので、意図しない使い方をしやすいです。学び始めは次のように分けると整理しやすくなります。
- ブランチ切り替え:
git switch - ファイル復元:
git restore
main でそのまま作業してしまう
小さな修正でも、いったん作業ブランチを作る癖を付けるほうが安全です。後から差分を見返したときの読みやすさが大きく違います。
merge 以外の選択肢はあるか
あります。代表例は rebase です。
ただし、最初の段階では branch で分けて merge で戻す流れを先に固めたほうがよいです。rebase は履歴を整えやすい反面、履歴を書き換える操作なので、意味を理解しないまま使うと混乱しやすくなります。
また、複数の作業ディレクトリを同時に持ちたい場合は git worktree もあります。これは「同じリポジトリで複数ブランチを同時に開きたい」ときに便利ですが、まずは通常のブランチ運用を覚えてからで十分です。
最初に覚えるならこの形で十分
Gitのブランチは、難しい機能というより、日々の変更を安全に分ける基本動作です。初心者ほど早めに身につけたほうが、後のレビュー、修正、共同作業が楽になります。
まずは次の流れを、手元で1回そのまま試すのがおすすめです。
git switch -c feature/xxxで作業開始- 変更してコミット
git switch mainで戻るgit merge feature/xxxで取り込む
この一連の流れが自然にできるようになると、次に stash、rebase、worktree を学ぶ意味も見えやすくなります。次に詰まりやすいのは、マージ競合をどう読むかです。