NEWS ABOUT SERVICE WORKS TEAM BLOG RECRUIT お問い合わせ JP EN

バージョン管理のすゝめ ~その1(仮)

こんにちは、エンジニアの藤野です。

今回は、 システム開発の旅のお供「バージョン管理」の素晴らしさについて軽くご紹介したいと思います。
詳しい機能や使い方まで伝えようとするとページがいくらあっても足りないので、今回は「その1」とし、

  • そもそもバージョン管理とは何ぞや?
  • で、そいつを使うと何がいいの?

といった辺りを中心に、
「え~、何か面倒くさそう。。。」という人に「バージョン管理って素敵!さっそく取り入れてみよう!」となってもらうことを目的として書いてみようかと思います。

やる気が続けば、その2・・・として詳しい機能や使い方まで、
シリーズ化してお伝えしていければと思います。(今のところ)

 バージョン管理とは何か

とあるお客さまの開発用サーバに更新をしようとしたある日…

orz...

orz…

何とはなしに古いのを消すのが怖い…という過去の担当者たちの葛藤が積もり積もった感じでしょうか。
そもそもidnexとは何なのか。。

几帳面なO型を自負する私はこういうのを見るとたまらなくモヤモヤします。。。
バックアップはせいぜいローカルに残しておいて
開発用とは言えせめてサーバ上は出来るだけ本番環境と同じきれいな状態にしておきたいものです。

この状態では実際に必要なファイルがどれなのかやがてわからなくなり人的ミスの原因となりますし、
いざという時のためのバックアップとはいえ、
それぞれの時点でのファイルに紐づく画像ファイルや読み込んでいる外部ファイルなども存在するはずなので
結局ある時点での状態に直ちに戻すことは不可能です。

また、複数人で開発・更新している場合、
他の担当者Aさんが修正したことを知らずに自分のローカルにあるファイルが最新だと思い込み
それに修正を加えてサーバ上に更新してしまい、Aさんの作業を無に帰すという
いわゆる「先祖帰り」が起こるというのもよく聞く話です。

何かいい方法はないものでしょうか。。
そう、そんな時こそ「バージョン管理」の登場なのです!

バージョン管理の種類

バージョン管理は大きく「集中型」と「分散型」と呼ばれる2種類に分類されます。
それぞれ、「集中型」はSubversion(SVN)やCVS、「分散型」はGitやMercurialあたりがメジャーどころかと思います。

集中型」は中央サーバーがファイルの原本と更新履歴(リポジトリ=「貯蔵庫」の意)を一元管理するのに対して、
分散型」はそれぞれのローカル上にリポジトリを持っているイメージです。
分散型」ではローカル上にリポジトリを持っているので、
個人的に一時的な開発用ブランチを作ってマージしたりすることも容易です。

まぁ、難しいことはいいのでここでは「へぇ~」くらいに思ってもらえればいいと思います。
分散型」の 方が新しく、今後(すでに?)主流になっていくものと思われます。

バージョン管理の使い方

では、実際にどのようなものか軽くご紹介していきましょう。

Mercurial&TortoiseHg

Mercurial&TortoiseHg

弊社では「分散型」の「Mercurial」を使っています。

どちらかというと「Github」で有名な「Git」の方が最もメジャーな感がありますがここは敢えて「Mercurial(hgコマンド)」です。
理由は私が入社した時すでにMercurialが運用されていたからです。(`・ω・´)
基本的な機能や使い方はGitとほぼ同じと思ってもらって構いません。

まず、弊社では新たに開発を始める場合、開発用サーバにMercurialリポジトリを作ります。
分散型」ではありますが複数人で作業するのでみんなから見える共通の原本を作るイメージですね。

各作業者はローカルのPCに「TortoiseHg」をインストールしています。
弊社ではデザイナーさんもこれを「かめ」と呼び慣れ親しんでいます。(^ω^)

ローカルの作業フォルダで右クリックから[TortoiseHg]-[Clone]をクリックします。

TortoiseHg

TortoiseHg

出てきたダイアログボックスに開発用サーバに作ったMercurialリポジトリのアドレスを指定して[クローン]をクリック!
するとリポジトリにあるソースファイル一式がドワーッとローカルに落ちてきます。

落ちてきたファイルには以下のような緑の「」マークが付いています。

これらのファイルはMercurialの管理下であることを表しています。
また、ファイルを編集すると赤で「」が付くので一目瞭然ですね。

この作業フォルダで再度右クリックから今度は[Hg Workbench]をクリックします。
すると以下のようなウィンドウが開きます。

このフォルダ以下で起こったすべての修正履歴をここで見ることができます。

ここまでがまずは下準備といったところでしょうか。
大分長くなってきたのでより詳細な機能や使い方は次回以降につづけることにします。

バージョン管理を使うとこんないいことがある!

予告も兼ねて、これを使うとどんないいことが起こるかを以下にまとめておきます。

  • 「index.html.bak」「index.html.20140216」のような名前のファイルを大量にストックしておかなくてよい!
  • 他の作業者の修正内容をうっかり上書きしてしまうことがない!
  • 今までの修正履歴がすべて簡単に見られる!
  • さらに、一瞬である時点での状態に戻せる!
  • 本番公開中のソースはそのままに新機能の追加などの修正を分離しておこなえる!
    などなど…

特に複数人で作業する案件であればもはや必須と言っても過言ではない・・・
と個人的には思っております。

私なんぞはもはやちょっとした更新でも取りあえずリポジトリを作って最初の状態をコミットしておかないと不安で夜も眠れません。。

どうですか?まだつかってないあなたも使ってみたくなってきませんか!!!?

結局一回ではまったく「バージョン管理って素敵!さっそく取り入れてみよう!」に行きつけなかったです。。(´;ω;`)

ちなみに、早速じっくり勉強してみたいと思った方は株式会社ヌーラボさんのこちら「サルでもわかるGit入門」のページがGitについてですが非常にわかりやすくまとまっていますよ!
私もGitについて勉強する時活用させていただきました。

 つづく

藤野 隼吾
ひとつ前の投稿 ひとつ前の投稿
ひとつ前の投稿 ひとつ前の投稿 個人アプリ開発のあんなこと、こんなこと