こんにちは、かつコーチです。
ここまでの記事では、1本の道筋でコミットを積み重ねる、Gitの基本的な使い方を解説してきました。
今回からは新しいテーマとして、ブランチについて解説していきます。
ブランチは、Gitを学ぶ上で最初につまずきやすい概念の1つですが、理解できると一気にGitでできることが広がる、重要な仕組みです。
ブランチとは？
別の紙に書く下書き・平行世界
ブランチ（英語で「枝」の意味）とは、リポジトリの中で、本流とは別に変更履歴を分岐させて記録できる仕組みです。
イメージとしては、別の紙に書く下書きを思い浮かべてください。
大事な清書（本線のコード）に直接手を加えるのは怖いものです。
そこで、いったん別の紙（ブランチ）にコピーを取って、そちらで自由に書き直したり、実験したりします。
うまくいけば、その下書きの内容を清書に反映（マージ、次々回の記事で解説）すればいいですし、うまくいかなければ、その下書きの紙を破り捨てるだけで、清書には何の影響もありません。
もう1つのイメージとして、SF作品でよく描かれる平行世界も近い感覚です。
ブランチを作った瞬間に、その時点のコードを引き継いだ「もう1つの世界線」が生まれ、それぞれの世界で別々の変更を進められます。
なぜブランチが必要なのか
ブランチがない状態、つまり1本の道筋だけで開発を進める場合、次のような困りごとが起こりがちです。
- 新機能を試したいが、動くコードを壊すのが怖くて手をつけられない
- 複数人で同時に作業すると、お互いの変更が混ざって収拾がつかなくなる
- バグ修正と新機能の開発を、同じ場所で並行して進めにくい
ブランチを使えば、常に安定して動く本線を保ちながら、その横で新機能の実験やバグ修正を安全に進められるようになります。
ブランチの基本的な考え方
mainブランチという「本線」
Gitのリポジトリを作ると、最初にmainブランチ（かつてはmasterという名称が主流でしたが、近年はmainが標準）という1本のブランチが自動的に用意されます。
これが、先ほどの比喩でいう「清書」にあたる、プロジェクトの本線です。
チーム開発では、このmainブランチには「常にきちんと動くコード」だけを置いておき、開発中の変更は別のブランチで進めるのが基本的な運用ルールになります。
作業ブランチを作るタイミングの目安
実務では、次のようなタイミングで新しいブランチを作ることが多いです。
- 新機能を追加するとき（例：
feature/login-formのような名前） - バグを修正するとき（例：
fix/header-layoutのような名前） - 実験的な変更を試したいとき
ブランチ名に用途がわかる接頭辞（feature/やfix/など）を付けておくと、後から見返したときに、それが何のための下書きだったのかがひと目でわかります。
よくあるつまずきポイント
Before/After：mainブランチで直接実験してしまう
Gitを学び始めたばかりの頃、私はブランチの存在を知りながらも、面倒に感じてmainブランチのまま新機能の実装を進めてしまうことがよくありました。
ある日、その状態で大きな機能追加を試みたところ、想定外のエラーが連鎖して、動いていたはずの画面まで表示されなくなってしまいました。
mainブランチが壊れた状態のまま、元に戻す方法もわからず、かなり焦った記憶があります。
❌ Before：思いついたらすぐmainブランチのままコードを書き換える
✅ After：新しい機能に着手する前に、まず作業用のブランチを作ってから作業を始める
# 現在のブランチを確認する（先取り紹介、詳細は次回）
git branch
# 出力例：現在いるブランチに * が付く
# * main
mainブランチを常にきれいな状態に保つ習慣さえあれば、あの日のようなトラブルがあっても、mainブランチ自体には影響がなく、作業用のブランチを作り直すだけで済んだはずです。
応用・一歩先の使い方
複数のブランチを並行して使う
慣れてくると、1つのプロジェクトの中で、複数のブランチを同時に使い分けるようになります。
例えば、「ログイン機能のブランチ」で作業しながら、急ぎのバグ報告が来たら、いったんそちらを中断して「バグ修正用のブランチ」に切り替えて対応する、といった進め方が一般的です。
まさに、複数の下書きを机の上に並べて、必要なものから手を付けていくようなイメージです。
次回予告：ブランチの作成・切り替え
今回はブランチの考え方に絞って解説しましたが、次回の記事では、実際にgit branch・git switch・git checkoutといったコマンドを使って、ブランチを作成・切り替える具体的な手順を解説します。
まとめ
この記事のポイント
- ブランチは、本線を壊さずに別の紙で下書きするような、変更履歴を分岐させる仕組み
mainブランチは常に安定して動く状態を保つのが基本ルール- 新機能やバグ修正には、用途がわかる名前の作業ブランチを作ってから着手する
mainブランチで直接作業すると、トラブル時の被害が本線に直接及んでしまう
次に読むべき記事
- ブランチの作成・切り替え（git branch・switch・checkout）
- git mergeでブランチを合流させる基本
タグ: Git, 初心者向け, ブランチ