はじめに
エンジニアの必須スキルである Git / GitHub の知識、コマンド、運用、チーム開発での流れまで、実務で使える形にまとめました。個人開発・チーム開発のどちらでも役立つ内容です。
Git / GitHubとは？
Gitとは
分散型バージョン管理システムです。
ソースコードの履歴管理、差分管理、並行開発、過去の状態への復元が可能です。
GitHubとは
Gitリポジトリをオンラインで管理・共有できるサービスです。プルリクエスト、コードレビュー、Issue管理、CI/CDなどチーム開発に便利な機能が揃っています。
違い
一言でまとめると、Gitで管理するリポジトリをオンラインで共有・運用しやすくするためのサービスがGitHubです。
個人開発ではGitのみでも履歴管理やバージョン管理ができますが、リポジトリはローカルに存在するため、チームでの共有や共同作業にはリモートリポジトリが必要です。GitHubを使うことで簡単にリモートリポジトリを作成・管理でき、チーム開発やオープンソースプロジェクトでの協力がスムーズになります。
🚀 Git・GitHubを使用したプロジェクトのはじめ方
パターン1：
既にPC内にあるソースコードをGitHub上で管理したい場合
1️⃣ リモートリポジトリ作成
- 新規リポジトリを GitHub 上で作成
- 公開 or 非公開を設定
- 初期ファイル（README、.gitignore等）を必要に応じて作成
2️⃣ ローカルリポジトリを初期化
# 新規リポジトリを作成
git init
3️⃣ リモートリポジトリへプッシュ
# ステージングエリアに追加
git add . # (.で全て追加)
# コミットする（変更の記録をとる）
git commit -m "<コメント>"
# ブランチ名の変更（念の為）
git branch -M main
# リモートリポジトリの追加（リーカルと紐付け）
git remote add origin <リモートリポジトリURL>
# リモートリポジトリへのプッシュ（アップロード）
git push -u origin main
パターン2：既にGitHub上で管理されているソースコードをPC内にダウンロードして編集したい場合
git clone <リポジトリのURL>
クローンを行うことにより、以下のことが自動で行われます。
- ローカルリポジトリの作成
- リモートリポジトリとの紐付け
👥 チーム開発におけるGitHubの基本的な流れ
チーム開発では、1つのリポジトリを複数人で、効率よく編集するために、GitHubの機能（ブランチ、プルリクエスト、コードレビューなど）を活用します。
ここでは実務でよく使われる GitHub Flow の流れに沿って解説します。
個人開発でも使用できます。
1️⃣ リポジトリをクローンする
先ほどのパターン2のようにまずはチームのGitHubリポジトリをローカルに複製します。
git clone <リポジトリURL>
# プロジェクトディレクトリに移動
cd <プロジェクト名>
2️⃣ ブランチを作成する（ブランチを切る）
チーム開発では mainブランチに直接コミットせず、ブランチを作って作業します。
git checkout -b <ブランチ名>
git checkoutはブランチの移動コマンドだが、-b をつけることで新しいブランチを作成し、同時に切り替えることができる。
💡 主なブランチの種類
※あくまでも例なのでプロジェクトによって異なります。
| ブランチ名 | 説明 |
|---|---|
| main | mainブランチに直接コミットすることはなく、マージを行うだけ |
| develop | 開発の中心となるブランチ。
開発中は、developブランチからさらにブランチを切って、作業完了後に再びマージするという作業を繰り返す。
例 : develop/[バージョン番号など] |
| feature | 機能の追加や変更、バグ修正などを行うブランチ。
ブランチの名前は、変更の内容が分かるような名称に。developブランチから派生させ、作業完了後に再び developブランチにマージ。そして、マージ完了後に削除。
例 : feature/[機能名など] |
| release | 製品をリリースするために使うブランチ。developブランチからreleaseブランチを切って、そのブランチでリリース作業を行う。リリース作業が完了したら、mainブランチと developブランチにマージし、mainブランチのマージコミットにリリースタグ（バージョンなど）を打ち、その後、release ブランチは削除。
例 : release/[バージョン番号] |
| hotfix | 製品のリリース時に不具合が見つかった際に使用。
mainブランチからhotfixブランチを切って、緊急の修正を行う。修正完了後には、mainブランチとdevelopブランチにマージして、リリースタグ（マイナーバージョンなど）を打ち、その後、hotfixブランチは削除。
例 : hotfix/[バージョン番号]/[バグ識別名] |
3️⃣ 作業・コミットを行う
コードを編集後、変更をステージングし、コミットします。
git add .
git commit -m "ログイン機能のバリデーション追加"
💡 コミットメッセージのポイント
何をしたか一目でわかる内容にする
チームでルールがある場合（例: 英語で書く、prefixをつける）に従う
例えば、
# 新機能追加時
git commit -m "feat: Implement user registration form"
# バグ修正時
git commit -m "fix: Correct null pointer exception when user data is empty"
| Prefix | 説明 | 使用場面 |
|---|---|---|
| feat | 新機能の追加 | 新しい機能を追加したコミット |
| fix | バグの修正 | バグを修正したコミット |
| docs | ドキュメントの変更 | ドキュメント（例: README, API ドキュメントなど）を追加、修正、削除したコミット |
| style | コードのスタイルに関する変更 (フォーマット、セミコロンなど) | コードの意味に影響を与えないスタイルの修正（例: インデントの修正、不要な空白の削除、コードフォーマットの適用など） |
| refactor | コードのリファクタリング (機能変更なし) | コードの内部構造を変更したが、外部から見た動作は変わらないコミット（例: 変数名の変更、関数の分割・統合、ロジックの整理など） |
| test | テストコードの追加、修正 | 新しいテストコードの追加や既存のテストコードの修正を行ったコミット |
| chore | ビルドプロセス、補助ツール、依存関係などの管理に関する変更 | 開発環境やビルドシステムに関する変更（例: 依存ライブラリの更新、タスクランナーの設定変更、gitignore の修正など） |
| perf | パフォーマンス改善に関する変更 | コードのパフォーマンスを向上させるための変更を行ったコミット |
| build | ビルドシステムや外部依存関係に関する変更 | ビルドプロセス自体や、それに必要な外部ライブラリなどの依存関係を変更したコミット |
| ci | CI (継続的インテグレーション) パイプラインの設定やスクリプトに関する変更 | GitHub Actions、CircleCI などの CI/CD に関する設定ファイルやスクリプトを変更したコミット |
| revert | 直前のコミットを取り消す変更 | 誤った変更を取り消すために `git revert` コマンドを実行した際に生成されるコミット |
4️⃣ リモートにブランチをプッシュする
git push
5️⃣ プルリクエスト（Pull Request, PR）を作成する
GitHubの画面から作成したブランチでPRを作成します。
💡 PR作成時のポイント
タイトル：
何をしたPRなのか簡潔に書く
（例: ログイン機能のバリデーション追加）
説明欄：
以下のテンプレートに沿って内容を他の人からしてもわかりやすく簡潔に書く
## 変更の概要
* 変更の概要
* 関連するIssueやプルリクエスト
## なぜこの変更をするのか
* 変更をする理由
* 前提知識がなくても分かるようにする
## やったこと
* [x] やったこと
* [ ] やっていること
## 変更内容
* UIの変更ならスクリーンショット
* APIの変更ならリクエストとレスポンス
## 影響範囲
* ユーザーに影響すること
* メンバーに影響すること
* システムに影響すること
## どうやるのか
* 使い方
* 再現手順
## 課題
* 悩んでいること
* とくにレビューしてほしいところ
## 備考
* その他に伝えたいこと
レビュワー：
チームのルールに従ってレビュー担当者を設定
6️⃣ コードレビューを受ける
他のメンバーがPRを確認し、コメントや修正依頼を行います。
修正が必要なら：修正 → コミット → PRに反映
OKが出たら：レビュワーが Approve（承認）
7️⃣ PRをマージする
レビューが完了したら、PRをにマージします。
PRをマージするのは 通常、レビュワーやリポジトリ管理者（責任を持つ人） が行う。
8️⃣ ローカルを最新状態に保つ
git checkout main
git pull origin main
💡 実務で役立つポイント
✅ mainブランチの保護ルールを設定
- きほんmainブランチ触らず、ブランチを切って作業展開していく
- PR経由でしかマージできないようにする
- レビュー・CI必須にする（GitHubのブランチ保護機能）
✅ 小さな単位でのコミット・PR
コミットの頻度：
コミットは 小さな意味のある単位ごと に行うのがベスト。
💡 コミットのタイミング例
- 新しい機能の一部（例: バリデーションを追加した、APIの呼び出しを実装した）
- バグを1つ修正したとき
- ファイル構造や依存関係を更新したとき
- 実験的な作業を始める前のスナップショットとして
コミットが小さい単位であればあるほど、次のメリットがあります：
- 変更の意図がわかりやすい
- コードレビューがしやすい
- バグ発生時の調査がしやすい
プルリクエストの頻度：
PRは 1つの目的・機能・修正につき1つ が基本。
💡 PRの頻度の目安
-
1つの小さい機能や修正ごとにPRを出す
- 例: 「ログインフォームのバリデーション追加」
- 例: 「プロフィール編集画面のレイアウト調整」
- 作業時間で言えば半日〜1日以内で終わる内容でPRを出すのが理想
- 2日以上かかりそうな作業は分割できないか検討する
PRが小さい単位であれば：
- レビュー時間が短くなる
- マージコンフリクトが起きにくくなる
- CIのチェックも早く終わる
- リリースやロールバックが安全になる
✅ 知っておくと便利なGitコマンド・機能
ちょっとしたトラブル解決や作業効率アップに役立ちます。
🔍 git status - 状態確認の基本
作業中は こまめに git status を実行する習慣 をつけましょう。
git status
📝 git diff - 変更内容を確認
どこを変更したのか確認するコマンド。
git diff # ステージングしていない変更を見る
git diff --staged # ステージングした変更を見る
レビュー前に自分の変更を見直すのに便利です。
🔄 git log - コミット履歴を見る
履歴を確認できます。
git log --oneline --graph --decorate --all
💡 よく使うオプション
- --oneline：1コミットを1行表示
- --graph：ブランチの分岐・マージをツリー表示
- --decorate：ブランチ名・タグも表示
- --all：すべてのブランチを対象に表示
💡 git restore - 変更の取り消し
間違った変更を取り消したい場合。
git restore <ファイル名> # 作業ディレクトリの変更を取り消す
git restore --staged <ファイル名> # ステージングを外す
🌟 git stash - 一時退避
作業途中の変更を一時的に退避したいときに便利。
git stash
# 作業を中断して別の作業をする
git stash pop # 一時退避した内容を戻す
🚀 git fetch と git pull の違い
git fetch：
リモートの最新情報を取ってくるだけ（マージはしない）
git pull：
fetch + merge（ローカルにマージまで行う）
💡 コンフリクトを避けたい場合、まず git fetch → 差分確認 → 必要なら git merge が安全です。
✅ コンフリクトが発生したときの解決法
git status # コンフリクト中のファイル確認
# ファイルを手動で編集し、コンフリクト部分を解消
git add <解決したファイル>
git commit
# 必要なら
git push
コンフリクト部分の記号例:
<<<<<<< HEAD
現在のブランチのコード
=======
マージ対象のコード
>>>>>>> feature/branch
不要な記号を削除し、正しい状態に修正してください。
✅ 作業を一時停止して他の作業を行う場合
git stash # 作業中の変更を一時退避
git checkout <他のブランチ> # 他の作業ブランチに切り替え
# 作業後、元のブランチに戻る
git checkout <元のブランチ>
git stash pop # 退避した作業を戻す
📝 Issueの役割と使い方
GitHubの Issue は、チームで開発を進める上での「課題管理・タスク管理ツール」です。
バグ報告、機能要望、作業メモ、ドキュメント改善など幅広い用途で使われます。
実際の使い方の流れ
1️⃣ Issueを作成する
- タイトル：内容がわかる簡潔なもの
- 説明欄：背景、再現手順、スクショ、関連ファイル、期待する結果などを記載
💡 Issueテンプレート を用意するとチームで統一感が出ます
（例：.github/ISSUE_TEMPLATE/bug_report.md など）
2️⃣ ラベル・担当者・マイルストーンを設定する
- ラベル：バグ、機能追加、リファクタリング、緊急、優先度高など
- 担当者（Assignee）：そのIssueを対応する人
- マイルストーン：どのリリースで対応するか
3️⃣ ブランチ作成時に関連付ける
Issue番号をブランチ名・コミット・PRに関連付けると管理がしやすくなります。
💡 ブランチ名の例：
feature/123-ログイン機能
fix/456-APIエラー対応
4️⃣ PRにIssueをリンクさせる
PRの説明に次のように書くことで、PRマージ時にIssueを自動でクローズできます。
close #123
fix #456
resolve #789
さいごに
本記事では、Git / GitHub の基礎からチーム開発で実務的に使える運用方法までを解説しました。
チームによって方針などもさまざまなため、臨機応変に対応できることが大切だと思います。
また、実際に使ってみて覚えていくのが一番です。実務で使用できれば元論ですが、個人開発でも大いに活用できます。ぜひ調べながら個人でも活用していきましょう。