#はじめに
これは、SVNでソース管理をしている現場で、ローカル環境だけGitを導入した時の経緯を記したものです。
自ら現場に導入したSVNに、何の課題も感じていなかった私が、ある日突然Gitの良さに気づきました。
ここでは、その時の状況や、Gitに移行するきっかけなんかを書いています。
具体的な移行手順も書こうかと思いましたが、それは別記事にする事にします。
#導入前夜
弊社は老舗の中小企業。何十年も前から使い続けているAS/400がメインの社内システムという状況です。
情報システム部にもベテランが多く、SVNどころかVCS自体使った事ない、というか存在すら知らないという感じ。
数年前、部分的にjavaで作ったシステムを導入し、同時にVCSでの管理を提案しましたが、VCSヴァージンにいきなりGitは理解が追い付かない。という事で、SVNを導入する事にしたのでした。
当時は私もGitについての知識が浅く、「Gitだと何かいい事あるの?」に対して「ブランチの運用がやりやすいらしいよ」くらいしか答えられず、SVN導入後も何も問題は感じていませんでした。
「そもそもブランチなんか滅多に作らないし」、「ローカルリポジトリって何がいいんだろう?もしハードディスクぶっ壊れたらソース消えちゃうし、リモートに直接コミットしたいよ」そんな感じでSVNでの運用に満足していました。
#予兆
SVN自体には問題を感じていませんでしたが、ローカル環境には1つだけ課題がありました。
複数の案件を同時に対応している時の運用です。
例えば、大き目の改修案件をやっている途中で、急きょバグ修正の必要が出てきたりする。さらに緊急で軽い変更を依頼されたりする。複数の案件がワークスペースに入り乱れるというケースは、意外と多いものです。
コミット時に「あ、これは別の案件のやつだ」とコミット対象から外したりするのはまだいいとして、最悪なのは1つのソースに色んな案件の修正が入り乱れてた時。
一旦別案件の修正は消しておいてコミット、その後元に戻したり。あぁ面倒くさい。
この状況はしかし、SVNの運用としては当たり前だという思いから、普通に受け入れていたのでした。
このように、SVNの運用には課題を感じながらも、「そういうものだ」みたいな感じで運用を続けていました。
これと同時に、Gitの方も少しづつ勉強を続けていました。
「あぁ、トピックブランチなんての作るんだ。ふ～ん」とか思ったり、コミットとかプッシュとかを実際に試してみたり。
相変わらず、導入してみようという気にはなっていませんでしたけど。
#神託の夜
ある夜、自宅で突然ひらめきます。
「複数の案件を同時に対応してるときって、Gitでトピックブランチ運用すれば楽なんじゃね?」
Gitの事を考えて、うずうずしながら眠りにつき、翌朝出社してすぐにGitを試してみます。
ブランチを作り、コミット。またコミット…、マージ…、スタッシュ…。
やっぱり!これなら、複数案件をブランチ切り替えながら対応できるぞ!
すぐに環境を整え、リモートはSVNのまま、ローカルはGitという開発環境を運用していく事になったのでした。
※最初に宣言したように、ローカル環境のGitへの移行は、別記事で手順とかをまとめようと思います
#まとめ
Gitの良さとは何か?
それは、「案件(トピック)ごとに独立したワークスペースで作業できること」だと思います。
このポイントは、わかりにくいというか、実感しにくいものみたいですね。
私のように、Gitについて学んでみて、一通り使ってみた経験があっても、すぐには気づけませんでした。
「Gitって何がそんなにいいの?」と思った人は、「ツールとしてGitは何ができるか」よりも、Gitの文化を重点的に学んだ方が良いと思います。
git-flowとかをじっくり見てみて、SVNを使ったフローとどこが違うのか、それぞれどこに良さがあるのか、考えてみるといいでしょう。
Gitを使うという事は、単なるツールの導入に留まらず、開発スタイルをアップデートする事であると考えるべきなんだと思います。