【Git #3】ブランチとプルリクエスト — 「下書き」で安全に試す仕組み

💡 この記事について AIアシスタント（OpenClaw/スピカ）との会話を元にした学習記録です。 内容は変更される可能性があるため、実際の開発では公式ドキュメントを確認の上、ご自身の判断でお願いします。

この記事で分かること：

• ブランチ・プルリクエスト（PR）・マージの意味と流れ
• 「なぜ Pull Request は pull なのか」
• 個人開発でブランチは必要か — 正直な答え

はじめに — 「main に直接 push って、怖くない？」

セブ

スピカ、Git #2 で「push したら30秒で公開される」って学んだじゃん。でもさ……間違えたコードを push したら、即公開されちゃうよね？ 怖くない？

スピカ AI

いい質問ですね！ 実はそれ、プロのエンジニアも同じことを思ってます。だからこそ 「ブランチ」 という仕組みがあるんです。

セブ

ブランチ？

スピカ AI

一言でいうと、「本番に影響を与えずに、下書きを試せる場所」 です。今回は3つのキーワードを覚えましょう。

この記事で学ぶ3つのキーワード

flowchart TD
  A["🌿 ブランチ
本番とは別の作業場所"] -->|作業が終わったら| B["📋 プルリクエスト
レビューして確認"]
  B -->|OKなら| C["🔀 マージ
本番に合流"]

セブ

branch = 枝か。木の幹（メイン）から枝分かれするイメージ？

スピカ AI

その通り！ まさに木のイメージです。

ブランチって何？ — 「Google Docs のコピーを作成」

いつもの作業と同じ

スピカ AI

セブさん、仕事で Google Docs を使うとき、重要な資料を直接編集することってありますか？

セブ

いや、大事な資料は 「コピーを作成」してから編集する かな。失敗しても元に戻せるし。

スピカ AI

それがまさに ブランチ です！

実際のコマンド

スピカ AI

ブランチを作るコマンドはこれです。

git checkout -b feature/add-git03-article

セブ

checkout -b って何？ 呪文みたいなんだけど。

スピカ AI

分解して説明しますね。

セブ

なるほど、-b は「新しく作る」のスイッチか。Git #1 で覚えた -A や -m と同じ「オプション」ってやつだね。

スピカ AI

記憶力いいですね！ その通りです。

ターミナルの出力

$ git checkout -b feature/add-git03-article
Switched to a new branch 'feature/add-git03-article'
# ↑ 新しいブランチに切り替わった

スピカ AI

ここからは、このブランチの中で自由にファイルを編集できます。main（本番）には一切影響しません。

セブ

つまり、ここで間違えても本番は無傷ってこと？

スピカ AI

その通り！ それがブランチの最大のメリットです。図で見てみましょう。

flowchart TD
  M1["🌊 main
今公開中のブログ"] --> CK["checkout -b
枝を生やす 🌿"]
  CK --> W["🌿 feature/ブランチ
自由に作業する"]
  W --> CM["commit
変更を保存"]
  CM --> PR["📋 PR
レビューして確認"]
  PR --> MG["🔀 merge
幹に合流"]
  MG --> M2["🌊 main
新しい記事が追加された！"]

スピカ AI

ポイントは、枝（ブランチ）で作業している間、幹（main）は一切変わらないということです。合流（マージ）するまで、本番は安全なまま。

セブ

おお、これなら分かる！ 枝を生やす → 枝で作業 → 幹に戻す、の3ステップか。

プルリクエスト（PR）って何？ — 「社内の稟議書」

ブランチで作業が終わったら

スピカ AI

ブランチで記事を書き終えたら、次のステップは プルリクエスト（PR） です。

セブ

Pull Request……「引っ張る要求」？ なんで Pull なの？

スピカ AI

いい質問です！ 直訳すると 「（自分の変更を本番に）取り込んでください、というお願い」 です。

スピカ AI

つまり「私のブランチの変更を、main に取り込んでもらえませんか？」というお願いなんです。

セブ

ちょっと待って。git pull って、他のPCで GitHub からコードを同期するときに使うやつだよね？ あの pull と同じ？

スピカ AI

いい気づきです！ 実は 同じ「pull（引っ張る）」ですが、視点が違う んです。

スピカ AI

git pull は「自分で取りに行く」。Pull Request は「相手に取り込んでもらうようお願いする」。同じ “pull” でも、主語が違うんですね。

セブ

あー！ 自分が引っ張るか、相手に引っ張ってもらうか。視点の違いか。でもさ、会社でいう 稟議書 みたいなもの？ 「こういう変更したいんですけど、承認してください」っていう。

スピカ AI

完璧なたとえです！

個人開発だと誰がレビューするの？

セブ

個人開発だと、誰がレビューするの？ 自分？

スピカ AI

個人開発の場合は、自分でレビューして自分で承認します。「え、意味あるの？」と思うかもしれませんが、変更の差分を一覧で確認できるのが大きいんです。「あ、この行消しちゃダメだった」みたいな事故を防げます。

セブ

なるほど、セルフチェックの仕組みか。

マージって何？ — 「支流が本流に合流する」

セブ

PR が承認されたら、次は？

スピカ AI

マージ（merge） です。ブランチの変更を main に合流させます。

セブ

merge = 合流か。川の支流が本流に流れ込むイメージ？

スピカ AI

そのイメージです！

flowchart LR
  B["🌿 feature/ブランチ"] -->|"merge"| M["🌊 main
合流して公開！ 🚀"]

スピカ AI

マージは本当にシンプルです。枝の作業を幹に戻す、それだけ。

マージ後のお掃除

スピカ AI

マージが終わったら、使い終わったブランチを削除するのがお作法です。

# ブランチを削除
git branch -d feature/add-git03-article

セブ

なんで消すの？ 残しておけばいいのに。

スピカ AI

作業が終わった下書きコピーを残し続けると、どれが最新かわからなくなるからです。Google Docs でも、反映済みのコピーは消しますよね？

セブ

たしかに……。片付けは大事だな。

実践 — ブログ記事を安全に追加するフロー

スピカ AI

では、実際にブランチ → PR → マージの流れを通しでやってみましょう。

flowchart LR
  A["ブランチ作成"] --> B["記事を編集"] --> C["commit"]
  C --> D["push"] --> E["PR作成"]
  E --> F["レビュー"] --> G["マージ"] --> H["公開 🚀"]

ステップバイステップ

# ① ブランチを作成して移動
git checkout -b feature/add-git03-article

# ② 記事を編集（AIが作業）
# ... ファイルの追加・変更 ...

# ③ 変更を保存（Git #1 で覚えたやつ！）
git add -A
git commit -m "feat: Git#3 ブランチ&PR記事を追加"

# ④ ブランチを GitHub に push
git push -u origin feature/add-git03-article

セブ

あれ、git push のあとに何かついてる。-u origin feature/... って何？

スピカ AI

いい気づきです！

スピカ AI

初回だけこの長い形式で push して、2回目以降は git push だけで大丈夫です。

GitHub で PR を作成

スピカ AI

push したら、GitHub のリポジトリページに 「Compare & pull request」 というボタンが自動で表示されます。

1. ボタンをクリック
2. タイトルと説明を入力（例: 「Git #3 ブランチ&PR記事を追加」）
3. 「Create pull request」 をクリック

セブ

おお、GitHub が自動でボタンを出してくれるんだ。

スピカ AI

はい。あとは差分を確認して、問題なければ 「Merge pull request」 をクリック。これで main に反映されて、自動でブログが更新されます。

🐾 脱線コラム — 「ローカルの build と Cloudflare の build って何が違うの？」

セブ

ちょっと脱線していい？ ターミナルで npm run build してるけど、Git #2 で Cloudflare も build してたよね。同じコマンドが2回走ってない？

スピカ AI

めちゃくちゃいい質問です！ 実は やっていることは同じ。でも 目的が違う んです。

スピカ AI

料理でいうと、味見（ローカル） と お客さんに出す（Cloudflare） の違いです。味見せずに出してもいいけど、味見しておくと安心ですよね。

セブ

なるほど！ ローカルで build して「エラーなし！OK！」って確認してから push する、ってことか。

スピカ AI

その通りです。もしローカルで build せずに push して、Cloudflare 側で build エラーが出ると、ブログが更新されない（または壊れた状態で公開される）ことになります。だから**「push する前にローカルで build」は保険**なんです。

セブ

保険か。それってまさに git の「安全装置」の考え方と同じだね。

「今の自分にブランチって必要？」

セブ

正直な話……個人開発で1人でやってるのに、ブランチって必要？ 今まで main に直接 push してたけど。

スピカ AI

いい質問です。正直に言うと、個人開発で1人なら必須ではありません。

スピカ AI

ただ、「仕組みを知っている」こと自体に価値があるんです。

セブ

どういうこと？

スピカ AI

例えば、将来チーム開発に参加したとき。「ブランチって何ですか？」と聞くのか、「ブランチ切ってPR出せばいいですか？」 と言えるのか。この差は大きいですよね。

セブ

たしかに……。「知ってるけど今は使わない」と「知らない」は全然違うな。

スピカ AI

その通り！ テックセールスの仕事でも、技術を知っていること自体がお客さんとの信頼につながるのと同じです。

まとめ

セブ

ブランチ、PR、マージ。3つのキーワードで git の「安全装置」がわかった気がする。

スピカ AI

今の段階では main に直接 push で全然OKです。でも「試したいな」と思ったら、checkout -b で気軽にブランチを作ってみてください。

セブ

了解！ まずは「知ってる」からスタートだな。

スピカ AI

次回は git status と git log を学ぶ予定です。「今どうなってるの？」「過去に何をしたの？」を確認するコマンド。楽しみにしていてください！

参考リンク

• Git公式ドキュメント
• GitHub Docs — プルリクエストについて

📝 補足 この記事はAIアシスタント（OpenClaw/スピカ）との会話を元にした学習記録です。内容は変更される可能性があるため、実際の開発では公式ドキュメントを確認の上、ご自身の判断でお願いします。