ブランチとは何か

コミット履歴は一本の線

前の章までで、コミットを積み重ねて履歴を作ることを学びました。

この履歴はまっすぐ一本の線のようなものです。

一人で順番に作業しているうちは、これで問題ありません。

しかし、実際の開発ではこんな状況が起こります。

一本道だと困るケース

Webサイトを作っているとします。あなたは「ログイン機能」を開発中です。まだ作りかけで動かない状態です。

そこに「ヘッダーのロゴがずれている」というバグ報告が来ました。すぐ直したいのですが...

• ログイン機能のコードが 作りかけのまま混ざっている
• バグ修正だけをきれいに切り出せない
• バグ修正を公開すると、動かないログイン機能まで一緒に公開されてしまう

コミット履歴が一本の線だと、複数の作業が混ざってしまいます。

このような場合に、 ブランチを分岐して 作業を行うことが一般的です。

ブランチ＝履歴を枝分かれさせる仕組み

ブランチ（branch） は、コミット履歴を枝分かれさせる仕組みです。英語で「枝」という意味です。

先ほどの一本道の履歴から、新しいブランチを作ると もう一本の線が分岐 します。

こうすると、それぞれのブランチが 独立した作業スペース になります。
メインのブランチは常にバグがなく安定した状態にするのが望ましいです。

画像のように目的ごとにブランチを分けて作業します。ログイン機能が作りかけでも、バグ修正ブランチには影響しません。バグ修正だけを先に完成させることもできます。

ブランチの作成と切り替え

ブランチを作っただけでは、まだ元の場所で作業しています。作業するブランチを 切り替える ことで、そのブランチの世界に移動します。

切り替えると、ファイルの内容がそのブランチの状態に変わります。main に戻したいときは git switch main で戻れます。

マージ（合流）

ブランチでの作業が完了したら、本流（main）に マージ（merge） して統合します。

マージは 取り込む側のブランチ に切り替えてから実行します。login ブランチの変更を main に取り込みたい場合は、まず main に移動します。

マージすると、ブランチで行ったすべての変更が main に取り込まれます。

ブランチを使った開発の流れ

実際の開発では、以下の流れを繰り返します。

1つの機能や修正ごとにブランチを作り、完了したらマージして戻す。この繰り返しで、main を常に安定した状態に保ちながら開発を進めます。

ローカルマージの落とし穴

ここまで紹介したマージは、自分のPC上で直接 main にマージするやり方です。一人で開発しているうちはこれでも問題ありません。

しかし、チームで開発する場合はどうでしょう？

• 誰かが気づかないうちにバグのあるコードを main にマージしてしまうかもしれない
• どんな変更がマージされたのか、他のメンバーが把握できない
• 「このコード、なぜこう書いたの？」と後から聞くこともできない

こうした問題を解決するのが、次の章で紹介する プルリクエスト です。

セクションまとめ