1. はじめに
当記事は全5回（+α）からなる Git入門シリーズ の第1回です。
今回は そもそもGitとは何なのか ということについて説明します。
2. Gitとは？
Git は2005年12月21日に発表された VCS です。「ギット」と読みます。 「ジット」だと思ってた。
開発元は、Linuxの生みの親であるLinus Benedict Torvalds氏と、Linuxコミュニティです。元々Linuxコミュニティでは、Linuxのソースコードの管理にBitKeeperというVCSを使用していました。ただ、様々な事情からBitKeeperの使用をやめることになり、その際BitKeeperの代替となるVCSを探したのですが、満足できるものが無かったため、新たにGitが開発されました。
3. VCSとは？
VCS (Version Control System) は バージョン管理 を支援するアプリの総称です。もちろん、バージョン管理ができるならば、アプリでなくとも（Webサービスなどであったとしても）VCSたりうると思うのですが、主要なVCSは全てアプリという形を採っています。
Git以外のVCSには――
- 世界初のVCSである SCCS (Source Code Control System)
- 世界で2番目のVCSであり、今なお一部では現役と聞く RCS (Revision Control System)
- クライアントサーバー型VCSの祖として広く普及した CVS (Concurrent Versions System)
- CVSの改良型のように語られることが多い SVN (Apache Subversion)
- Gitのライヴァル Mercurial
- 悪評高き VSS (Microsoft Visual SourceSafe)
- VSSの汚名返上に成功した（？） TFS (Team Foundation Server)
――などがあります。
4. バージョン管理とは？
私が調べたかぎりでは厳密な定義はないようです。バージョン管理（version control）という呼び方すら絶対ではなく――
- software configuration management
- SCCM (Software Change and Configuration Management)
- source configuration management
- revision control
- source control
――といった色々な呼称が使われているようです。
ただ、それでは話が進まないので、私個人の解釈を申し上げますと、バージョン管理とは ある成果物の状態の変遷を、特定の法則に基づいて記録・管理する手法および概念 ということになるでしょう。
プログラムの改修作業（変更作業）は常に成功するわけではありません。時には、変更を加えたことで新たなバグが生じたり、余計なところにまで手を付けてしまったり、そもそも変更内容自体が適切でなかったりします。そんなとき、変更前の状態が残っているのと残っていないのとでは、その後の対応状況・対応方法・対応難易度が変わってきます。言わずもがな、変更前の状態が残っているほうが対応が容易になります。
また、各状態を残すにしても規則性が必要です。例えば、新しい状態になるごとに「ソースファイルの末尾の数字を増やしていく（v1、v2、v3）」とか「変更を加えた日付を付ける（20200101、20200103、20200201）」といったようにです。これを徹底しないと以下のように収拾が付かなくなります。
- main.ps1
- main_v2.ps1
- main_20200203.ps1
- main-200204.ps1
- 【最新版】main.ps1
- 【最新版】main.ps1_バグ修正済み
- main.ps1_本番環境
上記例だと7つのファイルがありますが、結局どれが最新版なのか分かりません。どのように変更が加えられてきたのかも読み取れません。これではバージョン管理ができているとは言えません。
5. バージョン管理するのにVCSって要るの？
バージョン管理を行うのにVCSは必須ではありません。
実際、電子式コンピューターの生産、およびプログラミング言語の利用は1940年代から始まりましたが、世界初のVCSであるSSCSが登場したのが1972年のことです。つまり、およそ30年近くにわたって、VCSを用いないバージョン管理が行われてきたわけです（バージョン管理が1940年代から存在していたという前提に立つ）。
ただ、VCSを用いないバージョン管理は往々にして、VCSを用いたバージョン管理よりも問題を生じさせます。各バージョンを区別する方法（概ねファイル名で区別しますが）で悩んだり、旧バージョン・現行バージョン・開発中バージョンの分け方・管理体制で悩んだり、メンバーのなかからバージョン管理を無視する人が出てきたり、プロジェクトが進むにつれて管理が煩雑になってきたり、と色々と苦労する羽目になるでしょう。
このようなエンジニア職の本質ではない仕事はVCSというツールに任せてしまえばよいのです。
6. Gitの評価
他のVCSと比較したGitの長所として、よく聞くのは――
- 動作が軽快
- 多機能
- 大規模開発に耐えうる
- 現状、VCSはGitかVSNのツートップ
- ブランチを積極的に切っていく開発フローに適する
- マージ処理が賢い
――などがあります。反対に、短所としては――
- 覚えなければならない概念・仕様が多い
- Gitコマンドの抽象化が足りておらず使いにくい
- VCSのなかで最も学習難易度が高い
――などです。
私個人の考えも含めた総評としては 多機能、かつ高性能。それでいて様々プロジェクトで使われてきた実績もある、最も優れたVCSの1つ。ただし、学習コストも相応に大きい といった感じでしょうか。
ちなみに、無料のアプリなので安心して使ってください。