ほんの数年前まで恥ずかしながらおよそバージョン管理システムとは縁のない仕事の仕方をしていました．会社でSubversionを使うことになっていたのですが、単に修正したスタイルシートを放り込むのがせいぜいで、すべては結果にしか過ぎませんでした．もしいろいろ変更があっても、ローカルでソースをZIPしてクラウドに保存していました．しかし仕事のサイクルがタイトになり、お客様にリリースしたら直ちに次のバージョンの開発を開始し、同時にリリースしたバージョンの障害管理もするということになると、到底手動のソース管理では追いつかなくなります．
1. リリースバージョンのバグを修正したらただちにお客様にリリースしなければなりません．
2. リリースバージョンのバグは開発バージョンにも反映させねばなりません．
という訳でバージョン管理システムが必須になります．障害があれば修正用ブランチを切り、FIXしたらマージをしてという作業をいう作業をやることになります．
会社はSubversionですが、オープンソースで公開しているDITA-OTのプラグインはGitHubを使っています．Subversionはやっとやり方を覚えてきたのですが、GitHubはまだ勉強中です．ほとんどGitHub for Windowsを使って済むのですが、やはりお客様に納めるスタイルシートと同様に、開発バージョンがあってリリースバージョンがあってという状況は同じです．「GitHub実践入門」と言う本が技術評論社から出ていて役にたっています．でもこの本を読むともうGitHub Flowなんかでは「常にデプロイ」．リリースという概念はない」のですね．
なかなか追いついてゆけませんが、そのような初心者でもわかりやすいブランチとマージを学習できるサイトがあります．GitHub実践入門で紹介されていました．
ここの左下にコマンドウィンドウがあり、gitコマンドを入れられます．試してみたのは次のようなストーリーです．
１．masterブランチから開発用ブランチdevelopを作成し、数回commitして開発を進める．
２．リリースのmasterにバグが発生したので、masterに戻ってbugfixブランチを作る．
３．bugfixブランチで修正をコミット．FIXを確認．
４．masterブランチに切り替えて、bugfixブランチをマージ．（このときは単にmasterのリビジョンがフォワードされるだけなのですね）
５．developブランチにも同様のバグは存在するので、developブランチに切り替えて、bugfixブランチをマージ．
ここまでに入れたコマンドは以下のとおりです．
グラフィカルにリビジョンとブランチが表示されるので非常に理解しやすいです．もしGitHubをお使いになる予定があれば是非お試しください．
