バージョンコントロール(VCS)について

バージョンコントロールとは、ファイルの変更を繰り返し保存して、それを呼び戻したりするシステムです。一般的にはプログラミングのコードなどが記述されているファイルを扱う事が多いのですが、実はほとんどすべての種類のファイルを扱う事が出来ます。グラフィック関係やWeb系の仕事をしている人達は、2019年現在、ほぼほぼこのVCSを使っています。扱っているファイルに問題が発生した時、落ち着いて前のバージョンに戻ってみたり、何が問題なのかバージョンを比較して調べてみたり、あと誰がバグを発生させたのか調べたりする事で問題の解決を図るのです。あとバックアップにもなるので、ファイルが飛んだ時に復活出来たりします。

ローカルでのVCS

実はVCSを意識しなくても、普段パソコンを使っていると似たような事をしていたりします。ちょっとずつ更新していく系のExcelファイルを扱っている時に、上書き保存せずに「名前をつけてファイルを保存」する事で取り返しのつかないミスを防ぐっていうのはよく聞くパソコンあるあるです。僕はやらないのですが、物書きの人は初稿を修正する際に第２稿ー第３稿と別々に保存していくやり方をする人も多いと思います。

そんなシンプルなやり方でも十分と思う人もいるでしょうが、「どこのフォルダにまとめて保存しているか忘れた」とか「まちがってCommand+S押しちゃった」とか、そうゆうエラーが多いのもまた事実。

プログラマーの人達は長い間、「なーんか上手いやり方ないかなー」って考えてきたのです。

CVCSs

問題はまだあって、チームで作業している時は特に「なーんか上手いやり方ないかなー」って多くのプログラマーが考えていたのです。勝手に更新かける奴、みんなで同じディレクトリに保存しようって言ってるのに独自にフォルダを作り始める奴、他の人が作業している最中にファイルを開く奴などなど、ルールを明確に決めておいても、自分の都合の良いように作業工程を決めだす奴がたくさんいたのです。（あーなんか前職の会社思い出してきた）

まーそれでも複数人で作業しなくちゃいけないケースは多くて、大抵の場合共用のサーバーを使って行うんですが、そうゆうVCSをCVCSs(Centralized Version Control System)って呼んだりします。サーバーが１台あって、複数のクライアントがそこにアクセスするっていう、そうゆう形です。

身勝手なクライアントに管理者がブチ切れたりする事はしょっちゅうだったのですが、（１）チームで作業出来ると何かと便利（２）各自がローカルで管理するよりは遥かに楽っていう理由から、このCVCSsは長い間制作現場でスタンダードな形として使われてきたのです。

↑で紹介したローカルVCSとCVCSですが、この２つは最も大きな問題をはらんでいます。それは「データが消えたら世界の終わり」というケースです。ローカルの場合はパソコンがぶっ壊れたら終了ですし、CVCSもサーバーが停電とかで止まっている間は全員の作業が止まってしまいます。バックアップ取ってればいいんですが、そもそもバックアップの為にVCS入れてるのに更にそのバックアップを取るとか、なんかアホらしくないですか？（もちろん多くの企業はそうしていた）

DVCS

そこで登場したのがDistributed Version Control Systemってやつで、Gitはこれにあたります。サーバーはもちろん、各クライアントも、現状データ及び変更履歴を全部保存するっていう方式です。これならサーバーが爆発しても大丈夫。更にこの方式によって、現代的なワークフロー（スタートアップとかがやってるやつ）が実現するのです。