ブランチとmain——なぜ作業場所を分けるの？

ブランチは変更の流れを分けるもの

「ブランチ」は英語で枝という意味です。Gitでは、変更の履歴を分けて進めるための名前として使います。たとえば、サイトの基準となる履歴から「新しい記事を作る流れ」を分け、そこで変更を重ねるイメージです。

同じ地点から分かれた後は

枝を分けた時点では、それまでの履歴は共通しています。その後、一方のブランチでコミットすると、そのブランチ側の履歴が進みます。もう一方のブランチが、同じ変更を自動的に取り込むわけではありません。

コツエイゴでAIページの見出しを直したいとします。基準のブランチから見出し修正用のブランチを作り、そのブランチ上で編集・コミットすれば、基準側とは区別して作業できます。別の作業も別の流れとして進められます。

フォルダと同じもの？

ブランチを「別のフォルダが必ずもう一つできるもの」と考える必要はありません。同じ作業環境でブランチを切り替えて作業する方法もあれば、別の作業場所を用意する方法もあります。どの環境で何が起きるかは使い方によって異なります。

まずは名前を確認する

ここで大事なのは、ブランチは変更を分けて考えるための目印だということです。りんが「この修正はどのブランチで進めたの？」と聞ければ、ChatGPTの報告を読み解く第一歩になります。

名前には `fix/ai-heading` のように作業内容を表す言葉を使うことがあります。これは説明用の例で、名前自体が修正を実行するわけではありません。どの変更が含まれているかは、履歴や差分を見て確認します。

例えば同じ見出しから出発しても、記事本文を直すブランチと、ボタンを直すブランチに分ければ、どちらに何を記録したかを追いやすくなります。後で一緒にする場合も、それぞれの内容を確認できます。

なるほど！ まずは何が起きているか、ひとつずつ確かめればいいんだね。

mainと作業ブランチは何が違う？

多くのGitHubリポジトリでは、中心となる既定のブランチの名前が `main` です。GitHubでリポジトリを作ったときに標準で使われる名前ですが、既定のブランチは変更でき、別の名前を使うプロジェクトもあります。

作業用に流れを分ける

この学習ノートでは、mainをサイトの基準となる変更をまとめる流れとして考えます。一方、記事追加や表示の修正を進めるために分けたものを、ここでは「作業ブランチ」と呼びます。作業ブランチは役割を表す呼び方で、名前は作業ごとに異なります。

例えば、公開中のサイトに近い状態をmainに置き、「見出しを修正する」という作業を別のブランチで進めることがあります。途中の変更を確認し、必要な準備が整ってから、mainへ取り込むか判断できます。

mainに入ったら必ず公開？

ただし、mainにあることと、本番サイトで公開済みであることは同じではありません。mainへの変更をきっかけに自動公開するサイトもあれば、別の操作で公開するサイトもあります。mainに取り込んだときの影響は、各サイトの設定で確認しましょう。

コツエイゴでは

コツエイゴでは、作業ブランチへの保存、mainへの反映、本番公開を別の段階として扱います。ほかのサイトが同じ手順とは限らないため、ChatGPTに「このサイトのmainは何を基準にしていて、どう公開される？」と尋ねてみましょう。

mainも特別な魔法の保存先ではなく、Gitのブランチの一つです。名前だけで安全性や公開状態が決まるのではなく、そのプロジェクトの設定や運用が役割を決めます。

作業ブランチへの保存とmainへの反映

前の記事までに、コミットは変更のまとまりをGitの履歴に記録し、pushはその記録をGitHubなどへ送る操作だと学びました。ブランチを使う場合も、この2つは別々です。

pushしてもmainとは限らない

たとえばChatGPTが「作業ブランチにコミットし、GitHubへpushしました」と報告したとします。変更の記録は作業環境とGitHubの作業ブランチにありますが、それだけでmainにも取り込まれたとは言えません。

「ブランチに保存」の場所

「ブランチに保存」という表現だけでは、作業環境の中だけを指すのか、GitHubまで送信したのか曖昧なことがあります。「どこでコミットした？ GitHubのどのブランチへpushした？」と分けて聞くと、場所がはっきりします。

確認してから取り込む

mainに取り込む方法の一つが、変更を確認してから統合する方法です。GitHubではプルリクエストという仕組みを使うことがありますが、すべてのサイトで同じ方法が必要なわけではありません。具体的な仕組みは次の記事で学びます。

公開も別に確かめる

また、mainに取り込んだ後に本番公開する流れなのか、mainの更新で自動的に公開されるのかは設定次第です。保存済み・main反映済み・公開済みを一つにまとめず、それぞれの状態を確認しましょう。

もし「変更は作ったがpushは失敗した」と報告されたら、コミット自体は作業環境に残っているかもしれません。失敗した工程と、確認できた状態を聞いてから次の操作を決めます。分からないまま同じ操作を繰り返さないことも大切です。

ChatGPTの報告を読んで確かめよう

「見出しを修正し、作業ブランチ `fix/ai-heading` にコミットしてGitHubにpushしました。mainには反映していません」。これは説明用の一つの報告例です。作業ブランチに変更は記録され、GitHubにも送られています。mainへの反映はまだです。

「公開していない」も矛盾しない

この報告に「本番公開していません」が続いても矛盾しません。変更の記録や送信ができていても、本番サイトへの反映は別の状態だからです。実際の公開状態が書かれていなければ、推測せず質問しましょう。

質問を3つに分ける

最初の質問は「どのブランチで作業した？」です。名前が分かれば、どの変更の流れを見ているか確認できます。続いて「GitHubに送った？」「mainに取り込んだ？」と聞くと、作業場所と反映先を分けられます。

公開と確認結果も聞く

さらに「本番サイトには反映された？ 何を確認した？」と聞けば、公開の有無と確認の結果も分かります。成功したことだけでなく、失敗したことや未確認のことも報告してもらいましょう。

知らない名前が出たら

もし予想していないブランチ名が出てきても、すぐに削除ややり直しを頼む必要はありません。「そのブランチに何が入っていて、ほかの作業と関係する？」と聞き、状態を把握してから判断します。

ブランチを分けることで、変更の流れを整理しやすくなります。次の記事では、作業ブランチの変更を確認し、mainへまとめる際に登場するプルリクエストとマージを見ていきます。

難しい名前は覚えなくて大丈夫です。報告に出た名前をそのまま示し、「これは作業ブランチ？ main？」と一つずつ聞いてみましょう。