実践：Issue からマージまでのチーム開発フロー

Git と GitHub の各操作をバラバラに学んでも、「実際のチーム開発でどう使うのか」がイメージしにくいことがあります。この記事では、実際の開発シナリオを 1 本の流れで体験することで、Issue → ブランチ → 実装 → PR → レビュー → マージの全工程がどう繋がるかを理解します。

対象読者: Git の基本操作・ブランチ・PR の作成方法を学んだ方

学習時間の目安: 読了 20分 ＋ 実践 30分

前提知識: プルリクエストの作成とレビュー依頼 と GitHub Issues を完了していること

シナリオの設定

設定: あなたは Tanaka さんと 2 人でチーム開発をしています。ユーザーから「プロフィールページに自己紹介文を追加してほしい」という要望が届きました。

これから Issue を立て、ブランチを切り、実装して、PR を出してレビューを受け、main にマージするまでの全工程を体験します。

---

ステップ 1: Issue を立てる

まず、「何をやるか」を Issue に記録します。実装をいきなり始めず、Issue で作業内容を定義することで、チームメンバー全員が状況を把握できます。

Issue の作成

GitHub のリポジトリページで「Issues」→「New issue」をクリックします。

タイトルの例:

feat: プロフィールページに自己紹介文フィールドを追加

説明の例:

## 背景
ユーザーから「自己紹介文を書きたい」というリクエストがあった。

## やること
- プロフィールページに `bio`（自己紹介文）フィールドを追加する
- 最大 200 文字まで入力できるようにする
- 空欄でも保存できる（任意入力）

## 完了条件
- [ ] プロフィールページに入力フォームが表示される
- [ ] 保存ボタンを押すと入力内容が保存される
- [ ] 200 文字を超えると入力できない

ラベル: enhancement を設定 Assignees: 自分（あなた）を設定

「Submit new issue」をクリックして保存します。Issue 番号を確認してください（この例では #15）。

---

ステップ 2: ブランチを作成する

Issue が作成できたら、対応するブランチを作ります。ブランチ名に Issue 番号を含めると、後から「このブランチは #15 の対応だ」と分かります。

# main を最新にする
git checkout main
git pull origin main

# Issue 番号をブランチ名に含める
git checkout -b feature/15-add-bio-field

ブランチ名の構成：

feature / 15 - add-bio-field
  ↑         ↑        ↑
種類   Issue番号  何をするか

ブランチが作成できたことを確認します。

git branch
# * feature/15-add-bio-field
#   main

---

ステップ 3: 実装してコミットする

ブランチ上で作業します。変更が完了したらコミットします。

1 回目のコミット

# ファイルを編集する
# （例：プロフィールフォームに bio フィールドを追加）

git add .
git commit -m "feat(profile): 自己紹介文フィールドを追加 #15"

コミットメッセージの #15 は Issue 番号です。GitHub がコミットと Issue を自動でリンクします。

作業が続く場合：複数コミット

作業が長くなる場合は、意味のある単位でコミットを分けます。

# バリデーションを追加
git add .
git commit -m "feat(profile): bio フィールドのバリデーションを追加（200文字制限）"

# テストを追加
git add .
git commit -m "test(profile): bio フィールドのユニットテストを追加"

コミットの粒度は「1 つのコミットで 1 つの変更」が目安です。

---

ステップ 4: push して PR を作成する

実装が完了したら、ブランチを GitHub に push して PR を作成します。

push する

git push origin feature/15-add-bio-field

PR を作成する

GitHub のリポジトリページに移動すると「Compare & pull request」ボタンが表示されます。クリックして PR 作成ページを開きます。

PR タイトル:

feat(profile): 自己紹介文フィールドを追加

PR の説明:

## 変更内容
- プロフィールページに自己紹介文（bio）入力フィールドを追加した
- 最大 200 文字のバリデーションを実装した
- bio は任意入力（空欄でも保存可能）

## 変更の理由
ユーザーリクエストへの対応。詳細は Issue #15 を参照。

## テスト方法
1. アプリを起動する
2. プロフィールページを開く
3. 自己紹介文フィールドに入力して保存できることを確認する
4. 201 文字以上を入力しようとするとエラーが出ることを確認する

## 関連 Issue
Closes #15

Reviewers: Tanaka さんを設定して「Create pull request」をクリックします。

Closes #15 と書くことで、PR がマージされたときに Issue #15 が自動的にクローズされます。

---

ステップ 5: レビューを受けて修正する

Tanaka さんがコードをレビューしてコメントを送ってきました。

レビューコメントの例

Tanaka さんからのコメント（Files changed タブのコード行に付く）：

[nit] bio フィールドが空の場合、空文字列ではなく null を保存した方が
データベースのクエリがシンプルになります。どうでしょうか？

[nit] はニット（nitpick）の略で、「細かい指摘だが修正してほしい」という意味です。

コードを修正する

Tanaka さんの指摘を受けてコードを修正します。

# コードを修正する（空文字 → null に変更）

git add .
git commit -m "fix(profile): bio が空の場合は null を保存するよう修正"
git push origin feature/15-add-bio-field

push するだけで PR に自動的に新しいコミットが追加されます。

対応済みコメントをクローズする

GitHub の PR ページで、対応したコメントの「Resolve conversation」をクリックします。コメントが折り畳まれ、未対応の項目だけが表示されるようになります。

再レビューを依頼する

「Reviewers」セクションの Tanaka さんの横にある更新アイコン（↺）をクリックして「Re-request review」します。Tanaka さんに通知が届きます。

---

ステップ 6: Approve を受けてマージする

Tanaka さんが修正内容を確認して「Approve」しました。

Approve の確認

PR ページの「Reviewers」セクションに緑のチェックマークが表示されます。これでマージできる状態です。

マージする

「Squash and merge」ボタンをクリックします（ボタン横の「▼」から選択できます）。

確認ダイアログでコミットメッセージを確認します。「Confirm squash and merge」をクリックしてマージを完了します。

ブランチを削除する

マージ後に表示される「Delete branch」ボタンをクリックして、不要になったブランチを削除します。

Issue が自動クローズされることを確認する

「Issues」タブを開き、Issue #15 が「Closed」になっていることを確認しましょう。Closes #15 と書いたことで自動的にクローズされています。

---

ステップ 7: ローカルを更新する

GitHub 上でマージが完了したら、ローカルの main ブランチも最新化します。

# main ブランチに戻る
git checkout main

# リモートの変更を取り込む
git pull origin main

# ローカルのブランチを削除する
git branch -d feature/15-add-bio-field

これで 1 サイクルの完成です。

---

フロー全体の振り返り

今回の一連の流れを整理します。

Issue 作成 (#15)
    ↓
ブランチ作成 (feature/15-add-bio-field)
    ↓
実装・コミット (feat, fix, test)
    ↓
push → PR 作成 (Reviewers: Tanaka, Closes #15)
    ↓
レビュー → コメント対応 → 再レビュー依頼
    ↓
Approve → Squash and merge
    ↓
Issue 自動クローズ (#15)
    ↓
ローカル main を更新 → ブランチ削除

このサイクルが「1 機能・1 バグ修正」に対応する 1 イテレーションです。

チーム開発では、複数のメンバーがそれぞれ別の Issue に対してこのサイクルを並行して回します。

---

このフローを繰り返すことで

得られるもの	理由
コードの品質向上	レビューを経てからマージされるため
変更理由の可視化	PR と Issue が紐づき、後から変更意図が分かる
バグの抑制	main に直接 push せず、レビュー・テストを通過したコードのみマージ
知識の共有	レビューを通じてチーム全員がコードを理解できる
振り返りの容易さ	「いつ・誰が・なぜ」変更したかが GitHub 上に記録される

---

FAQ

Q. レビュアーが多忙でレビューが来ない場合はどうすればよいですか？

Slack や Chatwork でレビュー依頼を一言伝えると効果的です。チームのルールとして「レビューは 24 時間以内に対応する」などの合意があると理想的です。急ぎの場合は口頭で確認を依頼しましょう。

Q. main に直接 push してしまった場合はどうすればよいですか？

ブランチ保護ルールを設定していれば、main への直接 push は GitHub 側で拒否されます。もし保護なしで直接 push してしまった場合は、チームに報告して影響範囲を確認しましょう。ブランチ保護の設定については チーム開発の運用フロー を参照してください。

Q. 自分 1 人のプロジェクトでも PR を使うべきですか？

使うことを強くおすすめします。1 人でも PR を使うと「Files changed」でセルフレビューができ、変更の記録が残ります。GitHub Actions でテストを自動化していれば、マージ前にテストが通ることも確認できます。将来チームに参加するときに PR ワークフローに慣れていると、スムーズに貢献できます。

Q. PR がコンフリクトしている場合はどうしますか？

main の変更を取り込んでコンフリクトを解消してから PR を出しましょう。

git checkout feature/15-add-bio-field
git pull origin main
# コンフリクトを手動で解消する
git add .
git commit -m "chore: main の変更を取り込んでコンフリクトを解消"
git push origin feature/15-add-bio-field