SVNでGit Flowを実現する：レガシー環境で戦うエンジニアたちへ

1. はじめに

ソフトウェア開発の現場では、Gitが主流となり、Git Flowのようなブランチ戦略が一般的になっています。しかし、現実にはレガシーな事情により、Subversion（以下SVN）を使い続けざるを得ない企業やチームも少なくありません。

本記事では、そんな環境でGit Flowの恩恵を少しでも享受すべく、「SVNでGit Flowを模倣する方法」について、戦略的かつ実践的に解説します。辛さを乗り越える工夫を詰め込みましたので、レガシー環境で奮闘するエンジニアの皆さんに届けたい内容です。

2. SVNとGitの違いと背景

2.1 中央集権 vs 分散管理

SVN：中央リポジトリを中心とした集中型バージョン管理。ネットワーク接続が前提。
Git：ローカルに全履歴を保持する分散型。ブランチ操作も高速でオフラインでも作業可能。

2.2 ブランチのコスト

SVN：ブランチはディレクトリコピー。構造上の自由度はあるが、マージ時の管理は煩雑。
Git：軽量ブランチのため、機能開発ごとに作っても負荷は少なく、フローが自然に回せる。

2.3 なぜまだSVNを使うのか？

既存資産（ビルドシステム、リリースフロー）
社内の開発文化やルール
移行コストの高さ（トレーニング、CI/CD環境の再構築）

これらの理由から、"やむを得ず" という現場も多いのです。

3. SVNでGit Flowを再現するには？

3.1 Git Flowの構造を復習

Git Flowは以下のようなブランチ構成です。

main：本番に出ている安定版
develop：開発の統合ブランチ
feature/*：新機能開発
release/*：リリース準備
hotfix/*：本番緊急修正

これをSVNで再現するには、以下のディレクトリ構造を採用します。

/trunk
/branches
    /develop
    /feature/xxx
    /release/xxx
    /hotfix/xxx
/tags

3.2 SVNのブランチ戦略とルール

/trunk：安定版。本番環境と連動。
/branches/develop：全ての機能ブランチが統合される中継点。
/branches/feature/：1機能ごとに作成。開発が終わったらdevelopへマージ。
/branches/release/：リリース用の最終確認。trunkへマージ後タグを切る。
/branches/hotfix/：trunk直下から分岐。リリース後のバグ修正用。

3.3 命名規則と運用例

feature/add-login-api
release/v1.2.0
hotfix/fix-header-style

命名はルール化して、レビューやCIでブランチ種別ごとに処理を分けられると理想です。

4. SVNでの実践操作手順

4.1 ブランチ作成

svn copy ^/trunk ^/branches/develop -m "初期developブランチ作成"
svn copy ^/branches/develop ^/branches/feature/add-login-api -m "ログインAPI追加用ブランチ"

4.2 開発→統合の流れ

# 作業をfeatureブランチで実施

# 開発が終わったらdevelopへマージ
svn switch ^/branches/develop
svn merge ^/branches/feature/add-login-api
svn commit -m "feature/add-login-apiをdevelopへマージ"

4.3 リリースブランチとタグ付け

svn copy ^/branches/develop ^/branches/release/v1.2.0 -m "v1.2.0リリース準備ブランチ作成"

# テスト完了後、本番反映
svn switch ^/trunk
svn merge ^/branches/release/v1.2.0
svn commit -m "v1.2.0をtrunkへマージ"

# タグを切る
svn copy ^/trunk ^/tags/v1.2.0 -m "v1.2.0タグ付け"

4.4 ホットフィックス運用

svn copy ^/trunk ^/branches/hotfix/fix-header-style -m "ヘッダー修正ホットフィックスブランチ"

# 修正後マージ
svn switch ^/trunk
svn merge ^/branches/hotfix/fix-header-style
svn commit -m "ヘッダー修正を本番へ反映"

svn switch ^/branches/develop
svn merge ^/branches/hotfix/fix-header-style
svn commit -m "ヘッダー修正をdevelopへも反映"

5. 実運用のポイントと課題

5.1 開発体験のギャップ

Gitではローカルで気軽に作業・巻き戻しが可能ですが、SVNは中央集権的な構造ゆえに「試行錯誤」がやりづらいです。ローカルで差分を多く管理するTortoiseSVNなどの補助ツールは活用すべきでしょう。

5.2 マージミスのリスク

手動マージが多くなるため、コミュニケーションエラーが生まれやすくなります。マージの責任者やルールを事前に明確化しておく必要があります。

5.3 ブランチ掃除を忘れずに

SVNは軽量なブランチ管理ができない分、ブランチの放置が技術的負債になります。定期的な整理やリリース後即削除の徹底が重要です。

svn delete ^/branches/feature/add-login-api -m "不要ブランチの削除"

6. レガシー環境で生きるということ

Gitに比べて不便さは否めないSVN。しかし、現実のプロダクト開発では「理想よりも運用可能な仕組み」が重要です。SVNを前提としながらも、チーム全体で意識を統一し、運用ルールを整備することで、効率的な開発は可能です。

7. まとめ

SVNでもGit Flow的な運用は可能
ディレクトリ構造と命名規則で擬似ブランチ運用
マージルールの明文化と定期的なクリーンアップが鍵

レガシーに縛られても、知恵と工夫でモダンな開発フローに近づくことはできるのです。

8. 参考文献・リンク

リンク

TechCraft – エンジニアのためのスキルアップメモ

エンジニアのスキルアップを少しでも加速する技術ブログ

Gitに頼れない現場で、SVNでGit Flowを再現する方法