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 の基本フローに慣れる