ブランチ

まずこれだけ

ブランチは、元の状態を直接こわさずに、別の変更を試すための作業場所です。Git（ギット） では、いま公開されている内容や本流の内容を保ったまま、「この文章を直す」「新しいページを追加する」「設定を試す」といった作業を分けて進められます。難しい操作に見えますが、考え方としては「本番の資料に直接書き込まず、確認用の作業版を作る」に近いです。

どこで見かけるか

GitHub（ギットハブ） で変更を始めるとき、「ブランチを切る」「新しいbranch（ブランチ）で作業する」「main（メイン）にマージする」といった言い方で出てきます。リポジトリ の画面に main や feature/... のような名前が表示されることもあります。多くのチームでは、直接本流に書き込まず、作業用ブランチで変更してから プルリクエスト で確認します。

具体例

研究会サイトの用語説明を直す場合、公開中の内容が入っている本流をそのまま残し、glossary-update のようなブランチを作って文章を編集します。そのブランチで何度か コミット し、内容がまとまったらプルリクエストを出します。確認が終わってから本流へ取り込むので、途中の書きかけや失敗がすぐ公開される心配を減らせます。

つまずきやすいところ

ブランチは単なるフォルダのコピーではありません。Git（ギット） が「どこから分かれたか」「どの変更が加わったか」を履歴として覚えています。そのため、同じファイルを複数人が別々に直すと、あとでどちらを採用するか相談が必要になることがあります。これを衝突と呼びますが、壊れたという意味ではなく、確認すべき箇所が見つかったという合図です。

研究会では

サイトや文章を直すときに、まずブランチを作って作業する流れがよく出ます。作業の区切りは コミット、見てもらう場は プルリクエスト です。「履歴を残しながら別案を試し、相談してから取り込む」ための道具だと捉えると、共同作業の不安がかなり減ります。