GitHubワークフロー | n10u-tech bootcamp

GitHubはGitリポジトリのホスティングサービスであると同時に、コードレビュー・Issue管理・CI/CDの実行基盤でもあります。単なるコードの置き場ではなく、開発プロセス全体を支えるプラットフォームとして使いこなすことが重要です。

コラム: PR は「マージ依頼」ではなく「レビュー単位」で切る

Pull Request は単に main へ取り込むための手続きではなく、「この変更をこの粒度で見てほしい」というレビュー単位でもあります。変更が大きすぎると、実装自体が正しくてもレビューしづらくなり、バグや設計の粗さを見逃しやすくなります。

そのため、機能を小さく切り、1 PR で 1 意図を説明できる状態にするのが重要です。これは一人開発でも同じで、未来の自分が履歴を追うときの読みやすさに直結します。

概念リンク

GitHub Docs: About pull requests（https://docs.github.com/ja/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests）
Google Engineering Practices: Small CLs（https://google.github.io/eng-practices/review/developer/small-cls.html）

書籍

『Team Geek』: レビュー文化と協働の前提を理解しやすい
『理想のコード』: レビュー観点をどう言語化するかの補助になる

基本用語

リモートリポジトリ: GitHub上に存在するリポジトリです。origin という名前でローカルに登録されることが多いです。

フォーク（Fork）: 他人のリポジトリを自分のアカウントにコピーすることです。オープンソースに貢献するときや、元リポジトリの変更権限がないときに使います。

プルリクエスト（PR）: あるブランチの変更を別のブランチにマージするための提案です。コードレビューとディスカッションの場として機能します。

GitHub Flowによる開発サイクル

最もシンプルなブランチ戦略「GitHub Flow」です。

1. main から feature ブランチを作成
2. ローカルで実装・コミット
3. GitHub に push
4. PR を作成（base: main ← compare: feature/xxx）
5. レビューを受けて修正
6. main にマージ
7. feature ブランチを削除

git checkout -b feature/add-login    # ブランチ作成
# ... 実装 ...
git add .
git commit -m "feat: ログイン機能を追加"
git push origin feature/add-login    # GitHubにpush
# → GitHub上でPRを作成

PRの書き方

良いPRは変更の「Why（なぜ）」を伝えます。「What（何を変えたか）」はコードを見ればわかります。

## 概要
ユーザー認証にJWT方式を採用します。セッションストアが不要なため
スケールアウト時にも対応しやすいです。

## 変更内容
- JWTトークンの生成・検証ロジックを追加
- 認証ミドルウェアを実装
- ログイン・ログアウトAPIエンドポイントを追加

## テスト方法
1. `POST /api/auth/login` に email/password を送信
2. レスポンスのtokenをAuthorizationヘッダに付けてAPIを呼び出す
3. 無効なtokenで401が返ることを確認

コンフリクトの解消手順

PRをマージしようとするとコンフリクトが発生することがあります。解消手順は以下のとおりです。

# mainの最新を取り込む
git checkout main
git pull origin main

# 作業ブランチに戻る
git checkout feature/my-feature

# mainの変更をマージ
git merge main

# コンフリクトしたファイルを編集して解消
# （コンフリクトマーカー <<<<<< を取り除く）
git add .
git commit -m "fix: mainとのコンフリクトを解消"
git push origin feature/my-feature

.github/workflows との連携

PRを作成すると、GitHub Actionsが自動的にテスト・Lintを実行するよう設定できます。CIが通らないとマージできない設定にすることで品質を担保します（CI/CDの詳細はb19参照）。

Issues と Projects

Issue: バグ報告・機能要望・タスクを管理する単位です。#123 のように番号で参照できます。コミットメッセージに fix #123 と書くとマージ時に自動クローズされます。

Projects: KanbanボードやSpreadsheetでIssueとPRを管理する機能です。個人開発でも「やること・進行中・完了」の可視化に使えます。

個人開発での使い方

チーム開発だけでなく一人でも活用できます。

コミット履歴: 「なぜこのコードを書いたか」を未来の自分への説明として残す
Issue: 思いついたタスクをすぐ記録しておく
PR: 機能ブランチでの実装を振り返り、自分でレビューしてからマージする習慣をつける

参考リソース

GitHub Flow（https://docs.github.com/ja/get-started/quickstart/github-flow）
GitHub Skills（https://skills.github.com/）— インタラクティブなチュートリアル
Conventional Commits（https://www.conventionalcommits.org/ja/）

確認クイズ

Q1. GitHubにおける「リモートリポジトリ」とは何か。ローカルリポジトリとの違いを含めて説明してください。

正解: GitHub上に存在するリポジトリです。ローカルリポジトリは自分のPC上に存在し、リモートリポジトリはGitHub等のサーバー上に存在します。

解説: ローカルリポジトリはネット接続なしで操作できますが、チームと共有するにはリモートへのpush/pullが必要です。origin はリモートリポジトリのデフォルト名として慣例的に使われます。

Q2. フォーク（Fork）はどのような目的で使いますか。

A. 自分のブランチを作成する
B. 他人のリポジトリを自分のアカウントにコピーする
C. リモートリポジトリを削除する
D. コンフリクトを解消する

正解: B

解説: フォークは元リポジトリへの変更権限がない場合に使います。オープンソース貢献では、フォーク→変更→プルリクエストの流れが標準的です。自分のアカウント配下のフォークには自由にpushできます。

Q3. プルリクエスト（PR）の主な役割は何ですか。

正解: あるブランチの変更を別のブランチにマージするための提案です。コードレビューとディスカッションの場として機能します。

解説: PRはコードの変更内容を可視化し、レビュアーがコメントや修正依頼を行えるプラットフォームを提供します。マージする前に品質を担保するための重要なプロセスです。

Q4. GitHub Flowの正しい手順を並べてください。

A. mainにマージ →
B. featureブランチ作成 →
C. PRを作成 →
D. ローカルで実装・コミット → E. GitHubにpush → F. レビューを受けて修正 → G. featureブランチを削除

正解: B → D → E → C → F → A → G

解説: mainから派生させてfeatureブランチで開発し、PRを通じてレビューを経てmainにマージするのがGitHub Flowの流れです。マージ後はブランチを削除してリポジトリをきれいに保ちます。

Q5. 良いPRの説明文で重視すべきは「What（何を変えたか）」か「Why（なぜ変えたか）」か。その理由も答えてください。

正解: Why（なぜ変えたか）

解説: 「何を変えたか」はコードを見ればわかります。PRの説明文では変更の背景・意図・意思決定の理由を伝えることが重要です。未来のレビュアーや自分自身が変更の文脈を理解するための貴重な記録になります。

Q6. コンフリクトが発生した場合、最初に行うべき操作はどれですか。

A. feature ブランチを削除する
B. main の最新を取り込む
C. PRを閉じる
D. 新しいブランチを作る

正解: B

解説: コンフリクトはmainとfeatureブランチの変更が競合した際に起きます。まず git checkout main && git pull origin main でmainを最新化し、その後featureブランチにmergeすることで競合箇所を特定して解消できます。

Q7. GitHub Actionsを活用してPR作成時に自動テスト・Lintを実行するとき、設定ファイルはどのディレクトリに置きますか。

正解: .github/workflows/ ディレクトリ

解説: .github/workflows/ 以下にYAMLファイルを置くことでGitHub Actionsのワークフローが定義されます。CIが通らないとマージできないブランチ保護設定と組み合わせることで品質ゲートとして機能します。

Q8. Issueのコミットメッセージに fix #123 と書くと何が起きますか。

正解: そのコミットを含むPRがmainにマージされた時点で、Issue #123 が自動的にクローズされます。

解説: GitHubはコミットメッセージやPR本文内の fix #N・close #N・resolve #N といったキーワードを認識し、マージ時に対応するIssueを自動クローズします。手動でクローズし忘れることを防げます。

Q9. GitHub Projectsを個人開発で活用するメリットは何ですか。

正解: IssueとPRをKanbanボードやSpreadsheetで管理し、「やること・進行中・完了」を可視化できます。

解説: 個人開発でもタスクが積み重なると何から手を付けるべきか見えにくくなります。ProjectsでIssueを整理することで優先順位を保ちながら進捗を管理でき、モチベーション維持にも役立ちます。

Q10. 個人開発でブランチを切らずにmainへ直接コミットし続けることの問題点を説明してください。

正解: 変更の単位が不明確になり、特定の機能だけをロールバックしにくくなります。自己レビューの機会も失われます。

解説: featureブランチを切ってPRを作る習慣は、チーム開発だけでなく個人開発でも有効です。変更を小さく保ち、PRで振り返ることで「なぜこのコードを書いたか」を記録に残せます。CI/CDとも組み合わせやすいです。

この章で手を動かすときの確認

この章は導入編の STEP 3にある「手を動かす」の章です。本文を読み終えたあと、次の観点だけ確認すると次へ進みやすくなります。

この章で確認すること:

feature ブランチから PR を作る流れを理解する
コンフリクト解消の基本手順を説明できる

次に活きる章:

Issue ベースの開発フローを回す
CI/CD基礎

対応する完成条件（checklist.yml）:

補助参照:

Git と GitHub の基本フローに慣れる