このページを見に来た人は当然Gitを使っている人だと思いますが、
Git、すなわちバージョン管理システムの歴史について知っていますか？
バージョン管理システムの歴史及び「今後どうなっていくの？」
ということについてまとめていこうと思います。
そもそも、バージョン管理システムってなに？イメージを説明
バージョン管理システムとは、 “バージョン” を “管理” する “システム” です。(当然)
皆さんはゲームをする時にセーブって絶対にしますよね？
ある町に着いたとき、ボス前、レアドロが落ちた後、など
人によってタイミングはまちまちだと思いますが。
これら一つ一つはある地点でのセーブデータのバージョンになります
(version.〇〇町到着、version.△△ボス前、version.□□ドロップ後 という感じ)
このセーブデータのバージョンを管理する、というのをイメージに持っておいてください。
バージョン管理システムの目的と歴史
では、セーブする目的ってなんですか？
何かあった場合にそのセーブ地点から再び始められるようにするためですよね。
これはシステム開発(ゲーム製作とか)でも、有用だと思いませんか。
「なんかプログラム書いてたら動かなくなっちゃった！昨日の状態に戻したい！」
この考えが出てきたのが、1970年代です。
PCが普及し始めたのも1970年代なので、当初から考えてられていたことなんですね。
世界初のバージョン管理システム、SCCS(Source Code Control System)は1972年に誕生しました。命名もド直球ですね。
ただ、このSCCS、ゲームのセーブデータと大きく違う点があります。
それは、
- (ゲーム) データを全て保存する
- (SCCS) 変更ごとに違い(どのファイルを書き換えたか、作ったか)を保存する
ということです。
ゲームは、昔のセーブデータを消すことがあります。
ですので、それぞれのセーブデータが独立して、必要なデータ全てを持っている必要があります。
しかしSCCSは、昔のコミットログ(変更履歴)を消すことは想定されていません。
『○月△日：ABC.txt を消しました』といったログは消さずに常に持ち続けます。
“必要なデータ全てを保持する“、”変更点だけの情報を保持する“、この2つの違いは非常に重要です。
しかし、SCCSはバイナリファイルに対応していませんでした。
そこで約10年後の1982年、バイナリファイルに対応したRCS(Revison Control System)というバージョン管理システムが誕生しました。
~1990年頃までは自分のコンピュータ上でのみファイル管理するのが主流でした。
というより当時はコンピュータが高価すぎて、皆で1台のコンピュータを使用することが多かったからですね。
ですが、1台のコンピュータにデータ全てを任せるのは怖い。
壊れたら終わりですからね。
そこで1990年に、サーバクライアント型(C/S型)のバージョン管理システム、CVS(Concurrent Versions System)が誕生しました。
これまでローカルでのみファイル管理していたのが、サーバ上で管理するものになりました。
また、ブランチという並行バージョンの機能も導入されました。
しかし、ファイル名/ディレクトリ名の変更をうまく扱えないという欠点もありました。(個人的にはかなり致命的に思う)
そして、更に10年後、2000年にSVN(Subversion) が誕生しました。
CVSで問題だった”ファイル名/ディレクトリ名の変更をうまく扱えない”ということを解決しています。
さらに、今まではファイルごとにバージョンの番号が割り当てられていた(ex. ファイルA:ver.12 ファイルB:ver11 ファイルC:ver.9 … )のですが、
ソースツリー全体に対してバージョン番号が割り当てられる方法をとったのもこれが初です。
加えて、SSH通信を標準でサポートしています。
※ちなみに現在でも、このSVNは古いシステムだと利用されていることがあります。(私が実際に担当しているプロジェクトでも一部そうです)
記事作成時、最新版が2019年1月なのでまだ需要があるということですね。すごい。
そしていよいよ大本命。2005年にgitが誕生しました。(ちなみに同年にMercurialというのも誕生しました。gitと似ています。)
SVNはC/S型であるため、ネットワークにアクセスできない状況だったりするとコミットが出来ませんでした。
gitは
- サーバに存在するリモートリポジトリ
- 利用者がそれぞれ所有するローカルリポジトリ
に分散させることによって、ネットワークに接続できない場合でもローカルリポジトリにコミットが出来るようになりました。
また、リモートリポジトリの完全なコピーを各利用者が持つので、コミットログを確認したりもネットワークを通さず出来ます。
さらに、今までバージョン番号は1~の連続した番号だったのですが、gitはハッシュ番号が振られるようになりました。
このことにより、他のブランチからマージする際にトラブルが起きることが少なくなりました。
gitはSVNに比べてチーム開発で使いやすくなっているように感じます。設計思想というのでしょうか。
このように、バージョン管理システムの機能は移り変わっていきました。まだまだ細かい違いはあると思いますが。
以上を簡単にまとめると下の図のようになります。
今回は、SCCS・RCS・CVS・SVN・gitの5つを取り上げました。
しかし、バージョン管理システムはこれよりも沢山存在します(していました)。
それぞれのシステムは過去の問題を解決するために改良を繰り返しています。
ですので、2005年には全員が全員、gitに乗り移って使用し始めたということではなく、
この時代に発生していたこの問題を〇〇は解決した、ということに着目して読んでいただきたいなと思います。
では、今後どうなっていってほしい？ 今後の展望
初版から約15年、gitというシステムが使用されてきて、今から改善するところなんてあるの…？というのが正直な感想です。
“バージョン” を “管理” する “システム”。
“バージョン”は、もう既に細かく分けられていますね。ファイルのどこが書き換わったのかという情報まで細かく。
“管理”は、どうでしょうか。コミットログを見ることができたりするので管理はできていると言えるでしょう。
それぞれのローカルリポジトリを管理することは出来ていないので、改良するとすればそこですかね…。(でもこまめにコミットプッシュすればいいじゃん…)
“システム”については、システムとしての欠陥があるかどうかということですね。セキュリティ対策や障害が起きた時にどうなってしまうのか。
昨年Githubで43秒間ネットワークが止まったことによって1日間サービス障害が発生しました。(https://www.atmarkit.co.jp/ait/articles/1810/31/news063.html)
原因はネットワーク機器の部品交換という物理的なものでした。ユーザデータが本当に正しいかを検証しながら復旧するために1日の時間を費やしたようですが、
Githubの膨大なデータを1日で完全に復元する手際の良さは素晴らしいですね。
他に話題といえば、cloneした際にコマンドインジェクションを起こすセキュリティ脆弱性が見つかったというのもありました。(https://forest.watch.impress.co.jp/docs/news/1124686.html)
以上のように問題は適宜解決されています。問題ないじゃん！
では、『バージョン管理システム』という観点から少しズラして、『チーム開発におけるバージョン管理システム』ではどうでしょうか。
開発者が求めるのは結局動くプログラムです。
自分が作ったプログラムが他にどんな影響を与えるのかということを知るのは非常に重要です。
ですので、結合テストなどのテストをバージョン管理システムが勝手に行ってくれるサービスがあればデバッグは相当楽になりますよね。
関数の呼び出しに基づくファイル間の関係(ネットワーク)を管理することができれば、作業工数をへらすことに役立ちそうだなと思います。
なんだか、そういったツールは別で存在していそうな気はしますが…
ということで、バージョン管理ツールにこんな機能あったらいいな、という変な着地(?)になってしまいました。
あまり展望について語れなくてすみません…知識不足です…
歴史をなぞると「次はどうなりそうかな？」がわかると思ったのですが…一切見つからないあたりgitすごいっすね…
では、以上です。お読みいただきありがとうございます。
[蛇足1]
今だと、「ソースコードを共有するならgitじゃなくでDropboxやGoogle Driveとかのクラウドでいいじゃん！」と思う人も多いと思います。
クラウドに一応バージョン管理の機能はついていますが、優秀ではありません。
どの部分を書き換えたか？という細かい情報を保存するバージョン管理システムの方が機能的に洗練されているのです。
[蛇足2]
リモートリポジトリからローカルリポジトリにデータを落としてくることを何といいますか？
gitから触った人は “clone“(クローン) という人が多いでしょう。
しかしgitより前では、これを “checkout” と言いました。
「checkoutって言ったら、ブランチを切り替えることじゃん！」と思いますよね。
調べては見たのですが理由はよくわかりませんでした。gitがそうしたんだから仕方ないとしか僕は思っています…。
[補足1]
自動テストはツールありました。
