私の職場ではSVNからGitに移行して間もなく2年になります。移行の推進に関わった私の視点から、Gitにして良かったと思う点を綴っていきたいと思います。
少々Gitの用語を使ってますので、Gitとは？を一通り学び、実際に導入しようか考え始めた方に向けて書いています。
良かったと思う点
コミットが気軽に出来るようになった
Gitでコミットとは、ローカルリポジトリに変更内容を記録するだけ。リモートリポジトリにPushしない限り皆に影響を与えません。
そのため、ローカルリポジトリで検証をして問題無ければリモートリポジトリに上げるという手法が取れますので、コミットの心理的なハードルが下がります。
Branch作成のハードルが下がった
Gitでは非常に容易にbranch作成が可能になっています。
SVNのようにbranchesを選んで・・・といったStepが不要となっていますので、誰でも簡単に作れちゃいます。
もちろん、ローカルリポジトリにこっそりプライベートのbranchを作ってテストなんてことも容易です。リモートリポジトリにPushしない限り、皆には見えません
私の職場ではSVNを使っていた頃、Externalsを使っていたのでbranch作成が難しく、SVNの管理担当に依頼して作っていたという背景がありました。
Gitに変える際、このExternalsを解消して運用に落とし込んだということがありました。
確かにGitにはSubmoduleやSubtreeといった似たような機能がありますが、これらはリポジトリの管理を難しくするので、まずは無くすことは出来ないかを検討するのが賢明です。
コードレビューの必須化が実現できた
Gitの基本Stepとして、まずbranchを作って自分の変更を入れます。それをリモートリポジトリにPushしたら、
master branch(SVNで言うtrunk)にマージしても良いか？というリクエストを立てます。
ここでコードレビューし、OKであればマージということが実現できます。GitHubではプルリクエスト、GitLabではマージリクエストといいます。
master branchへのPushを直接できないように制限をかけられます。これによってコードレビューを必須化することが出来ました。
レビューフィードバックへの心理的負担が軽減された
コードレビューした結果、修正があったとしましょう。
私の職場ではSVNだとpatch運用でレビューしていたので、そういった場合には修正patchを作り直して上げ直すと言った手間があります。
しかもpatch間の差分は見づらい・・・
これがGitだと、修正をもういちどリモートリポジトリにPushすればよいので、非常に楽ちん。さらにレビュワーは修正間の差分も見れます。
これにより、気を遣わないで些細なコメント間違いでも指摘しやすい環境になりました。
Branch間のマージが容易になった
年度毎にコードを分けているような環境だと、最新で見つかったバグ、もしくは過去のコードにバグを見つけた場合、年度毎にマージする必要が出てきます。
SVNだとこれが結構手間でした。Gitだと実はこれがブラウザ上で数クリックでできちゃいます。
レビューが終わってマージが完了した後、Cherry-pickという機能を使うと、その変更を他のどのbranchにマージするかを指定するだけで、反映ができます。
あまりに簡単なので、何なら気づいたら修正を入れた本人じゃなくても出来てしまうという素晴らしさ。これが導入後非常に好評でした。
悪かったと思う点
教育コスト
便利な機能が増えた分、Gitは概念が複雑です。
そのため、最初は色々と疑問が出ますので、答えられる人を立てて運用を開始する必要があります。
私の場合は、何名かチームの中心になりそうな人を集めてGitの外部講習を受け、チーム毎に窓口になるという方法を取りました。
とはいえ、大変なのは最初だけで、数カ月もすれば皆慣れて質問もほとんど出なくなりました。
リバートの考え方(限定的かも）
Gitにはリビジョンという概念が無いので、戻すという考え方は難しいところがあります。
そのため、実動ベースでどの変更から不具合が起こったか特定する場合などに、変更を１つ１つリバートしたりします。
Gitではそういった手法が取りづらいデメリットがあります。
Gitはマージする時にSquashマージという手法を取るのが一般的で、これはbranchからマージする時にログを1つにまとめる方法です。
ログが1つにまとまるということは、コミットがひとかたまりになりますので、master側の変更点は見やすくなるものの、
SVNでやってた変更単位でリビジョンを戻して・・・といった手法は取れなくなります。branchも用が済めば消しちゃいますしね。
この辺りはSVNよりコミットの粒度が大きくなり、手間がかかる点ではありますが、
そもそもあまりこういったことに直面することは無いので、それほど大きいデメリットになっていないです。
Branch増えすぎ
branchが手軽に作れる分、増えます。かなり増えます。
増えるとCloneやPullの時間が遅くなるといった、パフォーマンスへの影響を与えます。
また、branch一覧に大量にbranchが出てくるので、目的のbranchを見つけにくくなりますので、定期的に消す必要があります。
SVNだとbranchを消すということはあまり考えられないですよね。
Gitではレビューが終わってマージすると同時にbranchを消すという操作が出来ます。
これを徹底しておかないと、増えまくりますので、気を付けて運用しましょう。
周りの説得の難しさ
Gitはチーム全員の協力あってこそ運用が成り立つものですので、実はここが一番難しいところかもしれません。
上記のメリットを説明しても、やっぱりデメリットを見てしまう方は居て。
最終的には
「Gitはトレンドなので、ソフト屋として今後覚えておいて損は無い！転職で有利に働くかもよ！」
という論法が一番効きましたね（笑）
それにはやはり、しっかりと皆に説明する場は必要です。やるからには皆が納得して導入したいものです。
結論として
導入には色々と障害はあったものの、悪い点を鑑みても余るぐらい利点の方が多かったです。
まだまだSVNを利用している会社は多いと思います。今Git移行に悩んでいる方の後押しになれば幸いです。