- 投稿日：2026/04/08
ブランチとプルリクエストって何？
GitやGitHubを使い始めると、「ブランチ」「プルリクエスト（PR）」という言葉が出てきます。
チーム開発のための機能というイメージを持つ人も多いですが、Claude Codeを使った個人開発でも活用する場面があります。
この記事では、仕組みの基本から、スマホでPRをマージした後に必要な作業、そして個人開発でブランチを使うことのメリット・デメリットまでをまとめて解説します。
※この記事ではGitのコミット・プッシュの基本知識がある方を前提にしています。
Git管理の基本については別記事をご覧ください。
Claude CodeでGitを使うべき理由と基本の始め方
Claude Codeの作業をGitHubで管理しよう｜バックアップ＆スマホ連携への第一歩
ブランチとは「作業用のコピー」のこと
まずブランチの概念から整理します。
Gitで管理しているプロジェクトには、メインとなる本体のブランチ（通常「main」または「master」と呼ばれます）があります。
ブランチとは、この本体から「枝分かれした作業スペース」のことです。
わかりやすい例えで言うと、「本原稿のコピーを作って、そこに赤ペンで修正を加える」イメージです。
コピーを編集している間、本原稿はそのまま残っています。
修正内容がOKだったら、本原稿に反映させる。
ダメだったらコピーを捨てればいい。
これがブランチの基本的な考え方です。
プルリクエスト（PR）とは「変更をマージしてください」という申請
ブランチで作業した内容を、本体のブランチ（main）に取り込むことを「マージ」と言います。
プルリクエスト（PR）は、GitHubの機能で「このブランチの変更をmainに取り込んでいいですか？」という申請を出す仕組みです。
チーム開発では他のメンバーがレビューしてからマージしますが、個人開発の場合は自分で内容を確認してマージします。
スマホからPRをマージした後に必要な作業
前回のスマホ操作の記事では、ClaudeアプリのCode画面からPR作成ボタンを押すと自動的にブラウザのGitHubページが開き、そこでマージボタンを押す、という流れを紹介しました。
ここで多くの人がハマりやすいポイントがあります。
マージしてもPCのファイルはまだ変わっていない
GitHubでPRをマージするということは、GitHub上（クラウド）のmainブランチが更新されたということです。
しかし、あなたのPC上のファイルは、まだ古いままです。
GitHubとPCのローカルは別々の場所にあるため、GitHub側が更新されても、PC側には自動的には反映されません。
PCに反映させるには「プル」が必要
PC側を最新の状態に更新するには、「プル（pull）」という操作が必要です。
ClaudeデスクトップアプリのCode画面であれば、チャット欄に以下のように入力することで実行できます。
「git pull してください」
これをClaude Codeに頼むと、GitHubから最新の状態をPC側に取り込んでくれます。
ターミナル版の場合は、ターミナルで「git pull」と入力して実行します。
流れをまとめると
スマホで作業
→スマホからPR作成
→GitHub上でマージ
→PCでプル（pull）を実行
→PC側に反映される
この最後の「PCでプル」を忘れると、PCで作業したときに古いファイルをベースにしてしまい、内容がぐちゃぐちゃになるリスクがあります。
必ずセットで覚えておいてください。
個人開発でブランチを使うメリット
それでは、Claude Codeに作業させる個人開発の場面で、ブランチを使うとどんなメリットがあるのかを見ていきます。
メリット① 失敗してもmainが壊れない
Claude Codeに大きな変更を依頼するとき、うまくいかないことがあります。
ブランチを使っていれば、そのブランチを捨ててしまえばmainは無傷のままです。
「やっぱりやり直し」が安全にできます。
ブランチを使わずにmain直接で作業していると、大きな変更が失敗したとき、もとに戻すのが大変です。
メリット② 変更内容がPRで見やすくなる
GitHubでPRを作成すると、mainから何が変わったか（差分）が一覧で確認できます。
Claude Codeが大量のファイルを変更したとき、「いったい何を変えたんだろう？」とブラックボックスになりがちですが、PRの差分画面を見ることで変更内容を把握しやすくなります。
メリット③ 作業のまとまりが明確になる
「ログイン機能の追加」「デザインの修正」など、機能や目的ごとにブランチを切る習慣をつけると、プロジェクトの変更履歴が整理されます。
あとで「あの機能を追加したのはどのタイミングだっけ？」と振り返るときに役立ちます。
個人開発でブランチを使うデメリット
ブランチには便利な面がある一方で、デメリットや注意点もあります。
デメリット① 手順が増えて少し面倒
ブランチを使う場合、作業のたびに「ブランチを作る→作業→プッシュ→PR作成→マージ→プル」という流れが発生します。
mainに直接プッシュする場合に比べて手順が多く、慣れるまでは煩わしく感じることがあります。
デメリット② ブランチの管理が必要になる
使い終わったブランチはこまめに削除しないと、どんどん増えて管理が煩雑になります。
PRをマージしたら、そのブランチは削除する習慣をつけるのがおすすめです。
GitHubのPRマージ画面に「ブランチを削除」ボタンが表示されるので、マージ直後に押しておくとよいです。
デメリット③ ブランチが古くなる問題（コンフリクト）
複数のブランチを同時に進めていると、mainが更新された状態で古いブランチをマージしようとすると「コンフリクト（競合）」が発生することがあります。
個人開発では複数ブランチを同時進行することはあまり多くありませんが、知識として覚えておくと安心です。
個人開発での現実的な使い方
毎回必ずブランチを使う必要はありません。
小さな修正（テキストの変更など）はmainに直接プッシュしても問題ない場面も多いです。
ブランチを使うと効果的な場面の目安
・スマホのClaudeアプリから操作する時（必ずブランチが作られる）
・Claude Codeに新しい機能の追加を依頼するとき
・大きなデザインや構造の変更を依頼するとき
・「失敗したときに戻せるようにしておきたい」と感じるとき
逆に、文章の修正や細かい調整など、影響範囲が小さい作業であれば、mainに直接コミットするシンプルな運用でも十分です。
自分のプロジェクトの規模や作業の大きさに合わせて使い分けていくのがおすすめです。
まとめ
・ブランチ ＝ mainから分岐した作業スペース。失敗してもmainが壊れない
・プルリクエスト（PR） ＝ ブランチの変更をmainに取り込む申請
・スマホでPRをマージした後は、PCでプル（pull）を実行しないとPC側に反映されない
・Claude Codeとの個人開発では、大きな変更の前にブランチを切る習慣がおすすめ
・小さな修正はmain直接でも問題なし。作業の大きさで使い分けよう
この記事を読んでみての感想や、実際に試してみた結果をコメントで教えてもらえると嬉しいです。「うまくいった！」でも「ここで詰まった」でも大歓迎です。
記事の内容について「ここがよくわからなかった」などの質問があれば、コメントに書いていただければできる限り返信します。
