1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

バージョン管理ベストプラクティス

Posted at

警告
この記事は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): バグ修正

タグ作成のワークフロー

タグを打つタイミング

  1. mainにマージ後
  2. テスト完了後
  3. リリース準備完了時

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 ✅

  1. プロダクション = タグ固定

    • 安定性と再現性を保証
  2. 明確なバージョニング

    • セマンティックバージョニングを遵守
    • 破壊的変更は必ずメジャーバージョンアップ
  3. ドキュメント化

    • CHANGELOG.mdの維持
    • 互換性マトリックスの更新
  4. 段階的移行

    • 開発 → ステージング → プロダクション

DON'T ❌

  1. mainブランチの直接更新

    • 他プロジェクトへの影響が予測不能
  2. タグなしでのプロダクション利用

    • 再現性が保証されない
  3. テストなしの更新

    • 必ず統合テストを実行
  4. ドキュメントなしの破壊的変更

    • 移行ガイドを必ず提供

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. まとめ

重要な原則

  1. タグ = 不変のマイルストーン
  2. ブランチ = 進行中の作業
  3. プロダクション = 常にタグ固定
  4. 開発環境 = ブランチ追跡OK

推奨ワークフロー

開発 → feature/xxx
 ↓
レビュー → develop
 ↓
テスト → release/vX.Y
 ↓
リリース → main + タグ (vX.Y.Z)
 ↓
利用 → 各プロジェクトで選択

この戦略により、複数プロジェクト間でサブモジュールを安全かつ効率的に共有できます。

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?