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 つに絞り、無関係な整形やリファクタを混ぜない

作業用ブランチの削除

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

削除手順：

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

削除の安全性：

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

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

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

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

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

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

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

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

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

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

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

発生例：

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」でマージ完了

PRレビュー状態

PRレビュー状態

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

PRディスカッション管理

PRディスカッション管理

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

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

1. 頻繁なマージ

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

2. 小さな変更単位

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

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

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

4. ファイル構成の工夫

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

PRマージ戦略

PRマージ戦略

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

PR自動化ツール

PR自動化ツール

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

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

まとめ

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

ブランチの基本概念

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

実践的なブランチ操作

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

マージによる統合

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

PRコンフリクト解決

PRコンフリクト解決

コンフリクト解決

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

PR品質ゲート

PR品質ゲート

コード品質を維持するために、PRに品質ゲートを設定しましょう。自動テスト、コードレビュー、セキュリティチェックなどを組み合わせた包括的な品質管理が可能です。

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