各界隈で度々見かける git vs svn 戦争ではありますが、
これをもちまして(勝手に)終結宣言といたしましょう。
共存への道
gitもsvnもそれぞれ得手不得手があります。
Gitの弱点
- バージョンが連番じゃないのわかりにくい
- 空ディレクトリを管理できない
- 巨大なファイルの扱いに難儀
- いろんな意味で大変なLFS
- プロジェクトの事情的に .gitattribute の設定が一筋縄でいかないケースも多々
- submoduleが融通利かない
- リポジトリ全体の参照しかできないとか
- 未定義状態を管理できなかったりとか
Subversionの弱点
- mergeが面倒
- まーできないことはないんだけど、Gitほど手軽にはいかない
- それ故に、branch運用も面倒
- それ故に、commitタイミング調整が要求される
では二者択一なんかじゃなくて、両方とも採用してしまいましょう。
互いの弱点を補って適材適所、これに尽きる。
ただし、 git-svn は逆に互いの弱点が足を引っ張り合うあかんやつ。
いざ悪魔合体
ひとまず双方の空ワークディレクトリを混ぜてみた
.git .svn を互いに無視設定
ワイルドカードになっているのは、リポジトリ切り替え技用
svn側の無視設定も同様だが
こちらは .gitignore とか .gitattribute とか無視しちゃいけないのあるので
リネーム用にはアンダースコア挟んどく。
運用形態
基本的には、
- ソースコードの編集はgit側で
- ソースコードの安定性が確認された時点でsvn commit
- リソースの編集からリリースまではsvn側で
といった感じになります。
初期checkout
最初は双方個別にcheckoutして、その後片方の.gitまたは.svnを
もう片方に移送することになりますが、手間と安全性を考慮すると
リポジトリ作りたてから無視設定まで済ませた状態で
バックアップしといて、そのコピーから始めるのがいいでしょう。
ソースコードの扱い
通常、git側のみで作業を進めていくことになります。
ワークフロー的に独立しており、しかも必要最低限の構成で済む。
svn側に足を引っ張られることもないでしょう。
例外的に、svn側の作業で発生した問題の緊急対応として
svn側でソースコードがcommitされることもあり得ます。
そのときはsvn updateをもってgit側へ適用します。
svn external(git submodule)の扱い
通常、svn側でexternal設定を行い、
git側では単純にコピーをcommitしていきます。
(git submodule特有の厄介な問題が一掃できます)
共有箇所に変更が発生したときはsvn側で答え合わせができます。
リソースの扱い
通常、リソースはsvn側のみで作業を進めていくことになります。
(ワークフローにmergeが含まれない限りgitに入れても邪魔なだけ)
単体テスト用のサンプルリソース程度ならgitに入れておくのもあり。
そうすることで、実装から単体テストまではgit側のみで完結できます。
場合によりsvn側でもbranchが必要になることもありますが、
ソースコードほど頻繁にmergeが発生する事態でもなければ
さほど苦にはならないでしょう。
(というか寧ろリソースの自動mergeは危険なわけで結局地道に)
プロダクト的にforkが必要なら、svn側だけ別のリポジトリに切り替えもできます。
Tortoiseシリーズごちゃまぜ問題
WindowsでTortoiseGitとTortoiseSVNが両方インストールされているとき
Explorerでの表示が混ざってよくわからなくなるので
.gitまたは.svnのうち使わない方の名前を変えておきます。
運用実績
ない。
ついさっき思いついたんで。
目下、実験中。