GitHub初心者ガイド - バージョン管理の基礎から実践まで

第7章：ブランチの基本操作

学習目標

この章を読み終える頃には、ブランチの概念を理解し、安全に実験的な変更を行えるようになります。また、GitHub Desktopを使ってブランチの作成、切り替え、マージ（統合）ができ、コンフリクト（競合）が起きた場合の基本的な対処法を身につけます。

7.1 ブランチとは何か（実験的な変更の管理）

日常生活での「ブランチ」的な考え方

「ブランチ」という言葉を聞くと難しく感じるかもしれませんが、実は私たちの日常生活でも似たような考え方をしています。

料理での例 カレーを作っているとします。基本のカレーは完成していますが、「スパイスを追加したらもっと美味しくなるかも」と思いました。でも、スパイスを入れすぎて失敗したら、せっかくのカレーが台無しになってしまいます。

そこで、カレーを小皿に少し取り分けて、その小皿でスパイスの実験をします。うまくいけば残りのカレー全体に適用し、失敗すれば小皿だけ処分して、元のカレーは無事に保たれます。

文章作成での例 レポートを書いているとします。基本の構成は完成していますが、「この章をもっと詳しく書いたら良くなるかも」と思いました。でも、大幅に書き直して読みづらくなったら困ります。

そこで、現在のファイルをコピーして「レポート_実験版.docx」として保存し、この実験版で新しい章を試してみます。うまくいけば本体に統合し、うまくいかなければ実験版だけ削除します。

GitHubの「ブランチ」は、まさにこの「実験用のコピーを作って、安全に試行錯誤する」仕組みです。

プログラミングでブランチが重要な理由

プログラミングの世界では、この「安全な実験」がさらに重要になります：

新機能を追加したい場合

  • Webサイトに「お問い合わせフォーム」を追加したい
  • でも、作業中にサイトが壊れてしまうかもしれない
  • 他の人が同時に別の作業をしているかもしれない

バグを修正したい場合

  • 「スマートフォンでレイアウトが崩れる」問題を直したい
  • でも、修正中に別の部分が壊れてしまうかもしれない
  • 修正がうまくいかない場合、元の状態に戻したい

デザインを変更したい場合

  • 「ヘッダーの色を青から緑に変えたい」
  • でも、緑色が思ったより印象が悪いかもしれない
  • 一度試してみて、判断したい

ブランチを使えば、これらの実験をすべて安全に行うことができます。

Gitにおけるブランチの仕組み

ブランチワークフローパターン

mainブランチ（本流）

  • プロジェクトの「正式版」
  • 常に動作する状態を保つ
  • 公開されているバージョン

featureブランチ（実験用）

  • 新機能開発用の作業ブランチ
  • mainから分岐して作成
  • 完成したらmainに統合

ブランチの流れ：

main ─────●─────●─────●───── （安定版）
          │             ↗
          └─● ─ ● ─ ●──┘    （実験ブランチ）
            新機能開発

7.2 GitHub Desktopでのブランチ作成と切り替え

新しいブランチの作成手順

ブランチマージ戦略

1. GitHub Desktopでリポジトリを開く

  • 対象のリポジトリを選択
  • 現在のブランチが「main」であることを確認

2. 新しいブランチの作成

  • 画面上部の「Current branch」をクリック
  • 「New branch」ボタンを選択
  • ブランチ名を入力（例：add-contact-form）
  • 「Create branch」をクリック

良いブランチ名の例：

  • add-contact-form（お問い合わせフォーム追加）
  • fix-mobile-layout（モバイル表示修正）
  • update-homepage-design（ホームページデザイン更新）
  • feature-user-authentication（ユーザー認証機能）

避けるべきブランチ名：

  • test（何をテストするか不明）
  • fix（何を修正するか不明）
  • new（何が新しいか不明）
  • branch1（内容が全く分からない）

ブランチ履歴管理

ブランチ間の切り替え

切り替え手順：

  1. 「Current branch」ドロップダウンをクリック
  2. 切り替えたいブランチを選択
  3. ブランチが切り替わると、ファイルの内容も自動的に変更される

切り替え時の注意点：

  • 未コミットの変更がある場合は、先にコミットするか、変更を破棄する
  • ブランチごとに異なるファイル状態が保持される
  • 切り替え後は、そのブランチの最新状態がローカルに反映される

作業用ブランチでの開発

実際の作業手順：

  1. ブランチ作成
    • mainブランチから作業用ブランチを作成
    • 分かりやすい名前を付ける
  2. ファイル編集
    • 普通のファイルと同様に編集
    • 複数のファイルを変更してもOK
  3. コミット
    • 変更内容をブランチにコミット
    • mainブランチには影響しない
  4. テスト
    • 変更が正しく動作するか確認
    • 問題があれば追加の修正とコミット

7.3 マージ（統合）の基本概念と実践

Pull Requestの概要

Pull Request概要

Pull Request（PR）は、ブランチでの変更をメインブランチに統合する前に、チームメンバーにレビューを依頼する機能です。コードの品質を保ち、チーム全体で知識を共有するための重要なプロセスです。

マージとは何か

「マージ」は、作業用ブランチでの変更を、mainブランチに統合することです。実験が成功した場合に、その成果を本流に取り込む作業です。

マージの流れ：

Before:
main   ─●─●─●─────── （安定版）
        │     
feature └●─●─●       （新機能）

After:
main   ─●─●─●─●───── （新機能が統合された安定版）

PRの種類とパターン

PRタイプパターン

Pull Requestには様々な種類があります。新機能追加、バグ修正、ドキュメント更新など、目的に応じて適切なPRタイプを選択することが重要です。

GitHub Desktopでのマージ手順

1. mainブランチに切り替え

  • 「Current branch」からmainブランチを選択
  • 統合先のブランチに移動

2. マージの実行

  • メニューから「Branch」→「Merge into current branch」
  • マージしたいブランチを選択
  • 「Create a merge commit」をクリック

3. マージ完了の確認

  • 変更内容がmainブランチに反映されていることを確認
  • コミット履歴にマージコミットが追加される

PR 作成ワークフロー

PR 作成ワークフロー

Pull Requestの作成からマージまでの一連の流れを理解し、効率的なチーム開発を実現しましょう。

最小手順（CLI）：clone → branch → commit → push → PR

GitHub Desktop ではなくターミナルで作業する場合でも、流れは同じです。ここでは最小手順だけをまとめます。

前提:

  • Git がインストール済み
  • リモートは origin、統合先は <default-branch>（例: main。プロジェクトにより異なるため要確認）
  • PR 作成はブラウザ、または GitHub CLI（gh）を利用（任意）

1) リポジトリを clone して移動します。

git clone https://github.com/<owner>/<repo>.git
cd <repo>

2) 最新の既定ブランチ（ここでは <default-branch>）を取得し、作業用ブランチを作成します。

git switch <default-branch>
git pull --ff-only
git switch -c feat/<topic>
# 参考: 古い Git の場合
# git checkout -b feat/<topic>

3) 変更をステージし、コミットします（不要なファイルを混ぜない）。

git status
git add <file1> <file2>
# 参考: 変更範囲を確認しながらステージする場合
# git add -p
git commit -m "docs: update ..."

4) リモートへ push します。

git push -u origin feat/<topic>

5) Pull Request を作成します。

  • ブラウザ: GitHub 上で feat/<topic> から <default-branch> への PR を作成する
  • GitHub CLI（任意）:
gh pr create --base <default-branch> --head feat/<topic> --title "..." --body "..."

よくある失敗と回避（最小）

  • main のまま作業してしまう: git branch --show-current でブランチ名を確認してから編集する
  • 意図しないファイルまでコミットする: git status で差分を確認し、git add <file> または git add -p を使う
  • git push で upstream エラーになる: 初回は git push -u origin <branch> を使う
  • PR が肥大化する: 目的を 1 つに絞り、無関係な整形やリファクタを混ぜない

PRをマージする前の最小ゲート

Pull Request は「作ったら終わり」ではありません。初心者向けの最小ゲートとして、少なくとも次を確認してからマージします。

ゲート 確認すること 証跡の残し方
目的と範囲 PR が 1 つの目的に絞られている PR body に概要、変更範囲、関連 Issue を書く
レビュー 指摘本文、inline comment、suggestion を全件確認した 修正した場合は返信し、不要な場合は理由を書く
conversation 未解決の review thread が残っていない GitHub 上で Resolve / Unresolve の状態を確認する
CI 必須チェックが成功している Checks タブで失敗 job がないことを確認する
merge 後 main のチェックと公開先に反映された merge 後の Actions / Pages / 動作確認を Issue に記録する

ブランチ保護や ruleset を使うと、レビュー、status checks、conversation resolution などをマージ条件として機械的に要求できます。本書では、個人学習では任意、チーム開発では最低限の merge gate として早めに導入することを推奨します。

branch protection rule と rulesets の整理（2026-07-19時点）

GitHub 公式仕様では、branch protection rule と rulesets は別機能です。rulesets を branch protection の単なる名称変更として扱わないでください。

  • branch protection rule は、特定の branch 名または fnmatch pattern を対象に設定します。ただし、同じ branch に同時適用される branch protection rule は常に 1 件だけです。優先順位は、specific branch rule が最優先、同じ specific branch を指す rule 同士では古い rule が優先、* などの特殊文字を含む wildcard rule 同士では作成順で古い rule が優先、です。
  • rulesets は branch または tag を対象にでき、複数の ruleset を同じ branch や tag に重ねて適用できます。さらに rulesets は branch protection rule とも重なって評価され、同じ種類の rule が複数定義されている場合は、より厳しい設定が有効になります。
  • active ruleset の確認 は admin 権限なしでも可能です。read 権限があれば、リポジトリの /rules や branch 一覧から対象 ruleset を確認できます。Pull Request の merge box に rule が表示された場合は、merge を妨げている条件も確認できます。
  • enforcement status は、Free / Pro / Team 向けの一般 docs では Active と Disabled が案内されています。Enterprise Cloud 向け docs では Evaluate も案内されており、利用できる環境では Rule Insights で非強制の評価結果を見てから Active へ進めます。

GitHub Docs（2026-07-19確認）

作業用ブランチの削除

マージが完了したら、不要になった作業用ブランチを削除できます：

削除手順：

  1. 「Current branch」ドロップダウンを開く
  2. 削除したいブランチの右側にある「×」をクリック
  3. 「Delete」で確認

削除の安全性：

  • マージ済みのブランチは安全に削除可能
  • 変更内容はmainブランチに保存されている
  • 必要に応じて同じ名前で再度ブランチを作成可能

7.4 PR レビューと運用（テンプレート / CODEOWNERS）

PR テンプレートの構造

PR テンプレート構造

効果的なPull Requestのために、テンプレートを活用しましょう。一貫性のある情報提供とレビュー効率の向上が期待できます。

このリポジトリでは、PR テンプレート例を .github/PULL_REQUEST_TEMPLATE.md として同梱しています。自分のプロジェクトで使う場合は、同ファイルをコピーして「必要最小限」から始めるのがおすすめです。

最低限そろえるとよい項目（例）

  • 目的（何を直す/追加するか）
  • 変更内容（概要）
  • 影響範囲（影響する/しない）
  • 検証（自動テスト/手動確認）
  • ロールバック（失敗時の戻し方）
  • 関連Issue（Closes #xxx）

※ AI支援を使う場合は、「AI支援の開示（任意）」を追加しておくと、後から検証責任の所在が曖昧になりにくくなります。

AI 支援の運用ルール（機密入力の禁止、確認観点など）は、次のポリシーを参照してください。

  • AI利用ポリシー（テンプレ）：https://github.com/itdojp/github-guide-for-beginners-book/blob/main/AI_USAGE_POLICY.md

PR レビュー状態

PR レビュー状態

Pull Requestのレビュープロセスでは、様々な状態があります。各状態の意味を理解し、適切なアクションを取ることが重要です。

PRディスカッション管理

PRディスカッション管理

Pull Requestでのディスカッションを効果的に管理することで、チーム全体のコミュニケーション品質と開発効率を向上させましょう。

AI生成PRのレビュー観点（最小セット）

AI生成のPull Requestは「速く作れる」一方で、意図・検証・安全性が省略されがちです。レビューでは「AIが作ったか」ではなく、次の観点で確認すると、主観ではなく手順として運用できます。

  • 変更意図の一致：Issueの背景/目的・受入基準に一致しているか
  • 検証の証跡：テスト結果や手動確認手順（ログ/スクリーンショット）が残っているか
  • 差分の過剰さ：関係ないリファクタやフォーマット変更が混ざっていないか
  • 依存関係/設定変更：更新理由と影響（リスク）が説明されているか
  • Secrets/個人情報：トークン・秘密鍵・顧客情報・ログの貼付がないか
  • ロールバック可能性（例：git revertで戻しやすいか）：PRが小さく、ロールバック手順が明記されているか

これらは、PR テンプレート（.github/PULL_REQUEST_TEMPLATE.md）のチェック欄としても運用できます。

CODEOWNERSでレビュー担当を自動で割り当てる（発展）

チームで運用する場合、「誰がレビュー責任を持つか」を仕組みで決めておくと、レビューが詰まりにくくなります。その代表例が CODEOWNERS です。

  • 設定ファイル: .github/CODEOWNERS
  • できること: 特定のパス（例：docs/）の変更が入ったときに、担当者（ユーザー/チーム）へレビュー依頼を自動化できる

このリポジトリでは、例として manuscript/**（本文）・docs/**（公開サイト）・src/**（元原稿）を CODEOWNERS に記載しています。自分のプロジェクトで使う場合は、まずは 「docs/ は文書担当」 だけ決めると運用しやすくなります。

また、CODEOWNERS は パターンの順序が重要で、複数マッチする場合は「最後にマッチした行」が優先されます。

レビューが詰まるときの対処（例）

  • 代替担当（バックアップ）を決め、CODEOWNERSに追加する
  • ローテーション（当番表）で担当を回す（人に依存しない）
  • 必須レビュー数や必須チェック（CI）と組み合わせ、例外運用の手順も決める

PRマージ戦略

PRマージ戦略

Pull Requestをマージする際には、様々な戦略があります。プロジェクトのポリシーや履歴管理の方針に応じて、適切なマージ戦略を選択しましょう。

PR自動化ツール

PR自動化ツール

効率的なチーム開発のために、PRプロセスの一部を自動化することができます。CI/CD、自動テスト、コード品質チェックなどのツールを活用しましょう。

ブランチワークフローパターン（参考）

ブランチワークフローパターン

7.5 コンフリクト（競合）の理解と解決

コンフリクト（競合）は、同じファイルの同じ箇所が、異なるブランチで別々の内容に変更された場合に発生します。

コンフリクトが発生する原因

発生例：

main ブランチ：
<h1>Welcome to Our Website</h1>

feature ブランチ：
<h1>ようこそ私たちのウェブサイトへ</h1>

この状態でマージしようとすると、Gitは「どちらが正しいか分からない」状態になります。

コンフリクトの種類

1. 内容の競合

  • 同じ行が異なる内容に変更されている
  • 最も一般的なコンフリクト

2. 削除と変更の競合

  • 一方で削除、もう一方で変更されたファイル
  • どちらを採用するか判断が必要

3. ファイル名の競合

  • 同じファイルが異なる名前に変更されている
  • 稀だが、解決が複雑

GitHub Desktopでのコンフリクト解決

1. コンフリクト発生の通知

  • マージ時にコンフリクトが発生すると警告が表示
  • 「Resolve conflicts」ボタンが表示される

2. 外部エディタでの解決

  • 「Open in External Editor」をクリック
  • VS Codeなどのエディタでコンフリクトファイルを開く

3. コンフリクトマーカーの理解

<<<<<<< HEAD
Welcome to Our Website (mainブランチの内容)
=======
ようこそ私たちのウェブサイトへ (featureブランチの内容)
>>>>>>> feature-branch

4. 解決方法の選択

選択肢1：片方を採用

<h1>ようこそ私たちのウェブサイトへ</h1>

選択肢2：両方を統合

<h1>Welcome to Our Website / ようこそ私たちのウェブサイトへ</h1>

選択肢3：全く新しい内容

<h1>私たちのサイトへようこそ</h1>

5. 解決完了

  • コンフリクトマーカーを全て削除
  • ファイルを保存
  • GitHub Desktopで「Mark as resolved」
  • 「Continue merge」でマージ完了

コンフリクト予防のベストプラクティス

1. 頻繁なマージ

  • 長期間ブランチを分離させない
  • 定期的にmainブランチの変更を取り込む

2. 小さな変更単位

  • 大規模な変更を避ける
  • 機能単位での細かいブランチ作成

3. チーム内でのコミュニケーション

  • 同じファイルを編集する際は事前相談
  • 作業範囲の明確化

4. ファイル構成の工夫

  • 機能ごとにファイルを分離
  • 共通部分の変更は慎重に

まとめ

この章では、ブランチを使った安全な開発手法について学びました：

ブランチの基本概念

  • 実験用のコピーを作成する仕組み
  • mainブランチ（安定版）と作業ブランチの分離
  • 日常生活の類推による理解

実践的なブランチ操作

  • GitHub Desktopでのブランチ作成と切り替え
  • 適切なブランチ命名規則
  • 作業用ブランチでの安全な開発

マージによる統合

  • 作業ブランチからmainブランチへの統合
  • マージ完了後のブランチ削除
  • 変更履歴の保持

PRコンフリクト解決

PRコンフリクト解決

コンフリクト解決

  • 競合が発生する原因の理解
  • 実践的な解決手順
  • 予防のためのベストプラクティス

PR品質ゲート

PR品質ゲート

コード品質を維持するために、PRに品質ゲートを設定しましょう。自動テスト、コードレビュー、セキュリティチェックに加えて、未解決の review thread が 0 件であること、必須 status checks 成功、merge 後確認を組み合わせると、変更の説明責任を保ちやすくなります。

PRメトリクス分析

PRメトリクス分析

Pull Requestのメトリクスを分析することで、チームの開発効率やコード品質を継続的に改善できます。レビュー時間、マージ率、コンフリクト発生率などの指標を活用しましょう。

次の章では、Issue 管理とプロジェクト管理について学習します。

理解度確認： □ ブランチの概念を理解し、適切に作成・切り替えができる
□ マージ操作により変更を安全に統合できる
□ 基本的なコンフリクトを自力で解決できる
□ ブランチを使った開発ワークフローを実践できる
□ 予防的なベストプラクティスを理解している

次の一手（文書運用に繋げる）

文書運用（Docs-as-Code）を前提にする場合は、次の 1 ステップを完了させると「運用が回る状態」に近づきます。

  • 文書変更の PR を 1 件作成し、レビュー→マージまで完了する（Issue と紐づける）

参照：

  • Docs-as-Code：/github-guide-for-beginners-book/chapters/chapter-docs-as-code/
  • Issue / Projects：/github-guide-for-beginners-book/chapters/chapter-issue-management/
Edit this page on GitHub