はじめに
こんにちは。この記事では現在SVNを使っている方に向けて、Git移行に関する有用な情報をまとめています。SVNからGitに移行を考えている方や、Gitってよく聞くけど、SVNとはどう違うのかイマイチ良く分からないという方に、それぞれの比較を交えながら移行のポイントなどもまとめました。
では早速学んでいきましょう。
レッスン１．それぞれの利点
GitとSVNは良く比較対象として挙げられます。新しい分、完全にGitが優れているかというと、そういうわけでもありません。もちろんそれぞれに一長一短がありますので、まずは比較してみましょう。
| – | SVN | Git | 長所 |
|
|
短所 |
|
|
|---|
このように、それぞれに一長一短がありますが、作業コピーの変更を記録できる、ローカルブランチの存在が大変大きいアドバンテージであるため、Gitの利用者は年々増えています。
レッスン２．構成の違い
では、続いてリポジトリの構成について比較してみましょう。下記の図をご覧ください。左がSVNで右がGitです。これを見てわかる通り、構成の大きな違いとしては「ローカルリポジトリ」があるかどうかです。
SVNではコミットをすれば即座に共有リポジトリに反映されますが、Gitの場合にはコミットすると一旦ローカルリポジトリに格納されます。そこで「プッシュ」という操作をすることで共有リポジトリに反映されます。
一方共有リポジトリから変更を取得する場合には、SVNでは「アップデート」を使いますが、Gitの場合は「フェッチ」を使ってローカルリポジトリに取り込んだ後に「マージ」を使って作業フォルダに反映します。
この「フェッチ」、「マージ」を一度に行う「プル」という操作方法もあります。普段作業フォルダの更新に使うのはこちらの操作がメインです。この操作をすると、ローカルリポジトリと作業フォルダが一度に更新されます。
レッスン３．用語の違い
では続いて、用語の違いの説明をしたいと思います。主な用語を一覧表にまとめてみました。
レッスン2で少し触れましたが、SVNとGitには似た操作がありますが、意味が異なる場合もあります。そのあたりに注意しながら、確認してみてください。
| SVN | Git |
|---|---|
| コミット | プッシュ |
| アップデート（更新） | プル |
| チェックアウト | クローン |
| trunk | master |
| Externals(外部参照) | Submodule（サブモジュール） |
| リポジトリブラウザ | リファレンスをブラウズ |
Gitにしかない用語ももちろんあります。例えばレッスン２でご説明した「フェッチ」などです。Gitは機能が多い分、SVNにはない用語があります。今回はSVNとの比較をメインにした記事ですので、Gitの機能の詳細については言及しませんが、Git専用の用語については操作方法を学習する際に確認してください。
レッスン４．使用方法の違い
では続いて、実際に使用する上での操作方法などの違いを比較してみます。
共有リポジトリへの反映と更新
これはレッスン２でも説明しましたが、SVNでは「コミット」だったのがGitでは「コミット」と「プッシュ」という操作に分かれています。
また、作業フォルダの更新はSVNでは「アップデート」となりますが、Gitでは「プル」となります。
コードレビューの方法
SVNでコードレビューを行う場合には、あまりメジャーなツールが無いことから、開発現場によってさまざまなツールが用いられております。一般的にはコミット前に変更パッチを作り、それでレビューした後に、改めてコミットログを書いてコミットするという方法を取るかと思います。
一方Gitでは、GitHubにマージリクエストという強力なレビュー機能があり、広く一般的に使われています。レビューをする時点で既に変更内容が共有リポジトリに上がっていますので、レビューが終わったらブラウザ上でマージボタンを押すだけで、本線(master)にマージされます。
操作方法が業界のスタンダードに沿っていることは意外と重要なことで、万が一転職などで異なる会社のチームに行ってもスムーズにプロジェクトに入ることができます。
ブランチ作成方法
SVNでブランチを作成する際には、基本的にbranchesのディレクトリ以下に作成しますが、システム的にはどの場所に作成することができます。また、プロジェクトが肥大化してくると、プロジェクト毎にbranchesができると思いますので、相手が言っているブランチはどこにあるのか？また、作成時はどこにブランチを作るべきなのか？といった疑問を招くことがあります。
その点Gitはブランチの作成場所の指定がありません。そのため、作成のためのステップが少なくなりシンプルです。いつでも気軽にブランチ作成ができます。また、作成済みのブランチを選ぶときには、常にそのリポジトリにあるブランチ全てが表示されます。
ですが、一方で探しにくくなるデメリットもありますので、ブランチ名のルールを適切に決める必要があります。
レッスン５．Gitに移行する前に注意すべき点
ここでは、SVNからGitに移行する前に注意しておくべき点を説明します。
(1) Externals属性について
まず、移行の際に最もネックになるのがExternals属性です。プロジェクトによっては、外部のSDKなどを参照するために、SVNでExternals属性を付けて外部参照している場合があると思います。Gitにもこれと似たSubmoduleという機能があります。
しかしながら、ブランチを頻繁に切り替えながら使うGitの特性上、Externals属性があると、ブランチ作成時に組み合わせるバージョンを意識する必要があるため、組み合わせるべきSDKのバージョンを間違ったり、意図せずブランチ側のSDKバージョンを更新してしまったりする等のミスを引き起こす可能性があり、操作も管理も煩雑になります。
そのため移行前に、そのExternals属性は本当に必要なのかをまずは吟味し、必要なのであればどのようにSDKのバージョン管理するのかを決めた上で移行することをお勧めします。
(2) 運用ルールについて
次に運用ルールです。SVNとは違い、ブランチを気軽に作成できるかつ、同じ場所に作られるためにブランチが乱立しがちです。そのため、前述したようにブランチ名のルールを決めるといった運用が不可欠です。
また、マージが完了したブランチは削除するといったルールも有効です。削除するというルール策定しても、どうしても一定数消し忘れが発生しますので、定期的にブランチの一覧を確認し、増えてきたらチームにアナウンスして消してもらうといった作業も必要になってきます。
(3) チームの理解を得る
実はここが最重要ポイントと言っても過言ではないですが、SVNから移行する際、操作が板につくまでは一時的にメンバーは不便を強いられます。説明しないで導入してしまうと、Gitの導入に何のメリットがあるのか疑問を持ったまま仕事をすることになってしまいますので、モチベーションが下がってしまいかねません。
Gitを導入することで一部操作が増えるが、それを差し引いてもメリットがあるという説明して、理解を得ることが重要です。
万が一、Gitは使いたいが賛同が得られず、SVNを使い続けるという結論に至った場合、git-svnという機能があります。これは、SVNのリポジトリをＧitのクライアントからチェックアウトできるコマンドです。ローカルリポジトリが作成できるのでＧitライクに利用できます。もちろんコミットもできますし、ログメッセージは通常のSVNクライアントを使った場合と変わりません。他のメンバーはSVNを使っていても一人だけgit-svnでGitを使うといったことが可能となります。
ですが、git-svnの場合はプルリクエストが使えませんし、使い勝手や管理方法もGitとは若干異なる点がありますので、できればGitに移行するのがベストです。あくまで苦肉の策としての位置づけです。
移行の際には、これらの点にあらかじめ注意してから移行を考えてみてください。
さいごに
Gitに移行する理由は様々です。バージョン管理ツールとしてGitがトレンドだとはいってもSVNを使っているプロジェクトはまだまだ多いのが現実です。少人数のプロジェクトであればSVNの方が楽に運用できる場合もあります。メリットとデメリットをよく理解し、それでもメリットの方が多いと判断できるのであれば移行に踏み切るといったステップを踏んでいきましょう。
とはいっても、使う目的は同じですので全くの初心者が使うよりもSVNを使っているチームが移行する方が理解しやすいのは事実です。導入説明などを行う際も、SVNの各操作に置き換えて比較することで、理解が早まると思います。
使いこなせればこれほど便利なツールはありませんので、前向きに導入を検討していただけると良いと思います。
導入に関する記事
以上を踏まえて実際に導入に移る場合は、下記の記事を参照して環境を構築してください。
https://tracpath.com/bootcamp/learning_git_firststep.html?preview_id=88
