1.3 はじめに - Gitとは何か？

Gitと他のVCS（Subversionなどを含む）との主な違いは、Gitがデータを考える方法にあります。概念的に、他のほとんどのシステムは情報をファイルベースの変更のリストとして保存します。これらの他のシステム（CVS、Subversion、Perforceなど）は、保存する情報をファイルのセットと、時間の経過とともに各ファイルに加えられた変更として考えます（これは一般的に差分ベースのバージョン管理と呼ばれます）。

Gitはデータをこのように考えたり保存したりしません。その代わりに、Gitはデータをミニチュアファイルシステムの連続するスナップショットのように考えます。Gitでは、コミットするたびに、つまりプロジェクトの状態を保存するたびに、Gitは基本的にその時点のすべてのファイルの様子を写真に撮り、そのスナップショットへの参照を保存します。効率化のために、ファイルが変更されていない場合、Gitはファイルを再度保存せず、既に保存されている同じファイルへのリンクを保持します。Gitはデータをまるでスナップショットのストリームのように考えます。

これはGitと他のほとんどすべてのVCSとの重要な区別です。これにより、Gitは他のほとんどのシステムが前世代からコピーしてきたバージョン管理のほぼすべての側面を再検討しています。これにより、Gitは単なるVCSというよりも、その上にいくつかの非常に強力なツールが構築されたミニファイルシステムのようなものになっています。データをこのように考えることによって得られる利点のいくつかについては、GitブランチでGitのブランチ機能について説明する際に詳しく見ていきます。

Gitでのほとんどの操作は、ローカルファイルとリソースのみを必要とします。通常、ネットワーク上の他のコンピューターからの情報は不要です。ほとんどの操作にネットワーク遅延のオーバーヘッドがあるCVCSに慣れている場合、Gitのこの側面は、速度の神々がGitに超常的な力を与えたかのように思わせるでしょう。プロジェクトの完全な履歴がローカルディスクにすべてあるため、ほとんどの操作はほぼ瞬時に行われます。

たとえば、プロジェクトの履歴を閲覧する場合、Gitは履歴を取得して表示するためにサーバーにアクセスする必要はありません。単にローカルデータベースから直接読み込みます。これにより、プロジェクト履歴をほぼ瞬時に確認できます。現在のファイルのバージョンと1ヶ月前のファイルの間の変更点を見たい場合、Gitは1ヶ月前のファイルを検索し、ローカルで差分計算を行うことができます。リモートサーバーにそれを依頼したり、古いバージョンのファイルをリモートサーバーからプルしてローカルで行ったりする必要はありません。

これはまた、オフラインまたはVPNから切断されている場合でも、できないことがほとんどないことを意味します。飛行機や電車に乗っていて少し作業をしたい場合、ネットワーク接続でアップロードできるようになるまで、喜んでコミットできます（ローカルコピーに対して、ということを覚えておいてください）。家に帰ってVPNクライアントがうまく動作しない場合でも、作業を続けることができます。他の多くのシステムでは、そうすることは不可能か、苦痛を伴います。たとえばPerforceでは、サーバーに接続していないとほとんど何もできません。SubversionやCVSではファイルを編集できますが、データベースに変更をコミットすることはできません（データベースがオフラインだからです）。これは大したことではないように思えるかもしれませんが、その違いがいかに大きいかに驚くかもしれません。

Git内のすべてのものは、保存される前にチェックサムが計算され、そのチェックサムによって参照されます。これは、Gitが知ることなくファイルやディレクトリの内容を変更することが不可能であることを意味します。この機能はGitの最も低いレベルに組み込まれており、その哲学に不可欠なものです。転送中に情報が失われたり、ファイルが破損したりしても、Gitがそれを検出できないということはありません。

Gitがこのチェックサムのために使用するメカニズムは、SHA-1ハッシュと呼ばれます。これは16進数文字（0–9とa–f）で構成される40文字の文字列で、Git内のファイルまたはディレクトリ構造の内容に基づいて計算されます。SHA-1ハッシュは次のようになります。

これらのハッシュ値はGitのいたるところで目にするでしょう。なぜなら、Gitがそれらを非常に多用するからです。実際、Gitはデータベースにすべてをファイル名ではなく、その内容のハッシュ値によって保存します。

Gitで操作を行うとき、そのほとんどすべてはGitデータベースにデータを追加するだけです。システムに元に戻せない操作をさせたり、データを消去させたりすることは困難です。他のVCSと同様に、まだコミットしていない変更を失ったり、台無しにしたりすることはありますが、スナップショットをGitにコミットした後でそれを失うことは非常に困難です。特に、定期的にデータベースを別のリポジトリにプッシュしていればなおさらです。

このため、Gitを使うことは喜びです。なぜなら、物事をひどく台無しにする危険なしに実験できるとわかっているからです。Gitがデータをどのように保存し、失われたように見えるデータをどのように回復できるかについて、より深く掘り下げるには、変更の取り消しを参照してください。

さて、今から注意してください。残りの学習プロセスをスムーズに進めたいのであれば、Gitについて覚えておくべき主な点がここにあります。Gitには、ファイルが存在し得る3つの主要な状態があります。それらは、変更済み (modified)、ステージ済み (staged)、そしてコミット済み (committed)です。

これにより、Gitプロジェクトの3つの主要なセクションにたどり着きます。それは、ワーキングツリー、ステージングエリア、そしてGitディレクトリです。

ワーキングツリーは、プロジェクトの特定のバージョンの単一のチェックアウトです。これらのファイルはGitディレクトリ内の圧縮されたデータベースから取り出され、使用または変更のためにディスク上に配置されます。

ステージングエリアは、通常Gitディレクトリ内に含まれるファイルで、次のコミットに含まれる情報が格納されます。Gitの専門用語での技術的な名前は「インデックス」ですが、「ステージングエリア」という表現も同様によく使われます。

Gitディレクトリは、Gitがプロジェクトのメタデータとオブジェクトデータベースを保存する場所です。これはGitの最も重要な部分であり、別のコンピューターからリポジトリをクローンする際にコピーされるものです。

基本的なGitのワークフローは次のようになります。

特定のバージョンのファイルがGitディレクトリにある場合、それはコミット済み (committed) とみなされます。ファイルが変更され、ステージングエリアに追加された場合、それはステージ済み (staged) です。そして、チェックアウトされてから変更されたものの、まだステージングされていない場合、それは変更済み (modified) です。Gitの基本では、これらの状態について詳しく学び、それらを活用する方法や、ステージングを完全にスキップする方法についても学びます。