現在Subversionなどの集中管理型のバージョン管理システムを利用している、歴史あるプロジェクトに参画している新人プログラマ及び、その上司に当たる熟練エンジニアに向けて、あなたのプロジェクトでGitをプロジェクトで使えるようになるための、はじめの一歩となる記事にしたいと思います。
はじめに
この記事は、モダンな開発者よりも、レガシーなシステムの開発者向けに書きました。
結論から言うと、以下の３つを実現してから、Gitを導入しましょう
１、設計書はGitで管理しようと思わない。設計書の作成・管理方法を見直すこと。
２、ソースコードに品質管理番号等の改版履歴を直書きしないこと。
３、システム更新をリホストだけで乗り切ろうとせず、リライト・リビルドする勇気を持つ。
バージョン管理とは
ソースコードをはじめとしたファイルの変更履歴（バージョン）を管理することを「バージョン管理」と呼びます。ファイルの種類は、例えば.java の拡張子がついたテキストのプログラムです。
ファイルの追加や変更の履歴情報を管理することで、過去の変更箇所を確認する、特定時点の内容に戻す、などの「バージョン管理」という作業が可能となります。一人でプログラムを開発している場合であればなくても困らない場合もありますが、通常複数人で構成されたチームで作業するものですし、たくさんの人に使ってもらうためのプログラムであるほど軽微な修正も含めて履歴を追えることはとても重要です。
このバージョン管理という概念が存在しない状況下での開発作業を考えた場合、本当に軽微な、たった１文字・１行変えるだけの修正であっても、突然動かなくなった時に、バグの修正が遅れや影響範囲の特定が難しくなります。チームでの開発する場合も、メンバー間での開発内容を連携することが難しくなります。
このため、ソフトフェアの開発においては、個人的な小規模開発でも、大規模なプログラムを開発するときでも、バージョン管理の理解は必須です。このため、皆さんのプロジェクトでも、すでにGitを使っていたり、そうでなくてもSubversion(あるいはTeam Foundation ServerやAzure DevOps Server、Bitbucketなど）を使ってバージョン管理をしていると思います。
レガシー環境でGitを導入を阻む壁３つ
ここで、Subversionを利用しているプロジェクトを考えたとき、Gitにはいくつかの問題が立ちはだかります。
問題１ GitってExcelの設計書管理できるの？？
Excelでプログラムの設計書を管理する層にとって、「Gitじゃ使いにくい！」という意見を目にします。初めからモダンな開発に触れている人にとっては理解することができないかもしれませんが、この日本にはExcelを方眼紙にして、それを仕様書にしているプロジェクトはたくさん存在します。
そうすると、こう思うわけです。
Gitで差分を表示してみても、「バイナリファイルなのでバージョン管理ツールで変更箇所を管理できないじゃん」
このような人たちへの処方箋は２パターンあります。
処方箋１：Officeドキュメント管理用ソフトを導入する
１つはGoogle Spread Sheetを用いて設計書をバージョン管理することです。
ただ、それもセキュリティ上できない人たちがいます。
そうはいっても、そういう企業はOffice365のSharePoint(SharePointOnline)でファイルのバージョン管理くらいはできるでしょう。
ただ、これも問題があって自社の社員でないと、アクセス権限が無かったりするわけです。そうすると、困るんですね。
なので、そいういときは、AlfrescoなどのOfficeドキュメントに特化したバージョン管理システムがありますので、あなたの開発サーバーにDockerを入れて、その上でAlfresco Communityエディションのコンテナをダウンロードしてきて動かしてみてください。
処方箋2 Excelの設計書はやめて、専用ツールを使う
draw.ioやastah* professional、を使ってみましょう。
特に、draw.ioはVisual Studioのプラグインとして入れることができるのでお勧めです。
Visual Studio CodeにDraw.io Integrationをインストールして、拡張子を「.drawio」と付けるだけで、設計用のアプリを動かせます。
きっとそれだけでもプロジェクトの管理精度は向上するでしょう。
ただ、それでも、歴史が長いプロジェクトだと、膨大なExcel文書からはなかなか脱却できないですよね。
対処療法としては、バイナリ系のファイル管理は、集中型のバージョン管理ソフトで管理し続けるのが良いでしょう。差分もWinMerge プラグインなどを使えば Excel の差分表示はできますので。
それでも、肥大化したExcelファイルは、どんなツールも手に負えません。
それは、あなたのプロジェクトが不良資産を抱えている証拠でしょう。
問題２ ソースコードに履歴が書いてあるから、差分がとっても読みにくいんだけど・・・
改訂履歴のコメントとは・・・
// NN999999 修正|追加|削除 start
...
// NN999999 修正|追加|削除 end
こういうやつですね。場合によっては、名前や、所属や、日付を入れるかもしれません。
集中管理型のバージョン管理システムを使っているプロジェクトほど、ソースコードにこのようなコメントが入っていることがあります。また、この場合さらに厄介なのは、元々のソース自体をコメントアウトしているわけです。
そうすると、こうなります。
if (a < 10) {
b = c + d;
} else {
b = c - d;
}
このプログラムに対して、
品質管理番号：NN000001 計算式 b = c + d を b = c * d に変更する修正 を入れる
if (a < 10) {
//// NN000001 修正 start
// b = c + d;
//
b = c * d;
// NN000001 修正 end
} else {
b = c - d;
}
そもそも、このような修正方法は、大昔にソース管理ツールなどというものが存在しなかったときの手法ですが、例えSVNを使って、そこにコミットコメント機能があろうとも、その機能を活用せずにこのようなコメントを入れている場合があるわけです。
元々がそのようなプログラム資産ですから、Gitを入れようとすると、まず困るわけですね。
Gitを習うと、必ずコメントを入れて使いますから。
Gitの使い方は、こんな感じです。
リポジトリを新規作成、または既存のリポジトリを初期化します。
git init
プッシュ先のリモートリポジトリを指定しておきます。
git remote add origin <URL>
ファイルを作成します。
touch hello.java
プッシュするためにコミットします。
git add hello.java
コミットする際には１行コメントを入れます
git commit -m "NN000001 Modify hello.java"
git push origin master
実際、差分をみてみると見やすさは一目瞭然です。
Gitでしっかり管理できているファイルは、以下のように表示されます。
GitHubでの差分のUnified表示
Git本来の差分表示
ソースコードに変更履歴を書くと...
GitHubでの差分のSplit表示
Git本来の差分表示
ソースコードに変更履歴を書くと...
Git(CLI)での表示
以下のコマンドで、Git（CLI）でも差分の履歴が表示できます。
git log -p
Git本来の差分表示
ソースコードに変更履歴を書くと...
なので、ソースの中にコメントを書く方法は、Gitととても相性が悪いんですね。
処方箋：Gitを使うのであれば、まずはソースにコメントを直書きすることから廃止しましょう。
問題３ うちのプログラムはSJISで書くことになっているのだけど・・・
モダンな開発者には理解できないかもしれませんが、プログラムのソースの文字コードがSJISで作られているプログラムというものが数多く存在します。
なぜなら、古いプロジェクトほど、移行元となる膨大な稼働資産に引きずられます。
なので、移行前のプログラムがシフトJIS(SJIS)文字コード環境で稼働している場合、必然的に今でもSJISで動いているわけです。
これも、Gitと相性が悪い。コンソールがUTF-8なので毎回文字化けして読めないということになってしまいます。
レガシーシステムのマイグレーション方法には、簡単な順にリホスト・リライト・リビルドとなります。業務ロジックが変わらなければ、20年くらいはリホストで乗り切れるのかもしれませんが、限界を感じます。
Gitを、上記の問題を抱えた既存プロジェクトに対して導入しても、Gitらしく使えるようにするのには大変です。