技術

【SVNバリバリの方へ】 バージョン管理は Git を使おう!

こんにちは。Git信者の @tara です。

今やバージョン管理Gitしかないと言っていいほど、Gitはバージョン管理の主流になりました。

しかし、その一方で現場では SVN が根強く残っており、実は Git ちゃんと使ったことがないというエンジニアがいるのも事実です。

またプログラミングは個人でのみやっている方や勉強中の方は、Git を使ってはいるけど何がいいのかよくわからないという方もいると思います。

本記事は、そんな方に向けて Git の何がいいのかの説明と強くオススメする理由についてになります。

この記事が役に立つ人
  • Git 使い始めたけど、何がいいのかよくわからない
  • 個人開発などで Git を適当に使っている人
  • Git に興味があるけど、別に SVN でいいと思っている人

バージョン管理とは

バージョン管理システムとは、ドキュメントを任意のタイミングで保存し、その時点からの変更点や場合によってはその時点に巻き戻したりできるようにするシステムです。

主にプログラミングのソースコード管理で使われますが、通常のドキュメント管理でも使うことができます。バージョン管理システムを導入すると、例えば

エクセル資料_ver1.1.xlsx
エクセル資料_ver1.2.xlsx
エクセル資料_ver1.3.xlsx


といった、ファイル名に日付やバージョン方法を付加してファイルを何個も生成していくといった前時代的なファイル管理は不要になります。

エンジニアなら開発者でなくても、バージョン管理の概念を知っておくのは当然として、使いこなせるようになるべ技術です。

Git と SVN

バージョン管理システムの製品比較

バージョン管理システムの製品で、代表的なのは下記の2つです。

  • Git
  • SVN(Subversion)

他にもあるのですが、特に知らなくていいでしょう。私はSESやフリーランス経験者ということもあり数々の現場を見てきましたが、この2つ以外の製品が使われているのを見たことがありません。

この2製品を比較すると、

Git: 多機能だが使いこなすのが難しく、学習コストが高い
SVN: 応用は効きづらいがその分シンプル、学習コストが低い

と、いった特徴があります。

この特徴だけ見ると、選びたいのは SVN と思うかもしれません。特に目的がプログラミング学習や個人開発ならなおさらでしょう。

しかし、目的は規模問わずオススメするのは Git です。

これからバージョン管理を始めるなら Git 一択です。現場に SVN が残っているという事情がない限り、SVN を選ぶ理由はありません。

現場に根強く残る SVN 文化

Git 全盛の現代ではありますが、実は現場によってはまだ根強く SVN 文化が残っていることもあります。

理由として主に以下の2つです。

  • 大規模開発で移行が大変
  • ドキュメント管理中心なので、Git移行の必要性がない

1つ目の理由はSI系の開発現場に多く、何年も前にリリースされたシステムを、延々と保守しているといった状況に発生しがちです。膨大なコミット履歴があり、移行にミスは許されないという事情があります。

また関係者が多く Git に踏み切ったら、全員がすんなり Git を使いこなせるわけではないので、運用周りでのトラブルも予想されます。多くの人が、Git を使いたいと思っているのに、移行リスクが高いので実現できないとう状況です。

2つめの理由は、プログラミングが少なめでバージョン管理は主にドキュメント管理にしか使わないという状況です。インフラエンジニアやシステム管理者、システムエンジニアなどといった職種の人にありがちです。

この場合は、Gitはよさそうだけど何かよくわからない、現状の SVN で困っていないという状況です。

いずれ Git を使うことにはなる可能性大

このようにエンジニアとして働いていながらも、現場は SVN のみで Git をちゃんと使ったことがないという方はいると思います。

また開発は個人でしかしていなくて、Git を導入はしているけど何がいいのかよくわからないという方もいると思います。

事実、私も数年前までは SVN ばかり使っていて、Git は個人で何となく使っているだけという状態でした。他部署のエンジニアは Git をばりばり使っていましたが、私は「Git って結局何がいいの? 別に SVN で事足りているよ。」と思っていました。

しかし、転職をして考えが一転します。転職先ではインフラのコード管理が導入されていて、Git がバリバリ使われている環境でした。ここで日々 Git を使うようになって考えが改まり、「Gitすげー、もっと早く使っておけばよかったー」となりました。

このように SVN しか使っていなくても、いずれは Git を使うことになると思います。

大規模開発で移行コストが高いと行っても、Git の方が便利なことには明らかですし、何かのタイミングで移行に踏み切るかもしれません。また、そのプロジェクトを外れて別プロジェクトに携わるようになったら、その時は Git の可能性大です。インフラもプログラムを書くようになってきたので、いずれ Git になるでしょう。

この流れを考えると、個人開発や新規のサービス導入時などに隙あらば Git を使うようにしておくべきです。

Git を強くオススメする理由

では、なぜこれほど Git を強くススメるのか。その理由は、下記の通りです。

  • 使い始めるだけなら簡単
  • 綺麗すぎるGUI
  • 現在の開発の主流、Webサービスの開発はほぼGit

Gitはローカルコミットができるなどといった機能的な視点からも Git を使うべき理由があがるのですが、機能面を考えなくてもGitを使うべき理由がこれだけあります。

使い始めるだけなら簡単

Git は、SVN に比べて学習コストが高いですが、導入、使い始めるだけなら SVN より簡単です。

SVN は、サーバに apache や subversion をインストールするといったサーバ構築作業が必要になります。Dockerイメージでサクッと立てる方法もありますが、サーバどうするのといった問題は残ります。

一方、Git は GitHub にアカウントを作成するだけで、すぐに使用できます。

昔は、プライベートリポジトリは有料だったので、ソースコードを公開したくなかったら、GitHub に毎月700円払うか、SVN のように個人で GitLab などの Git製品のサーバを立てるしか方法はありませんでした。しかし、GitHub が MicroSoft に買収されて、今は無料でプライベートリポジトリが使えるようになりました。個人開発をする人からしたら、非常に嬉しい変更です。

綺麗すぎるGUI

これは SVN を使い続けていた身からすると、非常に画期的なことでした。

Gitは、バージョン管理に施した、コミットメッセージや変更内容が、ブラウザで今風の綺麗なUIで見ることができるます。SVNには、そういった機能はありません。

コードを勢いよく書いてコミットした後、自分がやった変更内容をブラウザで眺めてムフフするのは楽しいですよ(笑)

現在の開発の主流、Webサービスの会社はほぼGit

Git を使うべき一番の理由は、みんな使っているからです。

上記は Git と、それ以外のメジャーなバージョン管理のトレンド比較です。Git が圧倒的です。

新規のサービス開発はまず Git が採用されますし、求人情報の採用技術は Git ばかりです。この図を見るまでもなく、Git はデファクトスタンダードということが体感できます。

技術者なら Git を使えて当然というレベルになってきています。

Git を使い始めたら

とりあえず使ってみるべき機能たち

Git は多機能すぎて、最初は何していいかわかららないと思います。

現場が Git でなくて、個人開発などで少し使い始めたという人は、とりあえず他のバージョン管理と同じ使い方をすればいいでしょう。

他のバージョン管理と同じ使い方するなら、わざわざ Git にする必要ないじゃんと思うかもしれませんが、同じ使い方をするだけでも、操作のしやすさやWeb UI のありがたみなどといった Git の良さがわかります。

具体的には以下のことをやるだけで十分です。

Git 基本コマンド
  • git add
    Git 管理下に置くファイルを登録する
  • git commit
    コミットする
  • git push
    プッシュする(コミットした内容をリモートリポジトリに反映する)

Git クライアントはどれを使う?

Git は、GUI製品がいくつかあります。これは便利なことは確かですが、最初は Git コマンドを理解するために Git デフォルトの CLI クライアントを使うことをオススメします。

上記の操作(add, commit, push)をするだけなら、コマンドラインだけでも十分です。コマンドラインを使いつつ、IDEに付属している Git クライアントを使うのがいいでしょう。

慣れてきたらブランチを使う

Gitに限った話ではありませんが、バージョン管理にはブランチという概念があります。Git になれてきたら、ブランチを作成して簡易的な Git-flow を取り入れてみましょう。

ブランチとは、簡単に言うと開発フローを並行化したものです。ブランチを知らない人には、これだけ言っても意味がわからないと思いますが・・・ とりあえず、使ってみると感覚的に理解はできるはずです。。。

個人開発だと master ブランチだけで開発してしまいがちですが、develop ブランチを作って通常の開発は develop ブランチで行って、本番で動かしていいというレベル単位で master ブランチに反映ということをやると Git-flow というものが理解できるようになります。

Git-flow に必要なコマンドたち
  • git branch
    ブランチを作成する
  • git checkout
    ブランチを切り替えする

developブランチの内容を、masterブランチに取り込む作業は Web UI 上で行います。この行為は プルリクエスト(pull request)といいます。PLプルリクと呼ばれることも多いです。

ちなみにプルリクエストは、Git製品が変わると用語がかわります。GitHub ではプルリクエストと言いますが、同じことを GitLab ではマージリクエスト(MR)と言います。

プルリクエストは、

コード反映リクエスト -> コードレビュー -> 承認(masterブランチにコード反映)

という行為なので、通常は二人以上の人がかかわります。

個人開発だと、リクエストするのも承認するのも自分(いわゆる一人プルリクエスト)なので意味ないと思うかも知れませんが、それでも取り入れるべきです。

Git-flow の理解にも繋がりますし、masterブランチを動くレベル単位にしておくと、何かあったときにとりあえず巻き戻すことができます。

まとめ

以上、Git 未経験者/初心者を対象に Git オススメ! とい記事でした。

Git は、本当にどこでも使われていますし、使い始めると面白いですよ。食わず嫌いで Git を使ってこなかった人は、機会を見つけて使い始めてみましょう!

ABOUT ME
tara
tara
年収360万円でIT業界のキャリアスタート
SES -> Web業界 -> 大手メーカー -> フリーランス
と経験してきて、現在は年収1000万円を越えました。

エンジニアのキャリアアップに役立つ情報を発信していきます。