Git下調べ〜SVNユーザー視点から〜

ふと使ってみようかなと思ったので調べてみましたが、私はSVNユーザーですが、だいたいこんなあたりが運用面で違いそうだなーという備忘録。調べたばかりでものすごく理解が曖昧なのはご容赦。

見かけ上のtrunk/tag/branchフォルダはなくなる

各リビジョン（差分履歴）はすべてGitのシステムファイル内に隠蔽されて、"tag"や"branch"などのフォルダは使わないみたいです。SVNで言うtrunk（メインライン）の名前は規定でmasterブランチ。全てのリビジョンはmasterのどこかの時点から派生したbranchのみになり、masterからガンガンbranch切ってガンガン派生元のラインへとmergeしていきます。「実際のところtrunkしかない！」という感じですね。tagは文字通り特定リビジョンに与える検索タグになる様子。

良さそうなところ

小まめなbranchとmergeができます。あえてフォルダを用意しない限り、分岐状態は”branchフォルダ”のようには見た目に出力されないので、分かりにくい反面、作業者個々人が小まめにブランチ切ってもそんなにウザくはならなさそうです。むしろチケット単位などかなり細かい作業単位でbranchを切って、元に合流するときのmerge衝突リスクを避ける事が推奨されるんじゃないかなーと思います。作業しやすそうな気がします。これは「バージョン管理についてtrunk/tag/branchの伝統を守れ」というファジーなお作法より、もっと動的さと積極性と厳格さを強制する仕様のように感じます。

しんどそうなところ

マルチラインが結構難しそうです。例えばメジャーバージョンの更新や基底APIの世代交代などでマルチラインで平行開発をする時は、ちょっとやりにくいかもしれません。そもそも一つのmasterに細かい更新をmergeしていく想定のようで、一つのリポジトリ内に、先々統合する可能性の低いマルチラインのブランチを平行して開発するのは、出来なくはないでしょうけど、それなりの手続きと慎重さが要求されそうです。SVNなどは複数プロジェクトの作業履歴でも一箇所に置いておける想定になっていますが、Gitはどちらかと言うと、もっと細かいプロジェクトごとの作業履歴をまとめておく印象を受けます。そのへんあって一応、SourceForgeでもSVNはリポジトリ一個で、Gitは複数のリポジトリを登録できるようになっています。とは言え「よく似てるけど細部はだいぶ違う」ような二つのGitリポジトリ間の移植は、そんなにサクッとはいかなさそうです（もともと容易な事ではありませんけれど！）。それと現在作業中のリビジョンが、どのようにブランチ派生しているのかはユーザー側が自覚しておく必要があります。

イケイケな多層

trunk/tag/branchも実際の運用では冗長だったり厳密には守れなくなる事が多いので、だったらいっそ、なるほど割り切ったなぁという感じです。その都合で、サーバー側データをローカル側に分身させてサーバー⇔ローカル間で同期をとりつつ、ローカル側データに変更をコミットして、ローカルに溜まったコミット履歴をサーバー側にマージするという多層構造がとても理系っぽい。

というわけでどうにか使い方を考えてトライしてみようと思います。