はじめに
これまでの実験では、「Time Machine」（Git リポジトリ）を初期化し、最初のスナップショットを保存する方法を学びました。しかし、プロジェクトは静的なものではありません。バグを修正したり、機能を追加したり、ドキュメントを更新したりしながら変化していきます。
Git はこの変化を追跡することを得意としています。Git を使うと、次のことができます。
- 変更を確認する：保存する前に、どの行を変更したのかを正確に確認できます。
- 履歴を確認する：これまでに保存したすべてのスナップショットを振り返り、誰が、いつ、何を変更したのかを確認できます。
これがバージョン管理の本当の価値です。単にバックアップを保存するだけでなく、プロジェクトが時間とともにどのように変化したかを、整理された履歴として残せます。
この実験では、ファイルを変更し、git diff で正確な差分を確認し、新しいスナップショットを保存した後、git log でプロジェクトの履歴を確認します。これは、実際の Git ワークフローで常に使われる基本的な確認サイクルです。
プロジェクトファイルを変更する
この実験では、すでに 1 つのコミット（「Initial commit」）があるリポジトリを使用します。このプロジェクトで作業する状況を再現してみましょう。
プロジェクトディレクトリに移動します。
cd /home/labex/project
readme.txt の現在の内容を確認します。
cat readme.txt
次の内容が表示されます。
Hello World
新しい行を追加してファイルを変更します。ここでは、簡単な説明を追加します。
echo "Git is a version control system" >> readme.txt
ファイルが変更されたことを確認します。
cat readme.txt
出力：
Hello World
Git is a version control system
Git は、readme.txt が最後のスナップショットに保存されているバージョンと異なることを検出しました。これで、ファイルは Modified と見なされます。
Git Diff で変更を確認する
作業を保存する前に、何を変更したのかを正確に確認することは、よい習慣です。これは、エッセイを提出する前に校正するのと同じです。
Git には、この目的のために diff コマンドがあります。このコマンドは、作業ディレクトリにあるファイルと、最後のコミット（スナップショット）に保存されているファイルを比較します。
つまり、git diff は、履歴に保存されている状態と、現在の作業ツリーに存在する状態を比較します。変更を恒久的に記録する前に作業内容を確認するための、Git の主要なツールの 1 つです。
git diff を実行して変更内容を確認します。
git diff
出力を確認します。
diff --git a/readme.txt b/readme.txt
index ...
--- a/readme.txt
+++ b/readme.txt
@@ -1 +1,2 @@
Hello World
+Git is a version control system
--- a/readme.txt：元のバージョン（Old）です。+++ b/readme.txt：現在のバージョン（New）です。+Git is...：プラス記号（+）は、新しく追加された行を示します。マイナス記号（-）は、削除された行を示します。
diff の出力を読み取ることは、Git の基本的なスキルです。変更内容を行単位で確認できるためです。コードレビュー、パッチの適用、プルリクエストなど、その後の多くのワークフローも同じ考え方に基づいています。
このステップでは、変更内容が意図したとおりであることを確認しました。
Git Commit で変更を保存する
変更内容を確認できたので、新しいスナップショットを保存します。2 段階の手順を思い出してください。Stage（Loading Dock に置く）してから、Commit（スナップショットを撮る）します。
まず、ステータスを確認します。
git status
「Changes not staged for commit」の下に、readme.txt が赤色で表示されます。
ファイルを Stage します。
git add readme.txt
もう一度ステータスを確認します。
git status
今度は、「Changes to be committed」の下に readme.txt が緑色で表示されます。
これは、変更済みの内容とステージング済みの内容を Git が分けて管理していることを示す例です。変更内容がファイルに存在していても、ステージングするまでは次のコミット候補には含まれません。
明確なメッセージを付けてスナップショットを Commit します。
git commit -m "Add description about Git"
-m：コミットメッセージをその場で指定できます。- メッセージには、何を変更したのか が分かる内容を記述します。
これで、プロジェクトの履歴に 2 つ目のバージョンが保存されました。
プロジェクトの履歴を確認する
これで、リポジトリには 2 つのコミットがあります。プロジェクトの時間的な流れを確認するには、git log コマンドを使用します。これはプロジェクトの「履歴書」です。
完全なログを表示します。
git log
出力を確認します。
commit 8d3a1b2... (SHA Hash)
Author: Your Name <you@example.com>
Date: Mon Oct 10 10:00:00 2023 +0000
Add description about Git
commit 4f2b3c4... (SHA Hash)
Author: Your Name <you@example.com>
Date: Mon Oct 10 09:00:00 2023 +0000
Initial commit
- SHA Hash：長い ID 文字列（例：
8d3a...）です。特定のスナップショットを識別する一意の指紋です。 - HEAD：表示されている場合は、現在の位置を示すポインターです。
- 順序：最も新しいコミットが常に一番上に表示されます。
これらのハッシュは、Git が履歴を識別するうえで重要です。コミットに連続した番号を付ける代わりに、Git は内容に基づく識別子を使用するため、各スナップショットを一意に参照できます。
必要に応じて、q を押すとログ表示を終了できます。
簡潔な履歴を確認する
数か月にわたってプロジェクトを作業すると、完全な git log は長くなり、詳細すぎる場合があります。簡単な一覧だけを確認したいこともあります。
Git には、この目的のために --oneline フラグがあります。
簡潔なログを表示します。
git log --oneline
出力を確認します。
8d3a1b2 Add description about Git
4f2b3c4 Initial commit
この表示では、Short Hash と Commit Message だけが 1 行ずつ表示されます。最近何が行われたのかをすばやく確認するのに適しています。
チャレンジ：
readme.txt をもう一度変更してみてください。新しい行を追加してコミットし、その後、もう一度 git log --oneline を確認します。3 件のエントリが表示されるはずです。
まとめ
この実験では、プロジェクトの変更を管理する一連の流れを学びました。
- Modify：ファイルを変更しました。
- Inspect：
git diffを使って変更内容を確認しました。 - Commit：
git addとgit commitを使って、恒久的なスナップショットを保存しました。 - Review：
git logとgit log --onelineを使って、プロジェクトの時間的な流れを確認しました。
この 4 つのコマンドは、Git を日常的に使ううえで中心となるものです。これらを身につければ、バージョン管理の基本を習得できます。
