【Git】ブランチ（Branch）

ブランチ（Branch）とは、Gitにおいて、開発の流れを枝分かれさせる仕組みのことです。「branch（枝）」という英単語のとおり、大元の流れから分岐した作業場所を作ることで、本体に影響を与えずに変更を試せるようになります。

現実世界に例えると、ブランチは書きかけの原稿をコピーして、別のノートで書き直してみるようなものです。元の原稿はそのまま残っているので、うまくいけば反映し、失敗すればノートごと捨てれば済みます。

基本的な仕組み

Gitのリポジトリには、通常「main」（または「master」）と呼ばれる中心となるブランチがあります。新しい機能を作るときや不具合を直すときは、ここから枝分かれさせた作業用のブランチを作り、その中で変更を重ねていきます。作業中の中途半端な状態がmainに混ざらないため、いつでも動く状態を保てます。

なぜブランチを分けるのか

複数の開発者が同じファイルを同時に触ると、変更が衝突して収拾がつかなくなります。ブランチを分けておけば、それぞれが独立して作業を進められます。また、途中まで作った機能を一旦止めて別の急ぎの修正に取りかかる、といった切り替えも簡単に行えます。

マージという合流作業

作業用ブランチでの変更が完成したら、それをmainへ取り込みます。この合流作業をマージと呼びます。多くの現場では、いきなりマージするのではなく、プルリクエスト（マージリクエスト）を作ってレビューを受けてから取り込む流れが取られています。

コンフリクトへの対処

複数のブランチで同じ箇所を別々に書き換えていた場合、マージ時にコンフリクト（衝突）が発生します。Gitはどちらを採用すべきか判断できないため、開発者が手作業でどちらを残すか決める必要があります。こまめにmainの変更を取り込んでおくと、衝突の規模を小さく抑えられます。

代表的なブランチの使い分け

ブランチ戦略という考え方

チームでブランチをどう運用するかの決めごとを「ブランチ戦略」と呼びます。厳格に役割を分ける「Git Flow」や、mainと作業ブランチだけのシンプルな「GitHub Flow」などが知られています。チームの規模やリリースの頻度に合わせて選ぶことが大切で、小さなチームに複雑な戦略を持ち込むと、かえって手間が増えます。

ブランチ名の付け方

ブランチ名には、何のための作業かが分かる名前を付けます。多くの現場では「feature/」「fix/」のような接頭辞を付け、その後に内容を続ける書き方が使われています。一覧で見たときに目的が判別できることが目的なので、日付だけや個人名だけの名前は避けたほうが無難です。

作業が終わったら削除してよい

マージが済んだ作業用ブランチは、基本的に削除して構いません。変更の内容はマージによってmainの履歴に残っているためです。使い終わったブランチを残し続けると一覧が見づらくなるので、こまめに整理する運用が一般的です。

あわせて知っておきたい用語

• Git：
  ソースコードの変更履歴を記録・管理するための、バージョン管理システムです。
• マージ：
  枝分かれしたブランチの変更内容を、別のブランチへ合流させる操作です。
• プルリクエスト：
  変更をマージする前に、他のメンバーへレビューを依頼する仕組みです。
• 【Git】コミット：
  ファイルへの変更内容を、記録として保存する操作のことです。