現場におけるSubversionからGitへの移行について
今回は私が実際に社内でSubversionからGitへ移行したときの話をまとめてみました。
うちの社内でもGitに移行したい！と考えている人に、少しでも参考になればと思います。
Gitはもうすっかり世間に浸透してきており、
業界にいる人では利用していない人はいないだろうというくらい多くなって来ました。
しかし、残念なことに未だ日本のIT企業ではSubversionが主流です。
これはGit登場当時、クロスプラットフォームにおける日本語の扱いに問題があったこと、
またWindowsでの動作に不具合が多かったことなどの理由が挙げられます。
かくいう私も、当時はGitよりもWindows対応のしっかりしていたMercurialを推していました。
しかし、Gitもver.1.7.10以降は日本語問題を解決したのと、
Windowsへの対応も大分しっかりしてきたこともあり、
今ではGitを社内SCMとして採用するには必要十分な条件を満たしています。
とはいえ、日本語扱いが怪しいといった当時の印象を持ったままの人が未だにいたり、「Subversionでいいじゃん。敢えてGitに移行したところで教育コストが掛かるしな・・・」などという理由から、移行したがる人がとにかくいません。
こういう人たちに何といえば納得してもらえるのか・・・と考えると、
会社の社風や上司・メンバーの性格にもよるので、確実な手段というものはもちろんありません。
ただ、何もやらなければ結局移行は出来ないので、まずはGitに移行しようという流れをつくることが大事でしょう。
それにはどうすればいいのかということと、
必ず向こうからぶつけられるであろう疑問・質問に対する回答をまとめてみました。
01. Git移行への流れを作るにはまずどこかのプロジェクトでやってみる
プロジェクト単位は比較的小さな単位なので、
その単位であれば許可をしてくれる上司は多いです。
なので、まずはプロジェクトごとにSubversionからGitへの移行を試していけばいいと思います。
更に言えば、「並行開発の多い既存プロジェクト」が一番望ましいです。
その理由については、それがGitの利点を一番生かせるため、成功例として印象付けやすいからです。
02. 「導入してもいいけど教育コスト掛かるんじゃないの？」という質問に対して
社員だけならともかく、パートナーさんなど社外の人をプロジェクトに参入させた場合を考慮し始めると、
やはりコストが掛かるだろうと考える人が多いようです。
先述のとおり、日本のIT業界では未だSubversionが主流なので、Gitを使えない人ばかりだろうという前提で考えている人は多いです。
しかし、Subversionであってもプロジェクトごとにtrunk、branches、tagsの扱い方は違うわけで、結局プロジェクト参入当初の教育という意味でのコストは掛かります。
更に言えば、私はSubversionを知らないという人すらも何人か見て来ました。
なので結局のところ、外部からパートナーさんを呼んだ時であっても、
社員を新しいプロジェクトに参入させたときであっても、
初回の教育コストは掛かりますし、余程アクロバティックなソース管理をしないのであればGitにしたところでそこに差はありません。
Gitであっても、基本はSubversionと同じく、trunk、branches、tagsといったソース管理の考え方自体は踏襲しているので、大きな違いはないと言えます。
03. 「移行することで何が便利になるの？」という質問に対して
当然、それがないことには移行する意味もないわけですから、この点に関する説明も求められると思います。
実は、これが一番難しいです。
何から説明すればいいのかわからなくなりますし、
説明したところで利点に結びつくかどうかは「やってみなければ」みたいな話になってしまう人も多いです。
いわゆる「集中型管理」と「分散型管理」という違いを上げた所で、
「( ´_ゝ｀)ﾌｰﾝ」で終わってしまうのが関の山ですし、
「ローカルでコミットできる」という説明をしたところでも
「一見便利に聞こえるけど、別にできなくてもよくないか？」と言われることもよくあります。
これは結局のところ、Gitを採用しようと思っている人自身も
Gitを満足に複数人開発で利用したことが無いから上手く説明できないことに起因していると言えます。
じゃあ、利点って何なのか。
余計なことはいわずにシンプルに言うと
「ブランチ管理が高速で簡単」
これに尽きます。
そしてこれは、保守と並行して追加開発を複数行う案件など
並行開発が多いプロジェクトほどこの利点が生かされます。
とはいえ、これだけではまだ理解はできないでしょう。
「何がどう簡単なのか」
これを説明するには、実際にEclipseのEGitなどでブランチ切り替えを実演すればわかるかと思います。
ワークスペースを切り替えたり、Eclipseを終了することなく、
ブランチ切り替えを実行することで、数秒〜数十秒ほどで別のソースにガラッと切り替わる。
これは目で見せてあげるのが一番いいと思います。
実際、私もこれを実演したら「これは凄く便利だね」と納得してくれた人が多かったです。
これをSubversionでやろうとすると、
trunk、branchesごとにワークスペースを予め作成しておき、
一回Eclipseを終了させてワークスペースを切り替えて・・・などになるかと思います。
一見これでもいいように聞こえますが、
ソース量が膨大なプロジェクトほどSubversionはチェックアウトに時間が掛かり、
ブランチが増えるたびにそれを行わなくてはいけなくなりますから、
これが結構なストレスになります。
その上、数ヶ月に一度リリースがあるプロジェクトでは
その都度branchesが新たに作成されます。
しかも、そのbranche対応最中で本番環境においてバグ対応などの緊急リリースが発生しますと、
trunkにもbranchesにも修正を反映しなくてはいけなくなります。
このような同じ修正を複数ブランチへ取り込む、といった対応がSubversionだとかなり面倒です。
その点Gitでは、他のブランチのコミット内容を取り込むことができますので、
このような場面にもSubversionと比較して簡単に対応することが出来るようになります。
要は、ブランチ切り替えを実演した上で、上記のような理由から「管理コストが減る」と言っておけば比較的納得します（笑）
04. Subversionのコミット履歴は移行できるの？という質問に対して
これは「git svn」コマンドを利用することで問題なくできます。
ただ、git svnコマンドはgitを導入しただけでは利用できないので
その点についてはまた別の機会に説明します。
とりあえず、「出来る」と回答してしまいましょう。
05. メリット、デメリットは？という質問に対して
何に対してもメリットとデメリットを求めてくる人が世の中にはいます。
メリットは、先述で説明したことになりますので問題ないでしょう。
ではデメリットと聞かれた場合、どう答えればいいでしょうか。
実は、Gitには１つだけデメリットがあり、
「誰でもコミット内容を自由に編集・削除できてしまう」という点があります。
その点Subversionではコミット内容をひたすら溜めていくだけなので、
制限があるからこそ守らているとも言えます。
これに関しては、予め運用ルールを決めておく必要が出てきます。
・「git push -f」を使わない (ローカルで削除したコミットをリモートリポジトリへ反映できてしまう)
・ブランチを勝手に作成・削除しない
この２つのルールは最低でも導入する必要が出てくると思います。
もし仮に、ルールを決めていたにも関わらず上記が守られなかったとした場合でも、
各人の変更は各々のローカルリポジトリにあるので、
誰かのローカルリポジトリを新たなベースとして、そこへマージしてあげれば問題はありません。
これはDVCSのいいところになりますので、
デメリットを説明しつつもメリットの説明になります（笑）
以上が、比較的聞かれるであろう質問に対する回答になります。
私の場合は周囲に新しい技術に対する理解のある方が多かったことも助けとなりましたので、そのようなメンバーを何人か見方につけるというのも手段の１つになります。
みなさんもめげずにGitへ移行して、脱Subversionしてしまいましょう。
次回は、実際にSubversionからGitへ移行するにあたって
必要となるツールをいくつか紹介します。
うちの社内でもGitに移行したい！と考えている人に、少しでも参考になればと思います。
Gitはもうすっかり世間に浸透してきており、
業界にいる人では利用していない人はいないだろうというくらい多くなって来ました。
しかし、残念なことに未だ日本のIT企業ではSubversionが主流です。
これはGit登場当時、クロスプラットフォームにおける日本語の扱いに問題があったこと、
またWindowsでの動作に不具合が多かったことなどの理由が挙げられます。
かくいう私も、当時はGitよりもWindows対応のしっかりしていたMercurialを推していました。
しかし、Gitもver.1.7.10以降は日本語問題を解決したのと、
Windowsへの対応も大分しっかりしてきたこともあり、
今ではGitを社内SCMとして採用するには必要十分な条件を満たしています。
とはいえ、日本語扱いが怪しいといった当時の印象を持ったままの人が未だにいたり、「Subversionでいいじゃん。敢えてGitに移行したところで教育コストが掛かるしな・・・」などという理由から、移行したがる人がとにかくいません。
こういう人たちに何といえば納得してもらえるのか・・・と考えると、
会社の社風や上司・メンバーの性格にもよるので、確実な手段というものはもちろんありません。
ただ、何もやらなければ結局移行は出来ないので、まずはGitに移行しようという流れをつくることが大事でしょう。
それにはどうすればいいのかということと、
必ず向こうからぶつけられるであろう疑問・質問に対する回答をまとめてみました。
01. Git移行への流れを作るにはまずどこかのプロジェクトでやってみる
プロジェクト単位は比較的小さな単位なので、
その単位であれば許可をしてくれる上司は多いです。
なので、まずはプロジェクトごとにSubversionからGitへの移行を試していけばいいと思います。
更に言えば、「並行開発の多い既存プロジェクト」が一番望ましいです。
その理由については、それがGitの利点を一番生かせるため、成功例として印象付けやすいからです。
02. 「導入してもいいけど教育コスト掛かるんじゃないの？」という質問に対して
社員だけならともかく、パートナーさんなど社外の人をプロジェクトに参入させた場合を考慮し始めると、
やはりコストが掛かるだろうと考える人が多いようです。
先述のとおり、日本のIT業界では未だSubversionが主流なので、Gitを使えない人ばかりだろうという前提で考えている人は多いです。
しかし、Subversionであってもプロジェクトごとにtrunk、branches、tagsの扱い方は違うわけで、結局プロジェクト参入当初の教育という意味でのコストは掛かります。
更に言えば、私はSubversionを知らないという人すらも何人か見て来ました。
なので結局のところ、外部からパートナーさんを呼んだ時であっても、
社員を新しいプロジェクトに参入させたときであっても、
初回の教育コストは掛かりますし、余程アクロバティックなソース管理をしないのであればGitにしたところでそこに差はありません。
Gitであっても、基本はSubversionと同じく、trunk、branches、tagsといったソース管理の考え方自体は踏襲しているので、大きな違いはないと言えます。
03. 「移行することで何が便利になるの？」という質問に対して
当然、それがないことには移行する意味もないわけですから、この点に関する説明も求められると思います。
実は、これが一番難しいです。
何から説明すればいいのかわからなくなりますし、
説明したところで利点に結びつくかどうかは「やってみなければ」みたいな話になってしまう人も多いです。
いわゆる「集中型管理」と「分散型管理」という違いを上げた所で、
「( ´_ゝ｀)ﾌｰﾝ」で終わってしまうのが関の山ですし、
「ローカルでコミットできる」という説明をしたところでも
「一見便利に聞こえるけど、別にできなくてもよくないか？」と言われることもよくあります。
これは結局のところ、Gitを採用しようと思っている人自身も
Gitを満足に複数人開発で利用したことが無いから上手く説明できないことに起因していると言えます。
じゃあ、利点って何なのか。
余計なことはいわずにシンプルに言うと
「ブランチ管理が高速で簡単」
これに尽きます。
そしてこれは、保守と並行して追加開発を複数行う案件など
並行開発が多いプロジェクトほどこの利点が生かされます。
とはいえ、これだけではまだ理解はできないでしょう。
「何がどう簡単なのか」
これを説明するには、実際にEclipseのEGitなどでブランチ切り替えを実演すればわかるかと思います。
ワークスペースを切り替えたり、Eclipseを終了することなく、
ブランチ切り替えを実行することで、数秒〜数十秒ほどで別のソースにガラッと切り替わる。
これは目で見せてあげるのが一番いいと思います。
実際、私もこれを実演したら「これは凄く便利だね」と納得してくれた人が多かったです。
これをSubversionでやろうとすると、
trunk、branchesごとにワークスペースを予め作成しておき、
一回Eclipseを終了させてワークスペースを切り替えて・・・などになるかと思います。
一見これでもいいように聞こえますが、
ソース量が膨大なプロジェクトほどSubversionはチェックアウトに時間が掛かり、
ブランチが増えるたびにそれを行わなくてはいけなくなりますから、
これが結構なストレスになります。
その上、数ヶ月に一度リリースがあるプロジェクトでは
その都度branchesが新たに作成されます。
しかも、そのbranche対応最中で本番環境においてバグ対応などの緊急リリースが発生しますと、
trunkにもbranchesにも修正を反映しなくてはいけなくなります。
このような同じ修正を複数ブランチへ取り込む、といった対応がSubversionだとかなり面倒です。
その点Gitでは、他のブランチのコミット内容を取り込むことができますので、
このような場面にもSubversionと比較して簡単に対応することが出来るようになります。
要は、ブランチ切り替えを実演した上で、上記のような理由から「管理コストが減る」と言っておけば比較的納得します（笑）
04. Subversionのコミット履歴は移行できるの？という質問に対して
これは「git svn」コマンドを利用することで問題なくできます。
ただ、git svnコマンドはgitを導入しただけでは利用できないので
その点についてはまた別の機会に説明します。
とりあえず、「出来る」と回答してしまいましょう。
05. メリット、デメリットは？という質問に対して
何に対してもメリットとデメリットを求めてくる人が世の中にはいます。
メリットは、先述で説明したことになりますので問題ないでしょう。
ではデメリットと聞かれた場合、どう答えればいいでしょうか。
実は、Gitには１つだけデメリットがあり、
「誰でもコミット内容を自由に編集・削除できてしまう」という点があります。
その点Subversionではコミット内容をひたすら溜めていくだけなので、
制限があるからこそ守らているとも言えます。
これに関しては、予め運用ルールを決めておく必要が出てきます。
・「git push -f」を使わない (ローカルで削除したコミットをリモートリポジトリへ反映できてしまう)
・ブランチを勝手に作成・削除しない
この２つのルールは最低でも導入する必要が出てくると思います。
もし仮に、ルールを決めていたにも関わらず上記が守られなかったとした場合でも、
各人の変更は各々のローカルリポジトリにあるので、
誰かのローカルリポジトリを新たなベースとして、そこへマージしてあげれば問題はありません。
これはDVCSのいいところになりますので、
デメリットを説明しつつもメリットの説明になります（笑）
以上が、比較的聞かれるであろう質問に対する回答になります。
私の場合は周囲に新しい技術に対する理解のある方が多かったことも助けとなりましたので、そのようなメンバーを何人か見方につけるというのも手段の１つになります。
みなさんもめげずにGitへ移行して、脱Subversionしてしまいましょう。
次回は、実際にSubversionからGitへ移行するにあたって
必要となるツールをいくつか紹介します。
