[GitBucketで学ぶバージョン管理] #01 - バージョン管理とは

皆さん、バージョン管理してますか？

恐らくそう言った呼び方ではないにせよ、普段の生活において自然としていると思います。

例えば、お仕事でドキュメントをつくるとしたら。ビラをつくるとしたら。あるいは書類の用紙をつくるとしたら。

そういうとき、変更が入るときにはその時に最新だったファイルに日付やバージョン番号なりをつけてコピーを保存していると思います。

そう、それがバージョン管理です。

バージョン管理

さて、こうした時に最新のものが手元にあったよ！としますが、実は同僚が既に手元の最新に手を加えて、さらなる最新のファイルを持っていたとしたら。

あるいは、非常によく似た内容だけど最後に更新した担当が違うかもしれなくてどちらが本当の最新なのか？に迷ったりしたことはないでしょうか。

バージョン管理は以下をマネジメントすることを目的とした行為です。

• いつ更新されたか
  
• だれに更新されたか
  
• 何を更新されたか
  
• どの箇所を更新されたか
  
• なぜ更新されたか
  

そして、これらの内容と現物をひとまとめにしたものに名前をつけたりしますよね。

◯◯で出版したもの、とか5/12に◯◯で配布したものとか。

こういったことをするために、昔から様々な施策がとられてきました。

バージョン管理しないとどうなるか

もちろん、おかしなことが起きることがあります。

例えば、加えていたはずの変更が元に戻ってしまっていたり、あるはずのものが無かったり。更新すべきでないものが変更されていたり。

これはかなりマズイですね。

設計図がそのまま製品になるコンピュータソフトウェアにおいては死活問題で、こうした最新をマネジメントするためのツールが開発されてきました。

やり方としては、最新のファイルだけを管理するというものや、管理者を置いて現物と台帳を組み合わせて管理したり。

あるいは、台帳の中に現物そのものも突っ込んでしまうなんてのもあります。

拡がる活用シーン

いままではコンピュータソフトウェアの開発において重要視されてきたバージョン管理の分野ですが、変化のスピードが速く、必要となる事柄がどんどん変化していく昨今ではコンピュータソフトウェアの開発以外の分野においても必要不可欠なものになりつつあります。

例えば、書式などのテンプレートが法令の変更に伴って細かに変更されていったりすると、どのファイルがいつの時点の最新なのかを管理しておく必要があります。

なぜバージョン管理システムが必要なのか

もちろんバージョン管理は棚や金庫、ラックなどで物理的に管理することができますし、電子メディアであればラベルでメディアごと管理することもできます。

電子ファイルであれば、フォルダ分けやサーバー、ドライブによる管理もできますよね。

ではなぜバージョン管理のために先人はシステムをつくったのでしょうか？

最初はソフトウェアを開発していた開発者たちも、我々と同じようにフォルダなどでファイルを管理していました。

同じ名前ではじまるファイルで、少しだけファイル名が異なるもののテキスト比較をして、「ここがこう違う」ということで違いを確認して管理してきました。

また、どのファイルがだれのもので、いつ更新されたか、最新はどれなのか？こうしたことを管理するためにファイルシステムはあります。

その後、コンピュータシステムへアクセスする仮想のユーザー（アカウント）にファイルやフォルダへのアクセス権だけでなく、リアルの職位などをリンクするようになりました。

ファイルやフォルダにアクセス権を設定して、このフォルダは課長以上しかアクセスできない、とかそういったことがありますよね。しかし課長以上といえども、簡単に更新されては困るものもあるのではないでしょうか？

そういうことがあって、マネジメントを行う担当がアサインされ、中央集権型のバージョン管理がなされるようになりました。

こうすることで、アクセスは適切な権限によって可能ですが、そこへのドキュメントの保存は管理者だけができる、という形をとるようになりました。

一見、うまくいくような気がしますが、これではドキュメントの更新に時間がかかるようになります。そして担当をアサインするための費用もかかりますし、担当はその仕事に選任するようになります。

つまり、ヒト、モノ、カネのすべてを費やすことになるのです。

分散管理

こうした経緯から誕生したのが分散バージョン管理です。

それぞれが中央と同じバージョン管理データベースを手元に持ち、すばやく更新することができます。そして選任の管理者が不要になるので各自でデータベースを管理することができます。

なおかつ、それぞれが中央と同じデータベースを持つということは、バックアップを各自が持っているということになります。それは中央のデータベースが破損した、紛失した場合でもだれかのPCにあるデータベースから復元することができるということでもあります。

なお、分散管理であってもいいことづくめではありません。もちろんデメリットも発生します。手元で最新化したものをチームでレビューし、中央のデータベースへ戻すようにするワークフローがなくては各自がそれぞれに文書を公開してしまうということになりかねません。

ですから、集中管理と分散管理をうまく組み合わせていく必要があります。

最後に

本講座では、分散バージョン管理システムとして代表的なツールである「Git（ぎっと）」を利用します。

また、手軽に手元でGitによる集中管理を行うツールとして「GitBucket」を利用します。

これらについては次回詳しくお話しします。