1. 👋 はじめに
前回の記事では、Gitの基本（コミット・ブランチ・コンフリクト）を学びました。
今回はいよいよ GitHub を使って、チームでの開発フローを身につけましょう！
この記事を読めば：
- ✅ GitとGitHubの違いがわかる
- ✅ リモートリポジトリへのpush・pullができる
- ✅ プルリクエストを使ったチーム開発の流れがわかる
2. 🤔 GitとGitHubの違い
「GitとGitHubって同じじゃないの？」という疑問、よくあります！実はまったく別物です。
🔧 Git
└─ バージョン管理ツール（ソフトウェア）
└─ ローカル（自分のPC）で動く
└─ コマンドラインで操作する
└─ 無料・オープンソース
🐙 GitHub
└─ Gitリポジトリをクラウドで管理するサービス（ウェブサービス）
└─ GitHubのサーバー上でリポジトリを管理
└─ ブラウザで操作できる
└─ チームでコードを共有・レビューできる
GitHubと似たサービス
GitHubの他にも同様のサービスがあります：
| サービス | 特徴 |
|---|---|
| 🐙 GitHub | 世界最大・オープンソースが多い |
| 🦊 GitLab | 自己ホスティング可能・CI/CD機能が充実 |
| 🪣 Bitbucket | Atlassian製・JiraやConfluenceと連携しやすい |
3. 🏠 ローカルとリモートの概念
GitHubを使うときに登場する重要な概念です。
🖥️ ローカルリポジトリ | 🌐 リモートリポジトリ
（自分のPC上） | （GitHubのサーバー上）
|
📁 my-project/ | 🐙 github.com/username/my-project
└─ main.py |
└─ .git/
push（アップロード） →
← pull（ダウンロード）
| 用語 | 意味 |
|---|---|
| 🏠 ローカル | 自分のPCの中にあるリポジトリ |
| 🌐 リモート | GitHubのサーバー上にあるリポジトリ |
| ⬆️ push | ローカルの変更をリモートにアップロード |
| ⬇️ pull | リモートの最新状態をローカルに取り込む |
| 📥 clone | リモートリポジトリをローカルにコピー |
4. 🚀 GitHubの始め方
アカウント作成
https://github.com にアクセスしてアカウントを作成します。無料プランで十分です！
新しいリポジトリを作成
- GitHubにログインして右上の
+→New repositoryをクリック - リポジトリ名を入力（例：
my-project） -
Public（公開）またはPrivate（非公開）を選択 -
Create repositoryをクリック
SSHキーの設定（推奨）
GitHubとの通信を安全・便利にするためにSSHキーを設定します。
# SSHキーを生成
ssh-keygen -t ed25519 -C "your@email.com"
# → Enterを3回押してデフォルト設定で生成
# 公開鍵を表示してコピー
cat ~/.ssh/id_ed25519.pub
コピーした公開鍵をGitHubに登録（GitHubダッシュボードで登録）：
- 右上にあるご自身のアイコンから
Settings→SSH and GPG keys→New SSH key→ 貼り付けて保存
"your@email.com"はコメントです。認証とは無関係な識別ラベルで、誰のキーかを判別するためです。内容は何でもよく、変更してもセキュリティや動作に影響しません。
5. ⬆️ push：ローカルからGitHubへアップロード
はじめてのpush
# 1️⃣ ローカルリポジトリをGitHubと紐付け
git remote add origin git@github.com:username/my-project.git
# 上記のgit@～について簡単に解説
git@github.com:username/repository.git
│ │ │ └─ リポジトリ名
│ │ └─ GitHubのユーザー名
│ └─ 接続先サーバー（GitHub）
└─ SSHのログインユーザー名
# 2️⃣ リモートの確認
git remote -v
# origin git@github.com:username/my-project.git (fetch)
# origin git@github.com:username/my-project.git (push)
# 3️⃣ pushする
git push -u origin main
# -u は「今後はこのリモート・ブランチをデフォルトにする」という設定
# 次回からは git push だけでOK！
2回目以降のpush
# ファイルを編集・コミットしたあと
git add .
git commit -m "ログイン機能を追加"
git push # これだけでOK！🎉
originって何？
origin = リモートリポジトリのニックネーム
GitHubのURLは長いので、「origin」という短い名前で呼ぶ
git@github.com:username/my-project.git
↓ origin という名前をつける
git push origin main
6. ⬇️ clone・pull：GitHubからダウンロード
clone：リポジトリを丸ごとコピー
チームに新しいメンバーが加わったときや、他のPCで作業するときに使います。
# GitHubのリポジトリをローカルにコピー
git clone git@github.com:username/my-project.git
# クローンするとフォルダが自動作成される
cd my-project
ls
# main.py README.md ...
pull：最新の変更を取り込む
チームメンバーがpushした変更を自分のローカルに取り込むときに使います。
# リモートの最新状態を取得して、ローカルに反映
git pull
# 詳しく書くと
git pull origin main
fetch と pull の違い
git fetch → リモートの変更を確認するだけ（ローカルには反映しない）
git pull → リモートの変更を取得 + ローカルに反映（fetch + merge）
🔍 まず確認してから取り込みたいときは fetch
⚡ とりあえず最新にしたいときは pull
7. 👥 チーム開発の基本フロー
GitHubを使ったチーム開発の標準的な流れを紹介します。GitHub Flow と呼ばれるシンプルで人気のあるフローです。
GitHub Flow の全体像
1️⃣ mainブランチから作業ブランチを作成
↓
2️⃣ 作業ブランチで開発・コミット
↓
3️⃣ GitHubにpush
↓
4️⃣ プルリクエスト（PR）を作成
↓
5️⃣ チームメンバーがコードレビュー
↓
6️⃣ レビューOK → mainにマージ
↓
7️⃣ ブランチを削除・次の作業へ
ステップ①：作業ブランチを作成
# まず最新のmainを取得
git switch main # mainに移動
git pull # 最新状態を取得
# 作業ブランチ(feature/user-profile)を作成して切り替え
git switch -c feature/user-profile
ブランチ名の命名規則（例）：
feature/xxx → 新機能の開発
bugfix/xxx → バグ修正
hotfix/xxx → 緊急の本番バグ修正など
ステップ②：開発・コミット
# 作業ブランチで開発する
# ... コードを書く ...
# こまめにコミット
git add .
git commit -m "ユーザープロフィールページを追加"
git commit -m "プロフィール画像のアップロード機能を追加"
ステップ③：GitHubにpush
git push -u origin feature/user-profile
ステップ④：プルリクエスト（PR）を作成
GitHubのページを開くと「Compare & pull request」ボタンが表示されます。
プルリクエストに書くべき内容（参考）：
## 📝 変更内容
ユーザープロフィールページを新規追加しました。
## 🎯 変更の目的
ユーザーが自分の情報を確認・編集できるようにするため。
## 🔍 レビューしてほしい点
- プロフィール画像のバリデーション処理（50行目）
- エラーハンドリングの方針が合っているか確認お願いします
## 📸 スクリーンショット
（画面キャプチャがあると親切！）
ステップ⑤：コードレビュー
チームメンバーがコードを確認して、コメントや修正依頼を行います。
レビューで使う機能：
💬 コメント → 質問・提案（承認でも却下でもない）
✅ Approve → レビューOK！マージしていいよ
❌ Request changes → 修正してほしい点がある
レビューコメントの例：
👍「この実装いいですね！」
🤔「この変数名、もう少しわかりやすくできそうです。
例えば `userData` より `userProfile` の方が明確かも？」
⚠️「ここでエラーが起きた場合のハンドリングがないので
try-catchを追加した方がよいと思います」
ステップ⑥：修正してpush
レビューで指摘があったら修正してpushすると、PRに自動で反映されます。
# 修正する
# ... コードを直す ...
git add .
git commit -m "レビュー対応：変数名を修正"
git push # 同じブランチにpushするだけでPRに反映される！
ステップ⑦：マージして完了
Approveをもらったら Merge pull request ボタンでmainにマージ！
# マージ後はローカルのmainも最新にしておく
git switch main
git pull
# 不要になった作業ブランチを削除
git branch -d feature/user-profile
マージとは？
別々のブランチの変更履歴を1つに統合するコマンド。 例えば機能開発用のブランチで作った変更を、main ブランチに取り込む際に使います。
8. 🔧 知っておくと便利なGitHub機能
📋 Issues（イシュー）
バグ報告・機能要望・タスク管理に使います。
Issueの使い方：
🐛 バグを発見 → Issueを作成
💡 新機能のアイデア → Issueに書く
📋 タスクを一覧管理 → Issue + ラベルで整理
PRとIssueを紐付ける：
PRの説明文に「Closes #123」と書くと
→ マージ時にIssue #123 が自動でクローズされる！
🛡️ ブランチ保護ルール
mainブランチを守るための設定です。特にチーム開発ではなるべく設定しましょう。
Settings → Branches → Add rule
おすすめの設定：
✅ Require pull request before merging
→ 直接pushを禁止・必ずPRを通す
✅ Require approvals（1以上）
→ 最低1人のApproveがないとマージできない
※ Require pull request mergingにチェックを入れると出てきます
✅ Require status checks to pass
→ テストが通らないとマージできない
👀 .gitignore：GitHubに上げてはいけないファイルを指定
パスワードや環境設定ファイルは絶対GitHubに上げてはいけません！
# .gitignore ファイルを作成
touch .gitignore
# .gitignore の中身（例）
.env # 環境変数（パスワードなど）
__pycache__/ # Pythonのキャッシュ
node_modules/ # Node.jsのパッケージ
*.log # ログファイル
.DS_Store # macOSのシステムファイル
⚠️ 注意！
.envファイルをGitHubに上げてしまうと
APIキーやパスワードが世界中に公開されてしまいます😱
一度pushしてしまったら、履歴から完全削除が必要で
とても大変な作業になります…
必ず最初に.gitignoreを設定しましょう！
9. 📋 よく使うコマンド早見表（GitHub編）
# リモート操作
git remote add origin <URL> # リモートを登録
git remote -v # リモートの確認
git clone <URL> # リポジトリをコピー
git push -u origin main # 初回push
git push # 2回目以降のpush
git pull # 最新を取得して反映
git fetch # 最新を取得するだけ（反映しない）
10. 🎯 まとめ
| 概念 | 説明 |
|---|---|
| 🐙 GitHub | Gitリポジトリをクラウドで管理するサービス |
| 🏠 ローカル | 自分のPC上のリポジトリ |
| 🌐 リモート | GitHubサーバー上のリポジトリ |
| ⬆️ push | ローカル → リモートへアップロード |
| ⬇️ pull | リモート → ローカルへ取り込む |
| 📥 clone | リモートをローカルにまるごとコピー |
| 🔀 プルリクエスト | 変更のレビュー・マージ依頼 |
GitHubを使ったチーム開発の基本フローは 「ブランチを切る → 開発 → push → PR → レビュー → マージ」 のサイクルです。最初は慣れないかもしれませんが、繰り返すうちに自然と身につきます！💪
まずは自分のプロジェクトをGitHubにpushすることから始めてみましょう🌟
🔗 シリーズ記事
- 【第一回】Git基礎 → バージョン管理・コミット・ブランチ・コンフリクト
- 【第二回】GitHub入門（この記事）
💬 質問や感想があれば、コメント欄でお気軽にどうぞ!
👍 役に立ったら、いいね&ストックをお願いします!
🎓 ここまで読んでくださって、本当にありがとうございました!