ITワクワク塾ブランチとは？作業を枝分かれさせて、あとで合わせる仕組み
Gitの版：2.56.0
新しい機能を試している途中で、急ぎの修正を頼まれることがあります。試作の変更と急ぎの修正が混在しないよう、作業の流れを分けておく仕組みがブランチです。
本記事では、Gitの公式ドキュメントと『Pro Git』をもとに、ブランチの正体と、分けた作業を合わせるマージの仕組みを解説しましょう。
ブランチとは
ブランチは、コミットの履歴を枝分かれさせ、別々の作業の流れを並行して進めるための仕組みです。
「枝」と聞くと、ファイルを丸ごと別のフォルダーに写すように思えるかもしれません。『Pro Git』によると、Gitのブランチの正体は、コミットの1つを指す、軽くて動かせる目印です。作るときは、指す先のコミットのハッシュ（40文字）と改行の41バイトをファイルに書くだけなので、一瞬で済みます。
今どのブランチで作業しているかを指すのは、HEAD という特別な目印です。新しくコミットすると、HEAD が指しているブランチの目印が、新しいコミットへ進みます。
最初のブランチの名前
リポジトリを作ると、最初のブランチが1つできます。Gitは何も指定しなければ master という名前で作りますが、『Pro Git』の説明では特別なブランチではありません。名前は設定（init.defaultBranch）で変えられ、main などの名前にしているサービスやプロジェクトもあります。
ブランチを合わせるマージ
分けた作業を最後に1つのブランチへ合わせる操作を、マージ（merge）と呼びます。状況によって、その形は2つです。
合わせる先のブランチが、枝分かれのあと進んでいなければ、目印を先へ進めるだけで済みます。これが早送り（fast-forward）で、新しいコミットは作られません。
両方のブランチが進んでいる場合、Gitは2つのブランチの先端と、枝分かれした地点のコミットを使って変更を合わせます。その結果は、前のコミットを2つ持つマージコミットとして記録される仕組みです。
コンフリクトが起きたら
2つのブランチが、同じファイルの同じ箇所を別々に書き換えていると、Gitはどちらを採るか決められません。この状態が、コンフリクト（衝突）です。
コンフリクトが起きると、Gitはマージを途中で止め、ぶつかった箇所に両方の内容を印付きで書き込みます。人がファイルを開いて正しい内容に直し、git add と git commit を実行すれば、マージは完了です。どちらの変更を残すかは中身を読んで判断することなので、機械的にどちらかを選ぶのは避けましょう。
プルリクエストとの関係
GitHubやGitLabのようなサービスでは、マージの前に、変更を見てもらう手順を挟めます。GitHubではプルリクエスト、GitLabではマージリクエストという名前です。
GitHubのドキュメントは、プルリクエストを「コードの変更をマージする提案」と説明していました。ブランチ間の差分を画面に表示し、レビューやコメントを経てから、マージするかどうかを決めます。プルリクエストはGitそのものではなく、サービスが用意している機能です。
製品での使われ方
ブランチとマージはGitの機能なので、どのサービスでも同じ考え方で使えます。サービスでは、マージの基準になるブランチ（既定のブランチ）を決め、作業用のブランチからプルリクエストを出す使い方が一般的です。
プログラミング用のAIエージェントに作業を任せるときも、ブランチを分けておきましょう。AIの変更を作業用のブランチにまとめておけば、内容を確かめてからマージでき、気に入らなければブランチごと捨てられます。ブランチを分けたら、手元の変更をプッシュして、プルリクエストで差分を確かめてからマージするとよいでしょう。