概要
GitHubワークフローとは、「チームで協力してコードを開発・管理するための一連の流れ」です。
個人で開発しているときは、直接コードを書いて保存すればOKです。 でも、チームで開発するときは、誰かが書いたコードが他の人のコードと衝突したり、 バグが混入したりするリスクがあります。
GitHubワークフローを使えば、安全に、効率的に、チームで開発できるようになります。
豆知識：このページでは、GitHubの基本を理解していることを前提に、 より実践的なワークフローについて説明します。
GitHubの全体の流れを理解する
以下のデモで、GitHubでよく使われる概念（リポジトリ、コミット、プッシュ、プル、ブランチ）の流れを体験できます。 「何をしているサービスなのか」が一目で分かります。
Gitフロー体験デモ
実際のチーム開発の流れをステップごとに確認してみましょう
1. mainブランチ（本番）
本番環境で動いているコード
アクション： 安定版のコード
これがチーム開発の基本的な流れです。ブランチを切って開発し、PRでレビューしてからマージします。
プルリクエスト（Pull Request）とは？
プルリクエストは、「この変更をmainに取り込んでください」とお願いする機能です。 単なる統合ではなく、レビューのプロセスが含まれます。
なぜプルリクエストが必要なのか？
もし全員が直接mainブランチに変更を加えたら、 どうなるでしょうか？
- 動かないコードが本番に混入する
- 他人の変更と衝突して壊れる
- 誰の変更が原因でバグったか分からない
プルリクエストを使えば、これらの問題を防げます！
プルリクエストの基本的な流れ
- ブランチを作成: 新機能開発用に
feature/loginなどの名前でブランチを切る - 開発＆コミット: ブランチ上で自由に開発・コミット
- プッシュ: GitHubにブランチをアップロード
- プルリクエスト（PR）作成: 「mainに統合してください」とお願い
- コードレビュー: チームメンバーがコードを確認・承認
- マージ: 問題なければmainブランチに統合される
補足：プルリクエストの流れを視覚的に理解したい場合は、上の「GitHubの全体の流れを理解する」デモを参照してください。
PRのメリット
- コードレビュー: 他の開発者が確認できる
- 議論の場: コメントで「ここはこうした方が良い」と提案
- 履歴が残る: なぜこの変更をしたのか記録される
- テスト自動化: PR作成時に自動テストを走らせられる
PRの作り方
- GitHubのリポジトリページで「Pull requests」タブをクリック
- 「New pull request」をクリック
- 統合したいブランチ（例：
feature/login）を選択 - 変更内容を説明するタイトルと本文を書く
- 「Create pull request」をクリック
# PRのタイトル例
feat: ユーザーログイン機能を追加
# PRの説明例
## 変更内容
- ログインフォームのUI実装
- JWT認証の実装
- ログインAPIエンドポイント追加
## テスト
- [x] ログイン成功時のテスト
- [x] ログイン失敗時のエラーハンドリング
## スクリーンショット
（画像を貼る）
## 関連Issue
Closes #123コードレビューのポイント
PRを見る側（レビュアー）も重要な役割です：
- ロジックは正しいか: バグがないか確認
- 読みやすいか: 他の人が理解できるコードか
- テストはあるか: 動作確認ができるか
- セキュリティリスクはないか: 脆弱性がないか
ポイント：PRは「マージするかしないか」だけでなく、チームの学びの場でもあります。 新しいやり方を共有したり、ベストプラクティスを議論したりできます。
よくあるブランチ戦略
ブランチ戦略とは、「どのようにブランチを管理して開発を進めるか」というルールです。 プロジェクトの規模や開発スタイルによって、適切な戦略が変わります。
| 戦略 | 説明 | 向いている規模 |
|---|---|---|
| GitHub Flow | mainから直接featureブランチを切り、PRでマージ | 小〜中規模、頻繁デプロイ |
| Git Flow | main、develop、feature、releaseなど複数ブランチを使う | 大規模、リリースサイクルが明確 |
| Trunk-based | mainブランチに直接コミット、短命なブランチのみ | 超高速開発、CI/CD完備 |
GitHub Flow（おすすめ）
初心者やスタートアップにはGitHub Flowがおすすめです。 シンプルで理解しやすく、それでいて十分強力です。
- シンプル: mainブランチとfeatureブランチだけ
- 理解しやすい: 複雑なルールがない
- 頻繁にデプロイ: 小規模な変更をすぐに反映できる
Git Flow
大規模なプロジェクトや、リリースサイクルが明確な場合に適しています。
- 安定版と開発版を分離: main（本番）とdevelop（開発）を分ける
- リリース管理: releaseブランチでリリース準備
- ホットフィックス対応: 緊急修正用のhotfixブランチ
Trunk-based
超高速開発や、CI/CDが完備されている場合に適しています。
- 高速開発: ブランチを切らずに直接mainにコミット
- 短命なブランチ: 必要最小限のブランチのみ
- 高度なCI/CDが必要: 自動テストとデプロイが必須
実践的なヒント
1. ブランチ名は分かりやすく
feature/login、fix/bug-123のように、 何のためのブランチか分かる名前を付けましょう。
2. PRは小さく、頻繁に
大きなPRはレビューが大変です。 小さな変更を頻繁にPRすることで、レビューも早く、マージも早くなります。
3. PRの説明は丁寧に
「何を変更したか」「なぜ変更したか」「どうテストしたか」を 明確に書くと、レビューがスムーズに進みます。
4. レビューは建設的に
レビューは「間違いを指摘する場」ではなく、「より良いコードを作る場」です。 建設的なコメントを心がけましょう。