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

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

学習目標

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

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

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

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

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

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

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

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

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

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

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

新機能を追加したい場合

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

バグを修正したい場合

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

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

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

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

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

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

mainブランチ（本流）

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

featureブランチ（実験用）

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

ブランチの流れ：

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

6.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. テスト
    • 変更が正しく動作するか確認
    • 問題があれば追加の修正とコミット

6.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の作成からマージまでの一連の流れを理解し、効率的なチーム開発を実現しましょう。

作業用ブランチの削除

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

削除手順：

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

削除の安全性：

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

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

PRテンプレートの構造

PRテンプレート構造

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

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

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

発生例：

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

次の章では、チーム開発に欠かせないプルリクエスト機能について詳しく学習します。

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

Edit this page on GitHub