定義
コードを管理するツール「Git（ギット）」において、メインの歴史の流れから分岐して作られる作業スペースのことです。これまでの記録をそのまま引き継いだ場所から新しい作業を進められます。元の本線には手を加えないまま残るため、うまくいかなくてもいつでも安全に戻ることができます。
原本ノートは残し、コピーした別冊で試してみる
クラスのみんなで文集を作っている場面を想像してみてください。1冊のノートにみんなで文章を書き込んでいます。そんなとき、新しい物語を試しに書いてみたくなったらどうするでしょうか。
原本のノートにいきなり書き始めると、気に入らなかったときに困ったことになります。消したり上書きしたりした跡が残り、それまでのページまで汚れてしまうからです。そこで、今まで書いたページをそのままコピーして新しい別冊ノートを作り、そこへ自由に書いてみることにします。
Gitでは、このコピーした作業スペースを「ブランチ（枝）」と呼びます。作った瞬間は原本とまったく同じ内容ですが、その後に書いた内容はすべてこの別冊にだけ記録されます。原本には手を触れないまま綺麗な状態で残るのです。
実は、原本の役割を果たしている本線もブランチの1つです。一般的には「メインブランチ」と呼ばれ、みんながこの本線を完成版と見なして作業を進めます。
みんなで分担して書き、終わったら貼り合わせる
文集を1人で作るわけではありませんよね。何人もの仲間がそれぞれ別冊ノートを持ち寄り、別々の記事を書きます。隣の人が何を書いていようと、自分の別冊ノートが影響を受けることはありません。
1人が自分の担当分を書き終えたら、その文章を原本のノートへ貼り合わせます。Gitでは、このように枝分かれした作業を元の本線へと合流させることを「マージ（統合）」と呼びます。この瞬間から、その文章は全員の完成版に組み込まれます。
問題になるのは、2人が同じ文章の同じ箇所を別々に書き換えて持ち寄ったときです。一方が文章を長く書き足し、もう一方がまるごと削除していた場合、どちらを残すべきか人間が判断しなければなりません。このように人の手で解決が必要な状態を「コンフリクト（衝突）」と呼びます。同じファイルでも離れた場所の変更であればGitが自動でうまく合流させてくれますが、変更箇所が隣接していると衝突と判断されて確認を求められます。
そのため、別冊ノートに長く溜め込みすぎると合流させるときに苦労します。その間に原本が大きく変わってしまうからです。小さく分けてこまめに合流させることが、一番スムーズに進めるコツです。
もう少し正確に言うと
Gitは実際には、ノート丸ごとを複製しているわけではありません。ブランチとは「この流れの最新地点はここだよ」と指し示す1枚の名札のようなものです。作業が1ページ進むたびに、その名札が新しいページへと移動していくだけなのです。
そのため、ブランチを作るのに時間はほとんどかかりません。新しい名札を1枚ペタッと貼るだけだからです。1日にいくつも作っては、用が済んだら消すという使い方が日常茶飯事です。
混同しやすい概念に「コミット」があります。コミットはその時々の状態を記録した「ノートの1ページ」です。ブランチは、そのページが連なった「流れにつけられた名前」です。
ですから、ブランチを難しく考える必要はありません。原本に戻れる目印を残したまま、そこから枝分かれして安心して色々試すための仕組みなのです。
よくある誤解
ブランチを作るとプロジェクト全体のフォルダが複製され、その分保存容量を消費する。
ブランチは履歴の先端を指す名札のようなものです。新規作成時にファイル全体がコピーされるわけではないため、作成や削除の負担はごくわずかです。
ブランチで作業すると、元の本線のコードもリアルタイムで書き換わる。
分岐した後の作業履歴はそのブランチだけに蓄積されます。元の本線に反映させるには「マージ」という統合手順を明示的に行う必要があります。
日常で出会う場面
ネット通販アプリに新しい決済画面を追加する際、現在稼働中のコードには触れず、作業用の枝を1つ作ってその中だけで変更を試す。
画面の表示崩れの報告が入った際、緊急修正用のブランチを一時的に作って直し、テスト後に本線へ合流させる。
つまり ひとことで
これまでの記録を受け継いで枝分かれさせた作業スペースなので、元のコードを壊す心配なく、新しい作業を気兼ねなく試すことができます。