リポジトリ
コミットをためていく場所のことです。
コミットとは？
ユーザーが任意のタイミングでソースコードの記録を保存すること。
リポジトリの種類
ローカルリポジトリ
ローカルのPCの自分専用のリポジトリでここで各人が作業をしていきます。適宜リモートリポジトリへ作業結果を反映させます。
リモートリポジトリ
GitHub等を使って作ることができるインターネット上のリポジトリのことです。サーバーを構築してそれをリモートリポジトリとすることも可能です。
リモートリポジトリやローカルリポジトリを用意する方法
リポジトリを用意する方法は二つあります。
- すでにプロジェクトがある場合は、リモートリポジトリをコピー（クローン）してローカルリポジトリとして使う。
- 新規でプロジェクトを立ち上げる場合はリモートリポジトリやローカルリポジトリを新規作成する。(git initコマンド）
クローン
リモートリポジトリを、ローカル（自分のパソコン）にダウンロードすることです。
クローンの具体的なやり方は下記の記事でも解説しています。
ローカルリポジトリの管理対象
個人的な作業はローカルリポジトリで実施していきますが、まずはGitでの管理対象のフォルダを決めます。（そこに隠しフォルダ.gitというのが作られて管理対象フォルダとして認識されることになります。）
ローカルリポジトリ管理対象フォルダの構成要素
さらにローカルリポジトリのフォルダは下記3つの構成要素に分かれます。
- ワークツリー（作業ツリー）
- ステージングエリア
- Gitディレクトリ（リポジトリ）
ワークツリー（作業ツリー）
ローカルで変更するファイルを保持する領域です。
ワークツリー内ではさらに四つの状態に分けてファイルは保持されます。
| 状態 | 説明 |
|---|---|
| untracked | 新規作成されたファイルがこの状態になります。「追跡されていない。」という意味です。
実際は、まだワークツリーの管理下にはない状態になります。 |
| unmodified | ファイルに手を加えていない状態です。「変更されていない。」という意味になります。
ワークツリーの管理下に該当します。 |
| modified | 何らかの手を加えた状態です。「変更済み」という意味で、ワークツリーの管理下にあたります |
| deleted | ファイルが削除された状態を示します。 |
ステージングエリア
コミットする変更を準備する場所のことです。ワークツリーで編集を行ったファイル（modified）や新規作成したいファイル（untracked）をステージングエリアに登録します。登録を行った後はファイルの状態は「staged(ステージングエリアに追加済み)」という状態に変わります。
なぜステージングエリアが存在するのか？
手元には作業をしていると変更が完了した分としていない分で分かれると思いますが、変更を完了した分だけコミットしてスナップショットに記録しておきたいという要望に応えるためです。
Gitディレクトリ（「リポジトリ」とも呼びます。）
コミットを行うと変更がスナップショットに記録されて、それ以降は変更が入らないファイルとしてGitディレクトリに格納されます。
コミット後はファイルの状態は再び「unmodified(変更されていない)」に戻ります。
Gitのファイル管理方法
Gitは変更履歴をデータを圧縮してスナップショットとして記録しています。
スナップショットで保存する際のメリット
複数人で開発する際のスピードを向上させることができます。差分で持つ場合に比べたらマージやブランチを切るという動作の速度がファイルの中身をいちいち見なくて良い分大幅に向上します。Git以前のバージョン管理システムだとブランチを切るのに数十秒かかることがザラにありました。
gitのデータ管理の仕組み
「git add」と「git commit」コマンドにより「圧縮ファイル」、「ツリー」、「コミット」の三つの情報がローカルリポジトリ内に作成されることになります。具体的にそれぞれのコマンドで起きていることは下記になります。
git addコマンド（ステージングに追加する）際に起きていること
- ワークツリー内の作業したファイルはリポジトリに圧縮して格納されます。
- ステージングエリア内で【「1.」で作成した圧縮ファイル】と【実ファイル】を示す情報のインデックス（マッピング）を作成して保管します。（インデックス情報は新しくファイルをステージングに追加しても増えません。）
圧縮ファイル
Gitのスナップショットの仕組みそのものが反映されています。ファイルの中身が変更されたファイルだけ新しく作られます。変更されなかったファイルからは圧縮ファイルは作られません。
git commitコマンド（スナップショットとして作業履歴を保存する）際に起きていること
下記のように「ツリー」と「コミット」をローカルのリポジトリに作成します。
- git addコマンドでインデックス情報を作成した際にそのインデックスのファイル構成をツリーとしてリポジトリに保管します。
- 「1.」で作成したツリーに対応するコミット（作成者やコミットメッセージ等）をリポジトリに作成します。
2度目以降のコミット時
「直前（2度目であれば1度目）のコミット情報」を「親コミット情報」としてコミットに保管します。直前のコミット情報を保持しておけば連鎖してコミットを辿れるようになるのでこれによって変更履歴を辿れるようにしています。
コミット後のデータ構造
コミット後は下記のようにデータが保持されています。
ステージングエリア
- 作業の圧縮ファイルをさす「インデックス」
リポジトリ
下記ファイルは「Gitオブジェクト」といって「.git/objects」配下に作成されます。
- 作業圧縮ファイル
- ツリー（ファイルを追加するたびに増えていきます。）
- コミット（ファイルを追加するたびに増えていきます。2度以降のコミット時は「親コミット情報」を保持します。）
「インデックス」と「ツリー」が分かれている理由
基本的にインデックスとツリーの情報は同じ情報になります。ただ分かれている理由としては基本的には「git add」は作業が完了していない情報も保持しておき「git add」して新しいファイルを追加するたびにインデックスを上書きするので容量は食わないですし、仮に何度もワークツリー内でファイルの追加や削除を行ったとしても無駄なファイルで容量を食ってしまうことがありません。
逆に「git commit」はスナップショットとしてツリーという領域を新しく作成することになるので領域を食うことになりますのでファイルの追加削除のない作業の区切りに行うようにしましょう。
コミットメッセージの書き方
基本方針
誰が見てもわかるようなわかりやすいメッセージを記述します。
簡単に記述する場合
下記内容を一行で記述します。ルールがそこまで厳格ではないプロジェクトで開発する場合はこちらで十分でしょう。
- 変更内容の要点
- 変更の理由
正式に記述する場合
下記のように記述します。
|
1 2 3 |
1行目：変更内容の要約 2行目：空行 3行目：変更した理由 |
正式というのは例えば、「オープンソースのプロダクトにコミットする場合」や「ルールを厳格に決めて開発するプロジェクト」の場合はこちらの書き方を参考に記述する場合が多いでしょう。
タグとは？
コミットを参照しやすくするためにわかりやすく名前をつけるために使います。
タグのメリット
- 名前的にわかりやすいのでバグが発生した際の切り戻しの際にわかりやすい。
- いつ何が変更されたかが後で見たときのわかりやすい。
用途
リリースポイントに付けます。
タグの種類
タグには2種類あります。
注釈付き(annotated)
しっかりと情報が付いたタグです。基本的にはこちらを使います。
軽量版(lightweight)
情報量を減らした軽量版のタグです。
タグを作成するコマンド
注釈付きタグを作成
-aオプションが注釈付きタグを作成するという意味になります。
|
1 |
git tag -a [タグ名] -m "メッセージ" |
軽量版のタグを作成
|
1 |
git tag [タグ名] |
特定のコミットに対して後からタグを設定する。
|
1 |
git tag [タグ名] [コミットID] |
タグの一覧を表示するコマンド
アルファベット順にタグを表示します。
|
1 |
git tag -l [パターン] |
-l
パターンを絞り込んでタグを表示します。
タグの詳細を確認するコマンド
下記コマンドを実行するとタグと関連づけられたコミットを表示します。
|
1 |
git show [タグ名] |
タグをリモートリポジトリに送信する。
|
1 |
git push [リモート名] [タグ名] |
--tags
ローカルにあってリモートリポジトリに存在しないタグを一斉に送信することができます。
この記事へのコメントはありません。