History and Changes

Introduction

In the previous labs, you learned how to initialize a "Time Machine" (Git repository) and save your first snapshot. But a project isn't static—it evolves. You fix bugs, add features, and update documentation.

Git excels at tracking this evolution. It allows you to:

Inspect Changes: See exactly what lines you changed before you save them.
Review History: Look back at every snapshot you've ever saved to see who did what and when.

This is the real value of version control: not just keeping backups, but preserving a structured history of how a project changed over time.

In this lab, you will modify a file, inspect the exact differences with git diff, save a new snapshot, and then browse project history with git log. This is the basic review loop used constantly in real Git workflows.

Modify a Project File

We start with a repository that already has one commit (the "Initial commit"). Let's simulate doing some work on this project.

Navigate to the project directory:

cd /home/labex/project

Check the current content of readme.txt:

cat readme.txt

You should see: Hello World

Modify the file by appending a new line. We will add a simple description:

echo "Git is a version control system" >> readme.txt

Verify the file has changed:

cat readme.txt

Output:

Hello World
Git is a version control system

Git has noticed that readme.txt is different from the version stored in the last snapshot. The file is now considered Modified.

Inspect Changes with Git Diff

Before you save your work, it is a best practice to review exactly what you changed. This is like proofreading an essay before submitting it.

Git provides the diff command for this purpose. It compares the file in your working directory with the file in the last commit (snapshot).

So git diff is comparing two states: what is saved in history and what currently exists in your working tree. It is one of the main tools for reviewing work before you record it permanently.

Run git diff to see the changes:

git diff

Analyze the output:

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: The original version (Old).
+++ b/readme.txt: The current version (New).
+Git is...: The plus sign (+) indicates a newly added line. (A minus sign - would indicate a removed line).

Reading diff output is a core Git skill because it shows change at line level. Many later workflows such as code review, patching, and pull requests build on the same idea.

This step confirms that your changes are exactly what you intended.

Save Changes using Git Commit

Now that we have verified the changes, let's save a new snapshot. Remember the two-step process: Stage (put it on the Loading Dock) and Commit (take the Snapshot).

Check the status first:

git status

You will see readme.txt in red under "Changes not staged for commit".

Stage the file:

git add readme.txt

Check the status again:

git status

Now readme.txt is green, under "Changes to be committed".

This is another example of Git's separation between modified and staged content. A change can exist in your file, but until you stage it, it is not part of the next commit candidate.

Commit the snapshot with a clear message:

git commit -m "Add description about Git"

-m: Allows you to write the commit message immediately.
The message should identify what you changed.

You have now saved the second version of your project history!

View Project History

You now have two commits in your repository. To see the timeline of your project, use the git log command. This is your "History Book."

View the full log:

git log

Examine the output:

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: The long ID string (e.g., 8d3a...). It is a unique fingerprint for that specific snapshot.
HEAD: (If visible) A pointer showing where you currently are.
Order: The newest commit is always at the top.

Those hashes are central to how Git identifies history. Instead of naming commits with sequential numbers, Git uses content-based identifiers so each snapshot has a unique reference.

(Press q to exit the log view if necessary).

View Condensed History

As you work on a project for months, the full git log can become too long and detailed. Sometimes you just want a quick summary list.

Git offers the --oneline flag for this purpose.

Run the condensed log command:

git log --oneline

Check the output:

8d3a1b2 Add description about Git
4f2b3c4 Initial commit

This view shows just the Short Hash and the Commit Message, one per line. It's perfect for quickly scanning what happened recently.

Challenge:

Try modifying the readme.txt one more time (add another line), commit it, and check git log --oneline again. You should see three entries!

Summary

In this lab, you learned how to manage the lifecycle of changes in a project:

Modify: You made changes to a file.
Inspect: You used git diff to verify those changes.
Commit: You saved a permanent snapshot using git add and git commit.
Review: You explored the timeline using git log and git log --oneline.

These four commands are the heartbeat of Git daily usage. Master them, and you master the basics of version control.