GitHubのブランチはプロジェクト内で複数の作業を同時に行うための機能。ブランチを使うことで、メインのコードベースに影響を与えることなく新しい機能を開発したり、バグを修正したりすることができます。
関連 【初心者向け】GitHubとは？使い方を１からわかりやすく解説
より具体的にざっくり説明すると、ブランチはリポジトリ内に複製される別の作業フォルダのようなものです。別に言い方をするとプログラムに改修をする際に一時的に生み出される別の世界線のようなもので、この世界線で作業することで現実の世界線には影響を与えずに作業することを可能にする仕組み。
このページではブランチの基本的な仕組みや、マージやプルリクエストといったブランチにまつわる基本知識をご説明します。
ブランチとは？
ブランチはプロジェクトの中で独立して作業を進めるための「作業場」や「実験場」のようなものです。「実験場」で作業することで、メインのコードベースに影響を与えずに新しい機能の開発やバグ修正を行うことができます。
例えば、プロジェクトのメインブランチ（通常は「main」や「master」と呼ばれます）は、安定したバージョンを保管しています。これが「完成された場所」だと考えてください。しかし、新しい機能を追加したり、バグを修正したりする場合、直接この「完成された場所」で作業するのはリスクがあります。そこで別の「実験場」（ブランチ）を作成して、その中で自由に作業を進めるということ。
以下がそのイメージ図。リポジトリ内に複製される別の作業場だと理解しましょう。
もし、新たに作成した「実験場」（ブランチ）での改修が成功したら、その資源をメインブランチに合体させます。こうすることで、大事な資源には影響を与えずにプログラムの改修やテストが可能になる、という仕組みです。
- ステップ１ブランチの作成
メインブランチから新しいブランチを作成。これで新しい「実験場」が誕生。
- ステップ２ブランチでの作業
新しいブランチでコードの変更や新機能の開発、バグ修正を実施。
- ステップ３テスト/検証
ブランチ内での変更が正しく動作するかを確認。問題がなければ次のステップに進む。
- ステップ４プルリクエストの作成
変更が完了しテストに合格したら、メインブランチに統合するためのプルリクエストを作成。
- ステップ５統合（マージ）
プルリクエストが承認されるとブランチの変更がメインブランチに統合される。これで「実験場」での成果が正式にプロジェクトの一部となる。
このように、ブランチを使うことで安全かつ効率的にプロジェクトを進めることができます。ブランチは、メインのコードベースを保護しつつ、新しいアイデアや変更を試すための「別の場所」や「実験場」としての役割を果たします。
プルリクエストとは？（PR）
プルリクエスト（Pull Request/PR）は、作業ブランチ（実験場）での作業をメインのブランチに取り込むための「リクエスト（要求）」のこと。ブランチで行った変更が他のチームメンバーによって確認され、承認された後にメインのコードベースに統合されていくための、レビュー機能のようなものです。
プルリクエストは、変更内容をレビューし問題がないか確認するための重要な手続きです。
- ステップ１作業完了後にプルリクエストを作成
ブランチでの作業が完了しすべての変更をコミットした後、そのブランチをメインブランチに統合したい場合にプルリクエストを作成。
- ステップ２GitHubでの操作
GitHub上のリポジトリページにアクセスし「Pull requests」タブをクリック。その後「New pull request」ボタンをクリックして、新しいプルリクエストを作成。
- ステップ３変更内容の確認と説明
プルリクエストを作成する際にはどのブランチからどのブランチに変更を統合するのかを選択します（例えば「feature-branch」から「main」へ）。続いて、プルリクエストのタイトルと説明を書きますが、ここでは、どのような変更を行ったのか、その変更の目的や理由を明確に記載します。
- ステップ４レビューとコメント
プルリクエストを他のチームメンバーがその変更内容をレビュー。レビューアは、コードを確認し、問題がないかチェック。改善点や修正が必要な部分についてコメントを残すこともあります。
- ステップ５修正と更新
レビューアのコメントを受けて、必要に応じて変更を修正。修正後は再度プルリクエストを更新し、再レビューを依頼。
- ステップ５承認とマージ
レビューアが変更を承認すると、プルリクエストをメインブランチにマージすることができます。これで、ブランチで行った変更がメインのコードベースに統合され、プロジェクトに反映されます。
GitHub上でのプルリクエストのリクエスト先
GitHub上でのプルリクエストのリクエスト先（レビューア）は、主に以下の2つの方法で決まります。
1. GitHub上での選択
プルリクエストを作成する際に作成者が特定のレビューアを選択することができます。この方法では、以下の手順でレビューアを指定します。
- プルリクエストの作成
- ブランチでの作業が完了し、GitHub上でプルリクエストを作成。
- レビューアの選択
- プルリクエストの作成ページで、「Reviewers」セクションがあります。このセクションでレビューを依頼したいチームメンバーを選択することができます。選択されたレビューアに通知が送られ、レビューを行う流れ。
2. 事前定義
プロジェクトの設定やリポジトリの管理者によって、特定のファイルやディレクトリに対するコードオーナーを事前に定義することができます。これにより特定の部分に変更があった場合、自動的にレビューアが割り当てるようにすることもできます。
- CODEOWNERSファイルの作成
- リポジトリ内に
.githubディレクトリを作成し、その中にCODEOWNERSというファイルを置きます。
- リポジトリ内に
- コードオーナーの定義
CODEOWNERSファイル内で、特定のファイルやディレクトリに対して、レビューア（コードオーナー）を指定。例えば、以下のように記述します。
# 全てのファイルに対するコードオーナー * @team-member1 @team-member2 # 特定のディレクトリに対するコードオーナー /src/ @specific-owner # 特定のファイルに対するコードオーナー /README.md @documentation-owner
GitHub上でのプルリクエストのリクエスト先は、作成時に手動で選択するか、事前にCODEOWNERSファイルで定義する方法の２つが存在します。手動で選択する方法は柔軟性があり、その都度レビューアを決めることができます。事前定義する方法は、プロジェクトの規模が大きい場合や、特定の部分に対して常に同じ人がレビューを行う必要がある場合に便利です。
どちらの方法も、プロジェクトのレビュー体制を整えるために有効です。
マージとは？（Merge）
プルリクエストはあくまでもレビュー機能。レビュー完了したら自動で「実験場」の資源が本番資源に統合されるわけではありません。（事前に自動でマージされる仕組みを構築することもできますが、これは後述。）
ここで必要となるのがマージです。マージを正式に説明すると、異なるブランチで行われた変更を１つに統合する操作のことです。GitHubでは、この操作をGUI上から簡単に行うことができます。
コンフリクト（conflict）
マージする際の注意点がコンフリクト（conflict）です。コンフリクトは異なるブランチで行われた変更が競合し、マージが自動的に行えない状態のことを指します。これは、同じファイルの同じ部分が異なる方法で変更されたときに発生します。コンフリクトは、手動で解決する必要があります。
コンフリクトは以下のような状況で発生します。
- 同じファイルの同じ行を変更: 異なるブランチで同じファイルの同じ行を異なる内容に変更した場合。
mainブランチでREADME.mdの1行目を「Welcome to our project」に変更。feature-branchで同じ行を「Welcome to the best project」に変更。
- ファイルの削除と変更: 一方のブランチでファイルが削除され、他方のブランチで同じファイルが変更された場合。
自動マージの設定方法
GitHubには、特定の条件が満たされた場合にプルリクエストを自動的にマージする機能があります。以下の設定を行うことで自動マージの仕組みを実現することができます。
- 保護されたブランチの設定: リポジトリの設定で、メインブランチに対して保護されたブランチルールを設定します。これにより、特定の条件が満たされるまでマージがブロックされます。
- リポジトリの「Settings」タブを開く。
- 左側のメニューから「Branches」を選択し、「Branch protection rules」セクションで「Add rule」をクリック。
- 保護したいブランチ（例：
main）を選択し、マージ条件（例：ステータスチェックの合格、レビューの完了）を設定。
- 自動マージの有効化: プルリクエストのページで「Allow auto-merge」オプションを有効にします。このオプションは、保護されたブランチのルールが満たされた場合にプルリクエストを自動的にマージします。
- プルリクエストを作成または開いた状態で、「Allow auto-merge」ボタンをクリック。