警告
この記事はAIに書かせており、記載の内容は人間が検証してません
1. タグ vs ブランチ管理
基本概念
特性 | タグ | ブランチ |
---|---|---|
不変性 | ✅ 不変(特定のコミットを指す) | ❌ 可変(コミットが追加される) |
用途 | リリースバージョンの記録 | 開発作業の進行 |
安定性 | 高い(テスト済みのポイント) | 変動する |
推奨環境 | プロダクション | 開発・ステージング |
サブモジュールの仕組み
# サブモジュールは特定のコミットハッシュを記録
$ git submodule status
a1b2c3d submodules/auth-module (v1.2.3)
↑ 実際にはコミットハッシュを保存
2. バージョニング戦略
セマンティックバージョニング
v{MAJOR}.{MINOR}.{PATCH}
例: v1.2.3
- MAJOR (1): 破壊的変更
- MINOR (2): 後方互換性のある機能追加
- PATCH (3): バグ修正
タグ作成のワークフロー
タグを打つタイミング
- mainにマージ後
- テスト完了後
- リリース準備完了時
3. ブランチ戦略
ブランチ命名規則
# 機能開発
feature/issue-{番号}
feature/{機能名}
# バグ修正
fix/issue-{番号}
hotfix/{緊急修正名}
# リリース管理
release/v{major}.{minor}
support/v{major}.x
# 実験的機能
experimental/{機能名}
推奨フロー
4. サブモジュール管理
プロダクション環境:タグ固定
# 安定版タグを指定
cd submodules/auth-module
git checkout v1.2.3
cd ../..
git add submodules/auth-module
git commit -m "Pin auth-module to v1.2.3"
開発環境:ブランチ追跡
# .gitmodules でブランチ指定
[submodule "submodules/experimental"]
path = submodules/experimental
url = https://github.com/org/experimental.git
branch = develop # 最新の開発版を追跡
# 更新
git submodule update --remote --merge
環境別バージョン管理
// submodule-versions.json
{
"production": {
"auth-module": "v1.2.3",
"api-client": "v2.1.0"
},
"staging": {
"auth-module": "v1.3.0-beta",
"api-client": "v2.1.0"
},
"development": {
"auth-module": "develop",
"api-client": "feature/new-api"
}
}
5. 複数プロジェクトでの共有
問題の概要
- プロジェクトA: v1.2.0を使用
- プロジェクトB: v1.3.0を使用
- プロジェクトC: mainブランチの最新を追跡
解決策:タグによる独立管理
# 各プロジェクトで異なるバージョンを選択
# プロジェクトA
cd project-a/submodules/shared
git checkout v1.2.0
# プロジェクトB
cd project-b/submodules/shared
git checkout v1.3.0
# プロジェクトC(開発用)
cd project-c/submodules/shared
git checkout develop
バージョン互換性マトリックス
親プロジェクト | auth-module | api-client | ui-lib | 備考 |
---|---|---|---|---|
ProjectA v2.0 | v1.2.3 | v2.1.0 | v3.0.0 | 現行プロダクション |
ProjectB v1.5 | v1.1.0 | v1.8.2 | v2.5.1 | レガシー |
ProjectC dev | develop | develop | v3.1.0-rc | 開発中 |
6. 安全な更新プロセス
更新前の確認
#!/bin/bash
# scripts/safe-update.sh
SUBMODULE=$1
TARGET_VERSION=$2
# 現在のバージョンを記録
cd "submodules/$SUBMODULE"
CURRENT=$(git describe --tags --always)
# 変更内容を確認
git fetch --tags
git log --oneline "$CURRENT..$TARGET_VERSION"
# 破壊的変更のチェック
if git diff "$CURRENT..$TARGET_VERSION" | grep -q "BREAKING"; then
echo "⚠️ 破壊的変更が含まれています"
read -p "続行しますか? (y/n): " -n 1 -r
if [[ ! $REPLY =~ ^[Yy]$ ]]; then
exit 1
fi
fi
# 更新実行
git checkout "$TARGET_VERSION"
cd ../..
npm test # テスト実行
if [ $? -eq 0 ]; then
git add "submodules/$SUBMODULE"
git commit -m "Update $SUBMODULE: $CURRENT -> $TARGET_VERSION"
else
echo "テスト失敗。ロールバック中..."
cd "submodules/$SUBMODULE"
git checkout "$CURRENT"
fi
7. 自動化
GitHub Actions でのタグ作成
name: Auto Tag on Release
on:
push:
branches: [main]
jobs:
tag:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Get version
id: version
run: |
VERSION=$(node -p "require('./package.json').version")
echo "version=v${VERSION}" >> $GITHUB_OUTPUT
- name: Create tag
run: |
git tag -a "${{ steps.version.outputs.version }}" \
-m "Release ${{ steps.version.outputs.version }}"
git push origin "${{ steps.version.outputs.version }}"
定期的な依存関係チェック
name: Check Dependencies
on:
schedule:
- cron: '0 0 * * 1' # 毎週月曜
jobs:
check:
runs-on: ubuntu-latest
steps:
- name: Check outdated submodules
run: |
git submodule foreach '
echo "Checking $name..."
git fetch --tags
CURRENT=$(git describe --tags)
LATEST=$(git describe --tags --abbrev=0 origin/main)
if [ "$CURRENT" != "$LATEST" ]; then
echo "Update available: $CURRENT -> $LATEST"
fi
'
8. ベストプラクティス
DO ✅
-
プロダクション = タグ固定
- 安定性と再現性を保証
-
明確なバージョニング
- セマンティックバージョニングを遵守
- 破壊的変更は必ずメジャーバージョンアップ
-
ドキュメント化
- CHANGELOG.mdの維持
- 互換性マトリックスの更新
-
段階的移行
- 開発 → ステージング → プロダクション
DON'T ❌
-
mainブランチの直接更新
- 他プロジェクトへの影響が予測不能
-
タグなしでのプロダクション利用
- 再現性が保証されない
-
テストなしの更新
- 必ず統合テストを実行
-
ドキュメントなしの破壊的変更
- 移行ガイドを必ず提供
9. トラブルシューティング
よくある問題と対処
Q: タグを間違えて作成した
# ローカルで削除
git tag -d v1.2.3
# リモートから削除
git push origin --delete v1.2.3
# 正しいタグを作成
git tag -a v1.2.3 -m "..." <correct-commit>
git push origin v1.2.3
Q: サブモジュールが更新されない
# 強制的に最新を取得
git submodule update --init --recursive --remote
# または特定のサブモジュール
git submodule update --remote submodules/module-name
Q: コンフリクトが発生
# サブモジュール内で解決
cd submodules/module-name
git status # 状態確認
git checkout --theirs . # またはours
cd ../..
git add submodules/module-name
10. まとめ
重要な原則
- タグ = 不変のマイルストーン
- ブランチ = 進行中の作業
- プロダクション = 常にタグ固定
- 開発環境 = ブランチ追跡OK
推奨ワークフロー
開発 → feature/xxx
↓
レビュー → develop
↓
テスト → release/vX.Y
↓
リリース → main + タグ (vX.Y.Z)
↓
利用 → 各プロジェクトで選択
この戦略により、複数プロジェクト間でサブモジュールを安全かつ効率的に共有できます。