1. はじめに：コードを書くだけでは終わらない時代の「必須スキル」
現代のソフトウェア開発では、「コードを書くだけ」ではエンジニアとして通用しません。
バージョン管理（Git）とチーム開発の文化を理解することが、即戦力エンジニアへの第一歩です。
あなたはこんなことで悩んでいませんか？
- Gitの基本は学んだが、チームではどう使われているのか分からない
- プルリクエスト（PR）って実際どのようにやるの？
- コードレビュー文化があるチームで働いてみたい
- Force pushしてリポジトリ壊した経験がある…😱
本記事では、実際の現場で使われているGit・GitHubの使い方を、体系的に・丁寧に・実践的に解説します。
未経験〜若手エンジニアが**「今すぐ試したくなる」**ような内容を意識して執筆しています。
2. GitとGitHubの役割を改めて理解しよう
2.1 Gitとは？
Gitは「ソースコードのタイムマシン」
Gitは、ファイルの変更履歴をすべて記録する分散型バージョン管理システムです。
1つのプロジェクトを複数人で同時に進めながらも、各人の作業を安全に記録・統合できるのが最大の利点。
- ✅ いつでも過去の状態に戻せる（
git log/git checkout） - ✅ 誰が・いつ・何を変更したか分かる（責任の明確化）
- ✅ 他人の作業と自分の作業を安全に合流できる（マージ・コンフリクト）
2.2 GitHubとは？
GitHub = Gitリポジトリのクラウド共有＋コラボレーション基盤
GitHubでは、Gitで管理されたリポジトリをインターネット上で管理できます。
それだけでなく、以下のような開発支援機能が充実しています：
- 📌 Pull Request（レビュー・議論の場）
- 🗂 Issue（タスク管理）
- 🤝 Actions（CI/CD）
- 👩💻 GitHub Pages（ホスティング）
特にPull Requestの存在が、チーム開発を「コードの共有」から「知識の共有」へと進化させます。
3. 実践ステップ：Gitを使ったチーム開発ワークフロー完全解説
3.1 役割とブランチの基本設計
| ブランチ | 用途 | 備考 |
|---|---|---|
main |
本番用、常にデプロイ可能 | 絶対に壊さない |
develop |
開発統合ブランチ | チーム内マージ用 |
feature/* |
各機能開発用 | 個人ごとに切る |
hotfix/* |
緊急修正 |
main から直接分岐 |
# 例：ログイン画面開発用ブランチ
git checkout -b feature/login-form develop
3.2 開発フロー：1人作業からPRレビューまで
ステップ①：自分の作業ブランチを切る
git checkout -b feature/add-login-api develop
ステップ②：変更をローカルでコミット
git add .
git commit -m "API: implement login endpoint using JWT"
ステップ③：GitHubにPush
git push origin feature/add-login-api
ステップ④：Pull Requestを作成
- GitHub上でPRを作成
- 説明文に「目的・背景・変更点・確認事項」を明記
- Reviewerにレビュー依頼
ステップ⑤：レビュー → コメント対応 → マージ
# developへマージ（GitHub UI）
# 不要になったブランチを削除
git branch -d feature/add-login-api
git push origin --delete feature/add-login-api
3.3 Pull Requestの作成例
## 概要
ログインAPIのエンドポイントを作成。JWTによるトークン認証を導入。
## 目的
- ユーザーの認証機能を実装
- フロントエンドと連携予定
## 変更点
- `routes/auth.js` を新規作成
- JWTによるサインイン処理を追加
- ユーザーのスキーマを修正
## 確認事項
- [x] Postmanで認証処理が成功するか
- [x] エラー時に400/401が返るか
4. 現場ノウハウ：ミス・文化・ツール連携まで
4.1 よくある失敗と対策
| 失敗例 | 対策方法 |
|---|---|
mainブランチに直接Pushして怒られる |
mainブロック設定＋CIで強制ストップ |
| コンフリクト多発 | 定期的なdevelopからのrebase・Pull |
| PRが大きすぎてレビューされない | 「1機能＝1PR」ルール導入 |
| 履歴が壊れてしまった |
--forceではなく--force-with-leaseを使用 |
4.2 実務で便利なツール連携
| ツール | 機能 |
|---|---|
| GitHub Actions | Push時にLint/Testを自動実行 |
| Slack | PR作成時に通知飛ばす |
| Linear | Issue → ブランチ名の自動紐づけ |
| Prettier/ESLint | コードの自動整形＋Lintチェック |
5. 発展編：Gitの「文化」をどう育てるか？
📌 Gitを軸にしたチーム開発の文化
- PRは「コードを提出する場」ではなく「知識と背景を共有する場」
- コメントは「責める」ためではなく「品質を高める」ため
- Gitの履歴は「未来の自分」へのドキュメント
✅ チームで取り組む工夫
- PRレビュー定例会：週1回、雑談含めてレビューをチームで学ぶ
- PRテンプレートを共有：認識齟齬をなくす
- Gitコマンド勉強会：新人や非エンジニアも含めて文化を共有
6. まとめ：Gitを知ることは、チームを知ること
本記事では、「Gitを使ったチーム開発の第一歩」として、現場で役立つフロー、実例、文化を紹介しました。
Gitは単なるツールではなく、「チームを育てる土台」でもあります。
🎯 今日から実践できる3つのこと
- プロジェクトでは必ずブランチを切る運用にする
- PRに背景と目的を書くようにする
- 他人のPRをレビューする習慣をつける
💬 コメント・フィードバック歓迎！
この記事が役立った方は、ぜひ「LGTM」や「ストック」お願いします！
質問・補足希望があればコメント欄へどうぞ。X（旧Twitter）で拡散も大歓迎です。