Day 5: ブランチとプルリクエスト - チーム開発の第一歩 🤝
🎯 今日の目標
- GitHubをSNSとして楽しむ方法を理解する
- Issueを使ったコミュニケーションを体験する
- ブランチの概念を理解する
- プルリクエスト（PR）を作成できるようになる
- レビューとマージの流れを体験する
- 簡単なコンフリクトを解決できるようになる
💬 GitHubをSNSとして楽しむ - Issueとコミュニケーション
GitHubは開発者のSNS！
GitHubは単なるコード管理ツールではありません。開発者同士がつながり、交流できるSNSでもあるのです。
Issueは掲示板のようなもの
Issueは、プロジェクトの「掲示板」のような存在です。バグ報告、機能提案、質問など、様々な話題について議論できます 。
Issueでできること
- 問題の報告: 「ここがうまく動かない！」
- 新機能の提案: 「こんな機能があったらいいな」
- 質問: 「この部分の使い方がわからない」
- 議論: 「このアプローチについてどう思う？」
コミットにコメントをつけよう
GitHubでは、各コミットに対してコメントを残すことができます。これは：
- コードの特定の行について質問する
- 改善案を提案する
- 「いいね！」と褒める
- 学んだことを共有する
など、様々な使い方ができます。
友達のリポジトリをWatchしよう
興味のあるプロジェクトや友達のリポジトリをWatchすると、更新情報が通知されます。まるでSNSで友達をフォローするような感覚ですね！
📚 ブランチと は？
ブランチの基本概念
ブランチは、メインの開発ラインから分岐した独立した作業空間です。新機能の開発やバグ修正を、他の人の作業に影響を与えずに行うことができます。
main ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
↓
feature ━━━━━━━━━○━━━○━━━○━━━━━━━━━━━━━━━━━━━━
新機能を開発
なぜブランチを使うの？
- 安全性: メインのコードを壊さない
- 協働: 複数人が同時に異なる機能を開発できる
- 履歴管理: 各機能の開発履歴が明確になる
- 実験: 新しいアイデアを気軽に試せる
🌿 ブランチの作成と切り替え
1. 現在のブランチを確認
ブラウザでリポジトリを開き、ブランチボタンをクリックすると現在のブランチが表示されます。
2. 新しいブランチを作成
- ブランチのドロップダウンメニューをクリック
- テキストボックスに新しいブランチ名を入力（例:
feature/profile-update） - 「Create branch: feature/profile-update from 'main'」をクリック
ブランチ名の付け方のコツ
良い例:
- feature/add-dark-mode
- fix/login-error
- update/readme-instructions
避けたい例:
- test
- mywork
- branch1
📨 プルリクエスト（PR）の作成
プルリクエストとは？
自分の変更を本番環境（mainブランチ）に取り込んでもらうためのリクエストです。コードレビューを通じて、品質を保ちながら開発を進められます。
プルリクエストは改善提案の場
プルリクエストは、単に変更を取り込んでもらうだけでなく、みんなで議論し、より良いものを作り上げる場でもあります。遠慮せずに意見を交換しましょう！
PR作成の手順
1. ブランチで変更を加える
# 例: READMEに新しいセクションを追加
## 🌟 新機能
- ダークモード対応
- 多言語サポート
2. 変更をコミット
- ファイルを編集
- 「Commit changes」ボタンをクリック
- わかりやすいコミットメッセージを入力
3. プルリクエストを作成
- リポジトリのトップページに戻る
- 「Compare & pull request」ボタンをクリック
- PR作成画面で以下を入力:
## 概要
プロフィールページに新機能セクションを追加しました。
## 変更内容
- 🌟 新機能セクションを追加
- ダークモード対応について記載
- 多言語サポートについて記載
## 確認項目
- [ ] READMEの表示が正しいか確認
- [ ] 誤字脱字がないか確認
- [ ] マークダウンの書式が正しいか確認
- 「Create pull request」ボタンをクリック
👀 レビューとマージ
レビューの重要性
- バグの早期発見: 他の人の視点でミスを見つけられる
- 知識共有: チーム全体のスキル向上
- 品質向上: より良いコードに改善できる
- 交流の場: レビューを通じて開発者同士が交流できる
レビューコメントの例
良いコメント:
- 「この部分をもう少し詳しく説明すると、初心者にもわかりやすくなると思います」
- 「絵文字を使って見やすくなりましたね！」
- 「ここにスクリーンショットがあると更に良いかもしれません」
避けたいコメント:
- 「ダメ」
- 「全然違う」
- 「やり直し」
マージの手順
- レビューが完了し、承認されたら
- 「Merge pull request」ボタンをクリック
- マージ方法を選択（詳細は下記）
- 「Confirm merge」をクリック
- ブランチの削除（オプション）
マージの3つの選択肢
1. Create a merge commit（マージコミット）
- 特徴: すべてのコミット履歴を保持
- 使用場面: 開発の経緯を残したい場合
- メリット: 完全な履歴が残る
- デメリット: 履歴が複雑になりやすい
main ━━━━━━━━━━━━━━━━○━━━━━━━
↗ ↓
feature ━━━○━━━○━━━○ マージコミット
2. Squash and merge（スカッシュマージ）
- 特徴: すべてのコミットを1つにまとめる
- 使用場面: 細かい作業履歴を整理したい場合
- メリット: 履歴がきれいになる
- デメリット: 詳細な開発過程が失われる
main ━━━━━━━━━━━━━━━━○━━━━━━━
↑
feature ━━━○━━━○━━━○ 1つのコミットに統合
3. Rebase and merge（リベースマージ）
- 特徴: コミットを一直線に並べ直す
- 使用場面: きれいな直線的な履歴を保ちたい場合
- メリット: 履歴が見やすい
- デメリット: 履歴の書き換えが発生
main ━━━━━━━━━━━━━━━━━━━○━━━○━━━○━━━
↑ ↑ ↑
feature ━━━○━━━○━━━○ 各コミットを移動
マージ時の注意点
マージ前の確認事項
- テストは通っているか: CIのチェックが緑色か確認
- コンフリクトはないか: 解決済みであることを確認
- レビューは完了しているか: 必要な承認を得ているか
- ドキュメントは更新されているか: 変更に応じた文書の更新
マージ方法の選び方
- チームの方針を確認: プロジェクトごとにルールがある場合が多い
- PRの内容を考慮:
- 機能追加: Create a merge commit
- バグ修正: Squash and merge
- リファクタリング: Rebase and merge
- 履歴の重要性: 後で参照する可能性があるなら詳細を残す
マージ後の作業
- ブランチの削除: 不要になったブランチは削除
- 関連するIssueのクローズ: 解決したIssueは閉じる
- チームへの通知: 重要な変更は共有
⚔️ コンフリクトの解決
コンフリクトとは？
複数の人が同じファイルの同じ場所を編集したときに発生する競合状態です。
コンフリクトの例
<<<<<<< feature/update-title
# 私のすごいプロジェクト
=======
# Our Amazing Project
>>>>>>> main
解決方法
-
GitHubのWebエディタで解決:
- 「Resolve conflicts」ボタンをクリック
- どちらの変更を採用するか選択
- または両方を組み合わせて編集
-
解決後の例:
# 私のすごいプロジェクト / Our Amazing Project
🎯 実践演習
演習0: コミュニケーション体験
- クラスメートのリポジトリにIssueを作成してみよう
- 「README.mdの〇〇の部分がわかりやすかったです！」
- 「ここにスクリーンショットがあるともっと良いかも」
- 友達のコミットにコメントを残してみよう
- コードの良い点を褒める
- 質問してみる
- 興味のあるリポジトリをWatchしてみよう
演習1: 初めてのブランチ作成
practice/your-nameというブランチを作成- 自己紹介ファイルを追加
- mainブランチに戻って違いを確認
演習2: PRの作成とマージ
- ブランチで
practice.mdファイルを作成 - 好きな食べ物リストを追加
- PRを作成してセルフマージ
演習3: コンフリクトの体験
- mainブランチで
conflict-test.mdを作成 - 2つの異なるブランチから同じファイルを編集
- PRでコンフリクトを解決
🚀 応用テクニック
ブランチ戦略
- Feature Branch: 機能ごとにブランチを作成
- Git Flow: 開発用、リリース用など用途別にブランチを管理
- GitHub Flow: シンプルにmainとfeatureブランチのみ
PRテンプレート
.github/pull_request_template.mdを作成すると、PR作成時に自動的にテンプレートが適用 されます。
## 変更の概要
## 変更の種類
- [ ] バグ修正
- [ ] 新機能
- [ ] ドキュメント更新
- [ ] その他
## チェックリスト
- [ ] 動作確認済み
- [ ] ドキュメント更新済み
- [ ] レビュー依頼済み
❓ よくある質問
Q: ブランチを削除してしまった！
A: GitHubの「branches」ページから、最近削除されたブランチを復元できます。
Q: 間違えてマージしてしまった！
A: PRのページから「Revert」ボタンで変更を取り消すPRを作成できます。
Q: コンフリクトが解決できない！
A: 一旦落ち着いて、変更内容を整理してから解決しましょう。必要であれば、チームメンバーに相談してください。
📝 今日のまとめ
✅ GitHubがSNSとしても楽しめることを学びました ✅ Issueやコメントを使ったコミュニケーション方法を理解しました ✅ ブランチを使った安全な開発方法を学びました ✅ プルリクエストでコードレビューの流れを体験しました ✅ コンフリクトの解決方法を理解しました
明日は、GitHub Classroomを使った課題の提出方法を学びます！