Gitの基本
リポジトリとは
リポジトリはGitのバージョン管理の対象になるファイルの中身、ディレクトリ構造、更新履歴などが保存される場所です。 変更履歴とバックアップの保管場所のことだと思っていれば特に問題ありません。
Gitではこのリポジトリに蓄積された作業ディレクトリの状態を利用して差分を確認したり、過去の状態を復元したりしています。
ローカルリポジトリとリモートリポジトリ
基礎知識 でも説明しましたが、Gitは分散型バージョン管理システム （ DVCS ）ですので、サーバー上と作業をする各個人のパソコンそれぞれにリポジトリを持ちます。
このとき、サーバー上にあるリポジトリを リモートリポジトリ 、各個人のコンピュータにあるリポジトリを ローカルリポジトリ といいます。
Gitではリモートリポジトリとローカルリポジトリ間でリポジトリに蓄積した情報をやり取りして共同開発者間で変更履歴を共有します。このように各環境にリポジトリを作成することで、作業内容を他人と共有したり公開するためにリモートとローカルの情報をやり取りする時以外は、ほとんどの作業をローカルで完結できるという利点があります。
コミットとは
作業ディレクトリで追加・変更したファイルの中身、ディレクトリ構造をリポジトリに記録することを コミット といいます。
コミットを行うとリポジトリには作業ディレクトリの状態を記録したものが作成され、この作成されたものも コミット （またはリビジョン、バージョン）といいます。 「コミットするとコミットができる」←紛らわしいですね。
この図ではコミットをA～Dで表していますが、実際のコミットはコミットの内容から SHA-1 （シャーワン）という関数で生成された英数字40桁のユニークな値を持ちこの値で識別をされています。この値は ハッシュ や SHA-1ハッシュ またはそのまま SHA-1 と呼ばれます。
ブランチとは
ただし、このブランチの切り方は様々な流儀があるので共同開発者内でのルールに従ってください。代表的な流儀には「git-flow」や「GitHub Flow」というものがあります。
ざっくりとしたコミットの構造
Gitにおける履歴のファイルの管理方法について説明します。
注意
ここではわかりやすさを優先して割愛していますが、実際はコミットオブジェクトが直接ブロブを参照しているのではなく、コミットオブジェクトはツリーオブジェクトという管理ファイルのディレクトリの構造の情報を持つオブジェクトを参照し、ツリーオブジェクトがブロブを参照しています。 もう少し詳しい説明は コミットの図解 を御覧ください。
このような管理方法をとっているため、過去のバージョン（スナップショット）の復元、変更差分の表示を簡単に行えます。
Gitで管理しているプロジェクトの構造イメージ
solver-X というプロジェクトのフォルダをGitで管理していたとすると構造は以下の図のようになります。
プロジェクトの構造のイメージ
- リポジトリ
Gitで管理しているディレクトリ（
solver-X）には.gitというフォルダが生成される。この.gitはGitでの管理に必要な情報や作業ディレクトリのスナップショットが保存され、ここが実質 リポジトリ である。- 作業ディレクトリ
solver-Xの直下(.gitがある階層)が 作業ディレクトリ であり、ここでファイルを配置したり編集を行う。Gitは作業ディレクトリのスナップショットをリポジトリに保存したり、リポジトリに保存されているスナップショットを作業ディレクトリに書き出すことができる。- ステージングエリア
ステージングエリアは 用語 で詳しく解説するが、コミットの対象とするファイルをコミット前に登録する領域であり、実態は
.gitの中のindexというファイルである。
これがGitの基本であり大部分である。
ステージングエリアのイメージ
作業ディレクトリ内のファイルの状態
作業ディレクトリ内のファイルには大きく分けて「追跡されている」と「追跡されていない」の2つの状態があります。 また、「追跡されていない」は3つの状態に分かれます。 基本的にGitでのファイルの管理は直近のコミットの状況から変更が加えられ、変更されたファイルをステージングしてコミットすることの繰り返しです。
ファイルの状態のイメージ