Making Your First Commit

You have initialized a repository, created some files, and seen how the staging area works. Now you will create your first commit — a permanent snapshot of your staged files saved into the repository’s history.

Staging files

Before you commit, you need to stage the files you want to include. From your git-practice folder, stage both files:

git add pine-ridge.txt summit-challenge.txt

Or stage everything in the current directory at once:

git add .

The . means “everything in the current directory and below.” It is convenient but use it carefully — you generally want to know what you are committing rather than blindly staging everything.

Run git status to confirm both files are staged:

On branch main

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
  new file:   pine-ridge.txt
  new file:   summit-challenge.txt

Creating a commit

Commit the staged files with a message:

git commit -m "Add initial tour notes"

Output:

[main (root-commit) a3f8c12] Add initial tour notes
 2 files changed, 2 insertions(+)
 create mode 100644 pine-ridge.txt
 create mode 100644 summit-challenge.txt

The commit is created. Let’s unpack what the output tells you:

main — the branch you committed to
(root-commit) — this is the first commit in the repository
a3f8c12 — the first seven characters of the commit’s unique hash (yours will be different)
Add initial tour notes — your commit message
2 files changed, 2 insertions(+) — a summary of what changed

What a commit actually is

A commit is a snapshot of all the staged files at the moment of the commit, not a record of what changed. Git stores the complete state of every tracked file. When you look at history later, Git computes the differences between snapshots to show you what changed — but the underlying storage is snapshots, not diffs.

Every commit has:

A unique hash — a 40-character string like a3f8c12d4e9f... generated from the commit’s content. No two commits in history will ever have the same hash. The short form (first 7 characters) is used in output and everyday conversation.
The tree — the complete state of every tracked file at that moment
The parent — a pointer to the previous commit (except the root commit, which has none)
The author and date — from your git config settings
The commit message

This chain of parent pointers — each commit pointing to the one before it — is what forms the commit history.

Verifying the commit

Run git status after committing:

On branch main
nothing to commit, working tree clean

“Working tree clean” means your working tree matches the latest commit exactly. There are no untracked files, no staged changes, no unstaged changes.

Run git log to see the commit in history:

git log

commit a3f8c12d4e9f... (HEAD -> main)
Author: Your Name <you@example.com>
Date:   Wed May 27 10:00:00 2026 -0700

    Add initial tour notes

HEAD -> main means HEAD (your current position in history) points to the latest commit on the main branch. You will see this notation throughout the course.

The commit workflow

Every time you want to save a snapshot of your work, you follow the same two-step process:

git add <files>      # stage what you want to commit
git commit -m "..."  # save the snapshot with a message

Repeat this as you work. Each commit is a checkpoint you can return to, compare against, or share with others.

Exercise

In your git-practice folder, stage your files and create your first commit:

git add .
git commit -m "Add initial tour notes"

Run git status after the commit and confirm you see “working tree clean.”
Run git log to see your commit. Note the hash, author, date, and message.
Edit pine-ridge.txt — add a second line with any text. Run git status and observe that the file now shows as modified.
Stage and commit the change:

git add pine-ridge.txt
git commit -m "Update Pine Ridge notes"

Run git log again. You now have two commits in history, each with its own hash. The most recent is on top.

Recap

git add <file> stages a file. git add . stages everything in the current directory.
git commit -m "message" creates a snapshot of everything in the staging area with the given message.
Every commit has a unique hash, a pointer to its parent, author information, and a message.
A commit stores a snapshot of all tracked files, not just the changes. Git computes diffs from snapshots on demand.
After a commit, git status reports “working tree clean.”
git log shows the history of commits on the current branch.

Module 01 is complete. The next module goes deeper into the tools for reading and understanding your repository’s state — git status, git diff, and git log — and covers how to write commit messages that actually communicate what you did and why.