概要
バージョン管理は、ソースコードやドキュメントの変更履歴を安全に記録・共有し、チーム開発の衝突を最小化するための基盤です。本ページでは Git と Subversion(SVN) を中心に、概念 → 導入 → 実務フロー → 応用まで一気通貫で整理します。
Git の特徴
- 分散型(各クライアントが完全な履歴を保持)
- ローカルでのコミット・ブランチ操作が高速
- ブランチ作成・マージが軽量で主流の開発フローに適合
- Staging(インデックス)で部分コミットが柔軟
- 大規模OSSでの実績・ツール/ホスティングが豊富(GitHub/GitLabなど)
- Git LFSにより大きなバイナリ管理に対応可能
- Rebase/Cherry-pick 等の高度な履歴整形が可能(運用ルールは要徹底)
SVN の特徴
- 中央集権型(中央リポジトリが唯一の真実)
- 単純な直線的履歴を作りやすい
- ロック型運用(大きなバイナリ/ドキュメント)との相性が良い
- リポジトリの容量管理やアクセス制御がシンプル
- ネットワーク必須の操作が多いが、権限管理や監査の一元化がしやすい
- 古参の大企業/オンプレ環境での導入実績が多い
基本
- リポジトリ(履歴の器)とワーキングコピー(手元の作業領域)
- 差分(変更点)を論理単位で記録する コミット
- 機能や検証を並行に進める ブランチ と安全な取り込み マージ
- 衝突(コンフリクト)の解消、レビュー/テスト/CI/CDとの連携
最初は「小さくコミット」「こまめにプッシュ/コミットメッセージに要約」を徹底すると、履歴が財産になります。
基礎
必須コマンドの地図(Git)
init / clone / status / add / commit / branch / checkout / switch / merge / rebase / log / push / pull
必須コマンドの地図(SVN)
checkout / status / add / commit / update / diff / log / copy / switch / merge
履歴の読み方
コミットメッセージは「目的 + 要約 + 影響範囲」。例:feat(login): 2FAコード入力を追加(/auth/** に影響)
導入
Git 初期化
git init
git config user.name "Your Name"
git config user.email you@example.com
echo -e "node_modules/\n.env\n.DS_Store" > .gitignore
git add .
git commit -m "Initial commit"
SVN 利用開始
svn checkout https://example.com/svn/repo/trunk myproject
cd myproject
svn status
svn add .
svn commit -m "Initial import"
開発現場
おすすめ基本フロー(Git:Trunk-Based or GitHub Flow)
mainは常にデプロイ可能に保つ- 小さな機能を
feature/*で短期開発 → PR → 自動テスト → レビュー - Releaseタグでロールバックも簡単に
SVN 運用のコツ
/trunk /branches /tagsの構造を守る- ブランチは短命、マージポリシーは文書化
- ドキュメント/バイナリはロックでの運用を検討
レビューとCI/CD
PR/MRにテスト・Lint・ビルドを自動実行。レビュー観点をチェックリスト化し、属人化を避ける。
最新情報
/data/versioncontrol_news.json を配置するとここに表示されます。
{
"items": [
{"date": "2025-08-01", "title": "Git vX.Y リリース", "url": "https://git-scm.com/"},
{"date": "2025-07-20", "title": "SVN セキュリティアップデート", "url": "https://subversion.apache.org/"}
]
}
応用
- モノレポ vs マルチレポ/サブモジュールとサブツリー
- Git LFSでアセットを分離、CIキャッシュで高速化
- Conventional Commits / Semantic Release による自動バージョニング
- Hook(pre-commit / pre-push)で品質ゲートを前倒し
発展
- 権限と監査:保護ブランチ/必須レビュー/署名付きタグ
- 大規模分散:フォーク戦略、CODEOWNERS、レビュー負債の可視化
- 移行:SVN → Git の段階移行(read-only ミラー→運用切替)
比較(Git vs SVN)
| 観点 | Git | Subversion(SVN) |
|---|---|---|
| 方式 | 分散型(DVCS) | 中央集権型(CVCS) |
| 速度 | ローカル操作が高速 | ネットワーク依存の操作が多い |
| ブランチ | 軽量で大量運用に適 | 重め、ベストプラクティスはブランチ数控えめ |
| 履歴 | 非線形(グラフ)に強い | 線形で読みやすい |
| 大容量ファイル | Git LFSで対応 | ロックで衝突回避しやすい |
| 学習コスト | 概念が多め(慣れると強力) | シンプルで導入しやすい |
| ホスティング | GitHub/GitLab/Bitbucket 等が豊富 | オンプレSVNサーバ運用が一般的 |
| 向き | アプリ/OSS/分散開発 | 文書系/バイナリ中心/厳格な中央管理 |
例(コマンド/設定)
【Git】最小フロー:初期化〜コミット〜ブランチ〜プッシュ
# 初期化 & 最初のコミット
git init
git add .
git commit -m "Initial commit"
# ブランチを切って作業
git checkout -b feature/login
# 変更 ...
git add path/to/file
git commit -m "Add login form"
# リモート登録 & プッシュ
git remote add origin https://example.com/your/repo.git
git push -u origin feature/login
# PR/MRを作成してレビューへ(ホスティング側UI)
【Git】rebase で履歴を整える(注意:共有前に)
# メインブランチを最新化してから、作業ブランチを付け替える
git checkout main
git pull origin main
git checkout feature/login
git rebase main
# コンフリクト解消 → add → rebase --continue を繰り返し
git add .
git rebase --continue
# push -f は危険。共有前のブランチのみ原則許可(チームルール厳守)
git push --force-with-lease
【SVN】チェックアウト〜コミット〜ブランチ作成
# チェックアウト
svn checkout https://example.com/svn/repo/trunk project
cd project
# 変更を確認
svn status
svn diff
# 追加 & コミット
svn add src/new_file.php
svn commit -m "Add new PHP file"
# ブランチ(/branches/login を切る)
svn copy https://example.com/svn/repo/trunk \
https://example.com/svn/repo/branches/login \
-m "Create login branch"
# 作業コピーをブランチへ切替
svn switch https://example.com/svn/repo/branches/login
共通:.gitignore(Git)/ svn:ignore(SVN)の指定
# .gitignore 例
node_modules/
dist/
*.log
.env
# SVN の ignore(プロパティ)設定例
# カレントディレクトリに対して node_modules と dist を無視
svn propset svn:ignore "node_modules
dist" .
svn propget svn:ignore .
おすすめツール
世界最大級のGitホスティング。PR・Actions・Package 等が充実。
セルフホスト/クラウドの両対応。CI/CDと統合運用が強い。
Atlassian連携(Jira/Confluence)と相性良。
無料GUIクライアント(Git/ Mercurial)。
軽快なGitクライアント。視覚化がわかりやすい。
Windows Explorer統合の定番SVNクライアント。
関連リンク
より具体的に(FAQ)
Git の rebase と merge、どちらを使う?
公開前の作業ブランチは rebase で履歴を整え、共有/公開された履歴は merge を基本にすると事故が減ります(要チームルール)。
SVN で大きなファイルを安全に?
ロック運用 + ファイル分割 + バイナリの版管理ポリシー(頻繁に更新される巨大バイナリは外部ストレージ連携も検討)。