イシューからPRマージまで：Gitワークフローの全体像を理解する

「mainブランチに直接pushしている」「PRって何のためにあるの？」という方に向けて、イシュー登録からPRマージまでの一連のGitワークフローを解説します。

この記事では、実際のPR対応を例に、各ステップの役割と具体的なコマンドを紹介します。

ワークフロー全体像

まず、全体の流れを確認します。

graph TD
    A[1. イシュー作成] --> B[2. ブランチ作成]
    B --> C[3. コード修正・コミット]
    C --> D[4. PR作成]
    D --> E{5. CIチェック}
    E -->|失敗| C
    E -->|成功| F[6. レビュー]
    F --> G{修正必要?}
    G -->|はい| C
    G -->|いいえ| H[7. マージ]
    H --> I[8. イシュークローズ]

各ステップには明確な役割があります。順番に見ていきましょう。

ステップ1: イシューで作業を明確にする

イシューとは

イシュー（Issue）は「これから何をするか」を記録する場所です。バグ報告、機能追加、改善提案など、あらゆる作業の起点になります。

なぜイシューを作るのか

  • 作業の可視化: 何をやるのかがチーム全体に共有される
  • 議論の場: 実装前に方針を議論できる
  • 履歴: なぜその変更をしたのか後から追跡できる

イシューテンプレートの活用

GitHubのイシューテンプレート機能を使うと、必要な情報を漏れなく記載できます。

# .github/ISSUE_TEMPLATE/bug.yml
name: バグ報告
description: バグや不具合を報告する
labels: ["bug"]

body:
  - type: textarea
    id: summary
    attributes:
      label: 概要
    validations:
      required: true

ステップ2: ブランチを切って作業する

なぜブランチを使うのか

mainブランチは「本番環境にデプロイされる状態」を保つべきです。作業中の不完全なコードをmainに置くと、他のメンバーに影響が出ます。

ブランチを使うことで：

  • mainを安全に保つ: 作業中のコードは別ブランチに隔離
  • 並行作業が可能: 複数の機能を同時に開発できる
  • レビューしやすい: 変更がブランチ単位でまとまる

ブランチの作成

# mainブランチを最新に更新
git checkout main
git pull origin main

# 新しいブランチを作成して切り替え
git checkout -b feature/add-login-button

ブランチ名の命名規則

チームで規則を決めておくと管理しやすくなります。

プレフィックス用途
feature/新機能追加
fix/バグ修正
docs/ドキュメント更新
refactor/リファクタリング

ステップ3: コミットで変更を記録する

コミットの単位

1つのコミットは「1つの論理的な変更」にまとめます。

# 良い例: 変更ごとにコミット
git add src/components/Button.tsx
git commit -m "ログインボタンコンポーネントを追加"

git add src/pages/login.tsx
git commit -m "ログインページにボタンを配置"
# 避けたい例: すべてを1つにまとめる
git add .
git commit -m "いろいろ修正"

コミットメッセージの書き方

何を変更したかではなく、なぜ変更したかが伝わるメッセージが理想です。

避けたい例良い例
fix bugログイン時のリダイレクトループを修正
updateAPIレスポンスのキャッシュ時間を30秒に延長
add fileユーザー認証のミドルウェアを追加

ステップ4: PRで変更を提案する

PRとは

PR（Pull Request）は「このブランチの変更をmainに取り込んでほしい」という提案です。

リモートにプッシュしてPRを作成

# リモートにブランチをプッシュ
git push -u origin feature/add-login-button

GitHubでPRを作成するか、CLIを使います。

# GitHub CLIでPR作成
gh pr create --title "ログインボタンを追加" --body "## 概要
ログインページにボタンを追加しました。

## 関連イシュー
Closes #42"

PRテンプレートの活用

PRテンプレートを用意しておくと、レビューに必要な情報が揃います。

<!-- .github/PULL_REQUEST_TEMPLATE.md -->
## 概要
<!-- このPRで何をしたか -->

## 関連イシュー
<!-- Closes #123 で自動クローズ -->

## 確認事項
- [ ] ローカルで動作確認済み
- [ ] 既存機能への影響なし

ステップ5: CIチェック

CIとは

CI（Continuous Integration）は、コードの変更があるたびに自動でテストやビルドを実行する仕組みです。GitHub Actionsなどで設定します。

CIで行われる一般的なチェック

チェック項目目的
ビルドコードが正しくビルドできるか
テスト既存の機能が壊れていないか
Lintコードスタイルが統一されているか
型チェック型エラーがないか

CIが失敗したら

graph LR
    A[CIが失敗] --> B[エラー内容を確認]
    B --> C[ローカルで修正]
    C --> D[コミット・プッシュ]
    D --> E[CIが再実行]

失敗したらエラーログを確認し、修正してプッシュします。CIは自動で再実行されます。

ステップ6: レビューとマージ

コードレビュー

チーム開発では、PRをマージする前に他のメンバーがコードを確認します。

レビューで確認されること：

  • コードの品質と可読性
  • バグがないか
  • 設計方針に沿っているか

mainが進んでいた場合

作業中にmainブランチが更新されていることがあります。その場合は最新のmainを取り込みます。

# mainの最新を取得
git fetch origin main

# 現在のブランチにmainをマージ
git merge origin/main

コンフリクト（競合）が発生した場合は、手動で解消してコミットします。

マージの種類

方法特徴
Merge commitすべてのコミット履歴を保持
Squash and merge複数コミットを1つにまとめる
Rebase and mergeコミットをmainの先頭に移動

チームの方針に従って選択します。

実際の例: PR対応の流れ

実際にあったPR対応を例に、流れを見てみましょう。

状況

  • 記事を追加するPRを作成
  • CIが失敗（ビルドエラー）
  • 原因を調査して修正

対応の流れ

# 1. PRの状態を確認
gh pr view

# 2. CIのエラー内容を確認
gh pr checks

# 3. ローカルでビルドして原因を特定
npm run build

# 4. 原因: 必須のメタデータが不足していた
#    → 修正してコミット
git add .
git commit -m "fix: 記事にfrontmatterを追加"

# 5. プッシュしてCIを再実行
git push

# 6. CIが成功したらマージ
gh pr merge --merge

学び

  • CIがあることで、本番環境にデプロイする前にエラーを検知できた
  • エラーメッセージを読めば、原因と対処法がわかる

まとめ

Gitワークフローの各ステップには明確な役割があります。

ステップ役割
イシュー作業内容を明確化・共有
ブランチmainを安全に保つ
コミット変更を論理的な単位で記録
PR変更を提案・レビュー依頼
CI自動でテスト・ビルド確認
マージmainに変更を取り込む

最初は手順が多く感じるかもしれませんが、この流れに慣れると：

  • バグの混入を防げる
  • 変更履歴が追跡しやすい
  • チームでの協業がスムーズになる

まずは個人開発でもこの流れを意識してみてください。

参考リンク