Ikeda->Weblog();

Ikedaの徒然雑記。

分散バージョン管理システム git を使ってみる。

| 0件のコメント

分散バージョン管理システム を使ってみる。仕事でとあるWebサイトのサーバ群を管理しています。

ここのWebシステム、DBサーバがシングルポイントだった為、レプリケーションを行う事になりました。
が、既に稼動しているシステムのうち、いくつか「ヤバい」ものが発見されたのです。

具体的にはPostgreSQLのLargeObjectやOIDに依存している部分。これを機に一度全てのプログラムをチェックし対応する事となりました。対象は全てのPHPプログラム、総ファイル数1500

とりあえず洗い出しが終了し、具体的な対策を取る段階までこぎつけましたが、実際のサーバ上のファイルをいきなり変更するのはちょっと怖い。ということで、急遽仮想的な環境を構築しました。

全てのコンテンツとデータをそれぞれ仮想WebサーバとDBクラスタにコピーし、いよいよ修正です。

と、ちょっと待て。


もし修正間違いとか起こったらどうする?3日前のバージョンに戻したい!なんてことになったら。
バックアップファイルを山ほど作っても、どれがどの変更を施したバージョンだかわからなくなるぞ?


こんな事態、ありがちっちゃーありがちですよね。

だがご安心あれ。

世の中には便利なシステムがあるのです。その名も「バージョン管理システム」。一言でいうと、どのファイルがどういう変更を加えられたか記録し、バージョン付けを管理してくれるシステムです。

一昔前にはCVSというシステムがありました(古すぎ?)。
現在の代表格というと、Subversionとgitでしょうか。今までバックアップと分散開発環境構築の為にSubversionを使っていましたので、今回はgitに挑戦することにします。

使用環境としてはFedoraCore6。なんで6?という突っ込みは却下です(たまたまインストールCDが手元にあったから、というのは内緒)。

さて、まずはインストール、、、と言ってもコマンド一発で完了しちゃいます。

% sudo yum install git

これだけ。
途中、いくつか確認を求められますが、「良きに計らえ」と”y”で応対しておきましょう。

続いて、管理対象とするディレクトリに「リポジトリ」を作成します。
リポジトリとは・・・・git の扱う管理領域だと思ってれば大体OKじゃないかと。登録(コミット:commit)されたファイルの更新履歴や内容、リビジョン(バージョン)情報等が格納されたデータベースです。

「このファイルをリポジトリにコミットしといて」とか「最新バージョンをリポジトリからチェックアウトおいて」って使います。多分。

今回、バージョン管理対象にしたいディレクトリは主に3つ。

  • www
    • htdocs  –  メインサイトのドキュメントルート
    • lib – PHP ライブラリ群
  • master
    • htdocs – 管理サイトのドキュメントルート


早速リポジトリを作成し、各々のディレクトリ内のファイルをgit管理下に置いていきましょう。

まずはwww-htdocs。
ディレクトリに移動し、おもむろにリポジトリ作成コマンドを叩きます。

% git init .

はい、完了。簡単ですねー^^

Subversionに慣れた方だと、「あれ?リポジトリってどっか共通領域とかサーバに作るんちゃうの?」と思われるかと思いますが、それは Subversionが単一リポジトリ型なのに対して、git が分散リポジトリ型だからなのです。

単一リポジトリ型はSubversionやCVSが採用している方式で、「中央集権型」です。プロジェクト1つに対しリポジトリは1つ。各作業者はリポジトリから自分の作業するファイル群をコピーし、作業が一段落したところで修正内容をリポジトリに反映(コミット)させる、という方法です。作業者の手元にあるのはあくまで作業用のコピーなので、コミットしない限り変更履歴の管理は行われません。

gitの採用している分散リポジトリ型は、その名の通りリポジトリが分散して複数存在します。作業者は自分用のリポジトリを持つことができ、作業内容はマイリポジトリに対しコミットします。そのままでは各作業者ごとにバージョンが異なるリポジトリが存在してしまいますので、これらリポジトリ間で通信を行い変更点を同期させる必要があります。これにはいくつか運用方法があるようですが、どこか1つを「マスタ」と決め、それに対して各作業者のリポジトリを反映させる方法がわかりやすいかもしれません。

このあたりに関してはこちらのページに詳しく解説されています。

さて、先程 www-htdocs に、専用リポジトリを作成しました。
が、まだリポジトリにはファイルが登録されていません。既存ファイルを初期バージョンとして登録してしまいましょう。 では “svn import” で行った、インポート作業ですね。

% git add .
% git commit


終了。「カレントディレクトリ以下の全ファイルをリポジトリに登録」し、「コミット」したわけです。

では、他のディレクトリ用のリポジトリも作成してしまいましょう。

% cd www/lib
% git init
% git add .
% git commit

% cd master/htdocs
% git init
% git add .
% git commit


完了。
さて、この時点では各々に専用のリポジトリを作りました。今回、作業者は一人ですからユーザごとに分散させる必要はありません。

が、最終的な配布やバックアップも兼ねて、上記3つのリポジトリを統括する「マスタリポジトリ」を作成しておくことにしましょう。

% cd /home/git/master
% mkdir www-htdocs libs master-htdocs
% cd www-htdocs; git –bare init
% cd ../libs; git –bare init
% cd ../master-htdocs; git –bare init



さて、それでは各リポジトリの内容をマスタリポジトリに反映させておきます。

っと、その前に、各リポジトリに「これがマスタリポジトリだよ」と教えておきましょう。

% cd www-htdocs
% git remote add origin /home/git/master/www-htdocs



これで、www-htdocs リポジトリに「origin」という名前でマスタリポジトリの www-htdocs が登録されました。あとは www-htdocs リポジトリの内容をマスタに反映させるだけ。

% git push origin master


「現在のリポジトリ内容を origin リポジトリ(マスタの www-htdocs)に反映(push)」という意味です。これを他の2つのリポジトリに対して行えば、初期セットアップは完了です。

git はコミットをローカルリポジトリに行う為、とにかくコミット完了までの時間が短いです!
また、ローカルにリポジトリを持っている、ということは「ネットに接続していなくてもOK」ということ。つまり、移動中にノートPCで編集してコミットできる、ということです。

後程ネットに接続し、ローカルリポジトリの変更点をマスタリポジトリにpushしてやればいいわけです。

さて、これから実際の開発作業に入ります。また簡単なまとめ記事を書きますね^^


参考サイト:

コメントを残す