同僚と一緒に文書を書いたことがある人なら、その辛さを知っているでしょう。誰かが最初に目を通し（document.doc）、それをみんなにメールで送る。次の人、3人目も同じように、それぞれファイル名にリビジョンを追加していく（documentu rev3.doc）。マネージャーはそれを見て気に入り、完了印をつける（documentu final.doc）...。Until the last minute changes appear (documentu finalu Aaron's changes, reviewu Bob, nowu reallyu final.doc).

ここで、このような変更が何十ものソースコード・ファイルに発生することを想像してみてください。この問題を解決するために、プログラマーはバージョン管理システム（VCS）を作ってきた。やや専門的な内容ですが、上級者にも役立つ内容です。今日はトップシステムのGitを使って、バージョン管理の基本を見てみましょう。

使用されているバージョンコントロールの概要

VCSの主な目的は、時間の経過に伴うファイルのバージョン（リビジョンとも呼ばれる）を把握することである。つまり、上記のような粗雑な手法に頼らないということです。これらのシステムでは、デフォルトでドキュメント.docにアクセスすると、最新バージョンを使用することになります。しかし、文書の履歴をさかのぼって過去のバージョンを取得することもできます。ドキュメントのバージョンを管理するために特別に作られたシステムは、ソフトウェア開発から始まり、より「主流」なアプリケーションにも進出している。

ソフトウェア開発におけるバージョン管理の変遷

バージョン管理アプリケーションは、もともとプログラマーが互いのコードを壊さないようにするために作られたものです。第一世代のシステムでは、ユーザーは他のエディターのためにファイルをロックすることしかできませんでしたが、Subversionなどの第二世代のシステムでは、中央リポジトリからプロジェクトを完全にチェックアウトすることができるようになりました。

このような第2世代のシステムがまだ広く使われている一方で、業界では第3世代のシステムへと移行しつつある。これらのシステムの最大の特徴は、分散型であること、つまり中央のリポジトリが存在しないことである。その代わり、各ユーザーはリポジトリの完全なコピー（以前のリビジョンをすべて含む）を自分自身で持ちます。しかし、どんな変更も（完全なリビジョンであっても）、彼が他のリポジトリに「プッシュ」するまでは「ローカル」なのです。その後、ユーザーはクローンを取り出して変更を加え、このプロセスを繰り返すことができます。

ノンプログラマーのための現在のバージョン管理

また、同じものを複数のバージョンでキャプチャできるのも、常連ユーザーにとっては共通の機能です。ローカルPCや使いやすいクラウドサービスを通じて安価なストレージにアクセスすることで、ユーザーはファイルの履歴を把握することができるようになったのです。汎用的なプログラムでは、さまざまな方法でこれを行うことができます。

オペレーティングシステムは、ファイルやフォルダーの履歴を取り込むことができます。これは、ファイルを保存するたびに自動的に、または定期的に行うことができます。デスクトップアプリケーションの中には、ファイルのバージョンやスナップショットをキャプチャすることができるものもあります。例えば、LibreOfficeには「保存バージョン」機能（下図）があり、複数のバージョンのドキュメントを1つのファイルに保存することができます。最後に、Google DriveやownCloudなどのWeb/クラウドアプリケーションは、過去のファイルやドキュメントの反復処理（Google Docsの場合は下の画像のように）をバックグラウンドで、またはあなたのエクスプレスコマンドで保存することも可能です。

なぜプログラミング中心のバージョン管理をするのか？

オペレーティングシステムやアプリケーションのレベルですでにすべてのオプションが存在するのに、なぜこのような面倒なプログラマーズツールをわざわざ使うのでしょうか？上記の方法には、以下のような欠点があります。

• オペレーティングシステムによっては、あなたがファイルに加えたすべての調整を新しいバージョンに保存します。これは不必要なストレージスペースを取るだけでなく、ファイルの特定の復元ポイントを決定することが困難な場合があります。
• また、これらのソリューションでは、ファイルを管理の基本単位として使用することができます。しかし、バージョン管理システムは通常、ディレクトリレベル（サブディレクトリを含む）で動作します。vcsは、いつ、どのファイルが変更されたかを正確に把握することを容易にします。
• また、多くの場合、同じソリューションで、イテレーションにタグを追加することもできません。これも同様に、ある時点で、テキストを上書きすることの素晴らしさに気づく前に、文書内で自分の道を見つけることが難しくなります。
• また、OSやアプリケーション（Wordなど）によるバージョン管理は、単一障害点（Single Point of Failure）を発生させます。つまり、ファイルそのものです（破損している場合は、過去のコピーにさよならを言うことになります）。オペレーティング・システムについては、あなたが責任感のあるユーザーで定期的にバックアップをとっていない限り、ハードディスクがそれにあたります。
• ウェブベースのサービスの性質上、古いバージョンがクラウド上にある可能性があります。例えば、LinuxでDropboxのファイルの履歴を見ようとすると（下図参照）、ウェブサイトにリダイレクトされます。

これらの問題のいずれか、あるいはすべてに不満が残る場合は、次のセクションでGitを使ってこれらの問題を解決してください。

git バージョン管理

以下の小項目では、非常に重要なプロジェクトである本記事について、これらのステップを一つずつ説明していきます。そのために、コマンドライン版のGitを使用することにします。ターミナルコマンドを知ることで、それに相当するGUIを簡単に見つけることができ、あらゆるプラットフォームで使用できるようになります。

1 git リポジトリのセットアップ

お使いのコンピュータに git がインストールされていない場合 (Mac や一部の Linux ディストリビューションも同様)、プロジェクトのダウンロードページから Windows 用のインストーラを入手するか、Linux では次のようなコマンド (お使いのディストリビューションに固有のもの) を使ってインストールすることができます。

sudo apt install git

次に必要なことは、git リポジトリを作成することです。これは、単にプロジェクトを格納するフォルダのことです。Gitのバージョン管理を利用するためには、このフォルダをリポジトリとして初期化する必要があります。これは、コマンドラインから次のコマンドを使用して行うことができます。

git init

完了すると、何も表示されないかもしれませんが、ファイルマネージャの「隠しファイルを表示」オプションを有効にすると、新しい.gitフォルダが表示されます（上図参照）。ここはgitが全ての情報を保持している場所なので、邪魔になることはありません。

2 1枚目のドキュメントを追加して送信

次に、プロジェクト内にいくつかのコンテンツ（ファイル）を作成します。ほとんどのプログラミングプロジェクトは、コード（テキスト）やグラフィック（バイナリ）などのアセットで構成されているため、これらのファイルはどのようなタイプでもかまいません。作成したら、プロジェクトディレクトリにいる間に、コマンドラインから次のように実行します。

git status

コミットメントの最初のステップは、新規または更新されたアイテムを「ステージング」することです。上の出力で、"unaged "な変更があることがわかるでしょうか。次のコマンドを使用すると、ディレクトリのすべての内容をステージングすることができます（再帰的に、つまりサブフォルダとそのファイルを含む）。

git -a .

a "フラグは「追加」を意味し、ピリオドはカレントディレクトリを指します。基本的に「すべてのファイルを私のコミットに追加してください」と表示されます。では、実際にコミットするために、次のように入力します。

git commit -m "WHOOP, my first commit!"

これで、再度ステータスを確認すると、何の変化も待っていないはずです。コミットそのものを見るには、グラフィカルモードでgit logを確認し、リストを一行に切り、読みやすくなるようにトリミングしてください。

git log --all --decorate --oneline --graph

これによって、最新のものを筆頭に、投稿のスケジュールが表示されます。

実験するブランチを作成する

作業中、特定の方向に進みたいが、うまくいくかどうかわからない場合があります。そのような場合は、次のコマンドでブランチを作成する必要があります。

git branch experiment1git checkout experiment1

2番目のコマンドは、「experiment1」ブランチに切り替わります。master "に置き換えることで切り替えが可能です。文章を書き始めたら、各ブランチの同じファイル間の違いに注意してください。まず、"experiment1" ブランチには、新しいテキストが含まれています。

この商品をオリジナルと比較する。

さて、しばらく作業して（新規投稿で終了）、思いつくのは "Lorem ipsum sorrow sitting amet...?" くらいでしょうか。それは何ですか？これはナンセンスなので、すぐにプロジェクトから削除すべきです。以下のコマンドでブランチを破棄することができます（強制削除は「-D」）。

git branch -D experiment1

今度は別のブランチを立ち上げ、スマートコンテンツ、およびの画像を追加します。

git branch experiment2git checkout experiment2 git add . git commit -m "More text, added images"

4変更点を整理する

最後に、現在のブランチの変更に満足したら、次のコマンドで "master" ブランチにマージします。この2つの間をあまり行き来しないようにすると、すべての新しい変更が適用され、新しいリビジョンが作成されます。コマンドラインから以下のコマンドを実行すると、それらをマージしてくれます。

git merge experiment2

これで、最新版の "master "と最新版の "experiment2 "を組み合わせた改訂版が出来上がりました。この時点で、（結局、実験は成功したのですが）以下の方法で取り除くことができます。

git branch -d experiment2

この場合、そのブランチで行われたすべてのインクリメンタルな変更のみが失われることに注意してください。

5安全な場所に押し出す

最後に、Gitは分散システムです。つまり、リポジトリの複数のコピーを持ち、それらを同期させることができます。例えば、サーバー上に新しいリポジトリを作成した場合、以下のコマンドでSSH接続することができます。

git init --bare

bare "フラグは、ファイルを直接変更できないため、一種の読み取り専用リポジトリに設定されます。そして、次のコマンドを使用して、ローカルリポジトリのリモートコピーとして設定することができます（最初のコマンドは、新しいローカルブランチがリモートで作成されることを保証します）。

git config push.default matchinggit remote add central ssh://[username]@[URL]/path/to/repository git push --set-upstream central master

gitによるバージョン管理およびバックアップのセットアップ

上記の設定により、簡単な手順でバージョン管理だけでなく、プロジェクトで行われたすべての作業のバックアップを保持することができます。

1. プロジェクトファイルを変更する。
2. git add. "を発行して、すべての変更をコミットに追加します。
3. git commit-m[メッセージ]」を発行し、ローカルリポジトリに変更をコミットします。
4. 定期的にリモートリポジトリに変更をコミットするために "git push" を発行します。
5. 別のマシンから「git clone ssh://[ユーザー名]@[URL]/path/to/repository」を発行し、次のようにします。

バージョン管理システムの利点に興味がありますか？それとも、開発用ではないバックアップ用のアプリケーションで十分なのでしょうか？下のコメント欄でご意見をお聞かせください。