第3章 Gitの高度な機能

基本操作と設定ファイルを押さえたところで、
この章ではもう一歩踏み込んだ Git の高度な機能 を見ていきましょう。

どれも「毎日使う」わけではありませんが、
管理者として 「いつ、なぜ使うか」を判断できる ことが大切です 🧰

3.1 submodules ─ リポジトリの中にリポジトリ

submodules とは？

submodule は、Git リポジトリの中に 別の Git リポジトリ を取り込む仕組みです。
共通ライブラリや共有コンポーネントを複数プロジェクトで使いたいときに便利です。

flowchart TD
    subgraph "メインリポジトリ (my-app)"
        A["src/"]
        B["package.json"]
        C["libs/shared-ui
(submodule 📦)"]
    end
    subgraph "別のリポジトリ"
        D["shared-ui リポジトリ
独立した Git 履歴を持つ"]
    end

    C -. "特定のコミットを参照" .-> D

    style C fill:#E3F2FD,stroke:#1E88E5,color:#0D47A1
    style D fill:#F3E5F5,stroke:#8E24AA,color:#4A148C

基本操作

submodule の追加

# リポジトリに submodule を追加
git submodule add https://github.com/your-org/shared-ui.git libs/shared-ui

# 自動的に以下が作成される
# - libs/shared-ui/      (submodule のディレクトリ)
# - .gitmodules           (submodule の設定ファイル)

[submodule "libs/shared-ui"]
    path = libs/shared-ui
    url = https://github.com/your-org/shared-ui.git

submodule を含むリポジトリを clone する

# 方法1：clone 時に一緒に取得
git clone --recurse-submodules https://github.com/your-org/my-app.git

# 方法2：clone 後に取得
git clone https://github.com/your-org/my-app.git
cd my-app
git submodule init
git submodule update

# 方法2の短縮形
git submodule update --init --recursive

submodule の更新

# submodule を最新にする
cd libs/shared-ui
git checkout main
git pull
cd ../..

# メインリポジトリで参照を更新
git add libs/shared-ui
git commit -m "chore: shared-ui を最新に更新"

# 全 submodule を一括で最新に
git submodule update --remote

運用上の注意点

flowchart TD
    A["submodule を使うべき？"]
    A -- "共有ライブラリが
独立して開発される" --> Y["✅ submodule が適切"]
    A -- "モノレポで
一緒に管理できる" --> N1["❌ モノレポのほうがシンプル"]
    A -- "バージョン固定だけでいい" --> N2["❌ パッケージマネージャ
(npm/pip)で十分"]

    style Y fill:#E8F5E9,stroke:#43A047,color:#1B5E20
    style N1 fill:#FFF9C4,stroke:#F9A825,color:#F57F17
    style N2 fill:#FFF9C4,stroke:#F9A825,color:#F57F17

3.2 Git LFS ─ 大容量ファイルの管理

なぜ Git LFS が必要なの？

Git はテキストファイルの管理が得意ですが、
大きなバイナリファイル（画像、動画、PSD、AI ファイルなど）を
そのまま管理すると、リポジトリが肥大化して全員に影響が出ます。

flowchart LR
    subgraph "通常の Git"
        A["コミットごとに
ファイル全体を保存"] --> B["リポジトリが
どんどん肥大化 💥"]
    end
    subgraph "Git LFS"
        C["ファイル本体は
別サーバーに保存"] --> D["リポジトリには
ポインタだけ 🪶"]
    end

    style B fill:#FFEBEE,stroke:#E53935,color:#B71C1C
    style D fill:#E8F5E9,stroke:#43A047,color:#1B5E20

セットアップ

# Git LFS のインストール（初回のみ）
# macOS
brew install git-lfs

# Windows (winget)
winget install GitHub.GitLFS

# Git LFS を有効化（初回のみ）
git lfs install

追跡するファイルの設定

# 特定の拡張子を LFS で管理
git lfs track "*.psd"
git lfs track "*.ai"
git lfs track "*.mp4"
git lfs track "*.zip"

# .gitattributes に自動追記される
git add .gitattributes
git commit -m "chore: Git LFS の追跡設定を追加"

*.psd filter=lfs diff=lfs merge=lfs -text
*.ai  filter=lfs diff=lfs merge=lfs -text
*.mp4 filter=lfs diff=lfs merge=lfs -text
*.zip filter=lfs diff=lfs merge=lfs -text

日常の操作

LFS を設定したあとは、普段の add / commit / push はそのままです。
Git が自動的に LFS 対象ファイルを処理してくれます。

# 通常どおり操作するだけ
git add design.psd
git commit -m "feat: トップページのデザインデータを追加"
git push

# LFS で管理されているファイルを確認
git lfs ls-files

# LFS の状態を確認
git lfs status

LFS の導入判断

条件	LFS 導入
100MB を超えるファイルがある	✅ 必要
画像・動画を頻繁に更新する	✅ おすすめ
テキストファイルだけのプロジェクト	❌ 不要
GitHub の容量制限に引っかかりそう	✅ 必要

3.3 タグ管理とセマンティックバージョニング

タグとは？

タグは、特定のコミットに付ける 固定ラベル です。
ブランチと違い、一度付けたら移動しません。
リリースバージョンの管理に使います。

gitGraph
    commit id: "A"
    commit id: "B" tag: "v1.0.0"
    commit id: "C"
    commit id: "D"
    commit id: "E" tag: "v1.1.0"
    commit id: "F"
    commit id: "G" tag: "v2.0.0"

タグの種類

種類	特徴	使いどころ
軽量タグ (lightweight)	コミットへの単なるポインタ	一時的な目印
注釈付きタグ (annotated)	作成者・日時・メッセージ付き	リリース（推奨）

基本操作

# ──── 注釈付きタグの作成（推奨） ────
git tag -a v1.0.0 -m "Release v1.0.0: 初回リリース"

# 過去のコミットにタグを付ける
git tag -a v0.9.0 -m "Beta release" a1b2c3d

# ──── 軽量タグの作成 ────
git tag v1.0.0-beta

# ──── タグの一覧 ────
git tag
git tag -l "v1.*"    # パターンで絞り込み

# ──── タグの詳細を確認 ────
git show v1.0.0

# ──── タグをリモートに送信 ────
git push origin v1.0.0       # 特定のタグを送信
git push origin --tags        # すべてのタグを送信

# ──── タグを削除 ────
git tag -d v1.0.0                  # ローカルから削除
git push origin --delete v1.0.0    # リモートからも削除

セマンティックバージョニング (SemVer)

セマンティックバージョニング は、バージョン番号に意味を持たせるルールです。

MAJOR.MINOR.PATCH
  │      │     └── バグ修正（後方互換あり）
  │      └──────── 機能追加（後方互換あり）
  └─────────────── 破壊的変更（後方互換なし）

flowchart LR
    V1["v1.0.0
初回リリース"]
    V2["v1.0.1
バグ修正"]
    V3["v1.1.0
機能追加"]
    V4["v2.0.0
破壊的変更"]

    V1 -- "PATCH +1" --> V2
    V2 -- "MINOR +1
PATCH → 0" --> V3
    V3 -- "MAJOR +1
MINOR,PATCH → 0" --> V4

    style V1 fill:#E3F2FD,stroke:#1E88E5,color:#0D47A1
    style V2 fill:#E8F5E9,stroke:#43A047,color:#1B5E20
    style V3 fill:#FFF3E0,stroke:#FB8C00,color:#E65100
    style V4 fill:#FFEBEE,stroke:#E53935,color:#B71C1C

バージョンアップ	いつ上げる？	例
PATCH (0.0.x)	バグ修正、誤字修正	`v1.0.0` → `v1.0.1`
MINOR (0.x.0)	新機能追加（後方互換あり）	`v1.0.1` → `v1.1.0`
MAJOR (x.0.0)	破壊的な変更（APIの変更など）	`v1.1.0` → `v2.0.0`

プレリリース版

正式リリース前のバージョンには ハイフン で識別子を付けます。

v1.0.0-alpha.1    # 初期段階
v1.0.0-beta.1     # ベータ版
v1.0.0-rc.1       # リリース候補 (Release Candidate)
v1.0.0            # 正式リリース

GitHub Releases との連携

タグを作成したら、GitHub Releases でリリースノートを作成するのが一般的です。

# タグを push
git push origin v1.0.0

# GitHub CLI でリリースを作成
gh release create v1.0.0 --title "v1.0.0" --notes "初回リリース"

# 自動生成されたリリースノートを使う
gh release create v1.0.0 --generate-notes

まとめ

機能	用途	使用頻度
submodules	他のリポジトリを取り込む	低〜中（必要なとき）
Git LFS	大容量ファイルの管理	プロジェクトによる
タグ	リリースバージョンの管理	リリースごと
SemVer	バージョン番号の命名規則	常に