Chapter 3: Essential Git Commands: Add, Commit, Log, and Status

Introduction: Your First Steps into Git’s Core

Welcome back, aspiring version control wizard! In the previous chapters, you learned what Git is, why it’s indispensable, and how to get it set up on your machine. You even initialized your very first repository. Now, it’s time to bring your Git repository to life by making it track your project’s evolution.

This chapter is all about getting hands-on with the essential Git commands that you’ll use daily: git add, git commit, git log, and git status. These aren’t just commands; they are the bedrock of managing your project’s history. We’ll explore the crucial concept of the “staging area,” understand how to create meaningful snapshots of your work, and learn how to review your project’s timeline. By the end of this chapter, you’ll be confidently tracking your changes and building a robust history for your projects.

Ready to dive in and make your first official Git snapshot? Let’s go!

Core Concepts: The Git Workflow - From Idea to Snapshot

Before we type any commands, let’s understand the fundamental workflow within a Git repository. Imagine your project has three main areas where your files reside, each playing a distinct role in how Git tracks changes:

1. Working Directory (or Working Tree): This is where you actually do your work. It’s the folder on your computer that contains all your project files and subfolders. When you create a new file or modify an existing one, these changes are initially only in your working directory. Git sees these changes but isn’t actively tracking them for a snapshot yet.

2. Staging Area (or Index): This is a unique concept in Git, acting as a “waiting room” or a “pre-commit buffer.” When you decide you’re ready to include certain changes in your next snapshot (commit), you move them from the working directory to the staging area. This allows you to meticulously craft your next commit, including only the relevant changes, even if you have other unfinished modifications in your working directory. It’s like preparing a package for shipment – you select exactly what goes into this package.

3. Git Repository (or Local Repository): This is where Git permanently stores all your project’s history as a series of snapshots, called “commits.” Once changes are in the staging area and you’re happy with them, you “commit” them. This creates an immutable snapshot of your project’s state at that specific moment, along with a message explaining what changed.

Here’s a visual representation of this workflow:

• Working Directory: Where you edit files.
• Staging Area: Where you prepare changes for your next snapshot.
• Git Repository: Where your project’s history (commits) is stored.

This three-stage process gives you incredible control over what gets saved in your project’s history.

What’s Git Status? Your Project’s Dashboard

Think of git status as your project’s real-time dashboard. It tells you exactly what’s happening in your working directory and staging area relative to your last commit. It answers questions like:

• Are there new files I haven’t told Git about?
• Have I modified existing files?
• Are there changes ready to be committed?
• What branch am I currently on? (More on branches later, but it’s good to know!)

It’s the first command you’ll often type to get your bearings.

git add: Selecting Changes for Your Snapshot

The git add command is how you move changes from your working directory to the staging area. You can add individual files, specific directories, or even all changes at once. It’s like carefully selecting the ingredients for your next recipe.

git commit: Creating a Permanent Snapshot

Once your changes are in the staging area and you’re satisfied, git commit takes everything currently in the staging area and packages it into a new, permanent snapshot in your Git repository. Each commit requires a “commit message,” which is a brief, descriptive explanation of the changes included in that snapshot. Good commit messages are vital for understanding your project’s history later on!

git log: Exploring Your Project’s History

The git log command allows you to view the history of your commits. It shows you who made which changes, when, and with what message. It’s your project’s diary, detailing every significant step it has taken.

Step-by-Step Implementation: Making Your First Commits

Let’s put these concepts into practice! We’ll start with a fresh repository.

1. Set Up Your Project Folder

First, create a new directory for our practice project and navigate into it.

mkdir my-first-git-project
cd my-first-git-project

2. Initialize a Git Repository

Now, initialize Git in this directory. If you followed Chapter 2, this should be familiar.

git init

You should see output like: Initialized empty Git repository in /path/to/my-first-git-project/.git/

3. Check Your Status - The Empty Slate

Before we do anything, let’s see what Git thinks about our brand new, empty project.

git status

Expected Output:

On branch main

No commits yet

nothing to commit (create/copy files and use "git add" to track)

Explanation:

• On branch main: Git automatically creates a default branch named main (historically master, but main is now the widely adopted default in new repositories). We’ll dive deep into branches later.
• No commits yet: As expected, we haven’t saved any snapshots.
• nothing to commit: There are no changes in the staging area, and no files in the working directory that Git knows about (or that are untracked).

4. Create Your First File

Let’s create a simple text file. We’ll call it README.md.

echo "# My First Git Project" > README.md

This command creates a file named README.md and adds the text # My First Git Project to it.

5. Check Status Again - Git Sees a New Friend!

Now that we’ve created a file, let’s ask Git for its status again.

git status

Expected Output:

On branch main

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)
	README.md

nothing added to commit but untracked files present (use "git add" to track)

Explanation:

• Git now tells us about Untracked files. This means Git sees README.md in your working directory, but it doesn’t know if you want to track it or ignore it. It’s just there.
• The hint use "git add <file>..." to include in what will be committed is exactly what we need to do.

6. Stage Your First File with git add

We want Git to track README.md and include it in our next snapshot. Let’s move it to the staging area.

git add README.md

This command tells Git: “Hey, I want to include the current state of README.md in my next commit.”

7. Verify Staged Changes with git status

What does our dashboard say now?

git status

Expected Output:

On branch main

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
	new file:   README.md

Explanation:

• Changes to be committed: Excellent! Git now shows README.md under this section, indicating it’s in the staging area and ready for a snapshot.
• new file: README.md: Git recognizes it as a newly tracked file.
• The hint use "git rm --cached <file>..." to unstage tells you how to remove it from the staging area if you change your mind.

8. Create Your First Snapshot with git commit

It’s time for the big moment – your first commit! We’ll use the -m flag to provide a commit message directly in the command.

git commit -m "Initial commit: Add README.md file"

Expected Output:

[main (root-commit) 6a1b2c3] Initial commit: Add README.md file
 1 file changed, 1 insertion(+)
 create mode 100644 README.md

(Your commit hash, e.g., 6a1b2c3, will be different.)

Explanation:

• [main (root-commit) 6a1b2c3]: This confirms the commit was made on the main branch, it’s the very first (“root”) commit, and 6a1b2c3 is a short version of the unique identifier (hash) for this commit.
• 1 file changed, 1 insertion(+): Summary of the changes.
• create mode 100644 README.md: Details about the file creation.

Congratulations! You’ve just created your first permanent snapshot in Git.

9. Check Status Again - A Clean Slate

What does git status show now?

git status

Expected Output:

On branch main
nothing to commit, working tree clean

Explanation:

• working tree clean: This is the ideal state! It means there are no uncommitted changes in your working directory or staging area. Everything is saved.

10. View Your Project’s History with git log

Let’s look at the history we’ve created.

git log

Expected Output:

commit 6a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b (HEAD -> main)
Author: Your Name <your.email@example.com>
Date:   Mon Dec 23 10:30:00 2025 +0000

    Initial commit: Add README.md file

Explanation:

• commit 6a1b2c3...: The full SHA-1 hash (unique ID) of your commit.
• (HEAD -> main): HEAD is a pointer to the current commit you’re on. main is the branch name, also pointing to this commit.
• Author: Who made the commit (based on your git config settings).
• Date: When the commit was made.
• The blank line, then Initial commit...: This is your commit message.

11. Make More Changes and Commit Them

Let’s add more content to README.md and create another file.

First, append some text to README.md:

echo "This project is awesome!" >> README.md

Next, create a new file, index.html:

echo "<h1>Hello Git!</h1>" > index.html

Now, check the status:

git status

Expected Output:

On branch main
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
	modified:   README.md

Untracked files:
  (use "git add <file>..." to include in what will be committed)
	index.html

no changes added to commit (use "git add" and/or "git commit -a")

Explanation:

• modified: README.md: Git correctly identifies that README.md has been changed since its last commit, and these changes are not yet in the staging area.
• Untracked files: index.html: Git sees the new index.html file, but it’s not being tracked yet.

This is a common scenario: some files are modified, some are new. You can stage them selectively.

12. Staging Multiple Files

Let’s stage both files. You can add them one by one, or use git add . to stage all changes in the current directory (including new, modified, and deleted files).

git add README.md index.html
# OR, to stage all changes (new and modified) in the current directory:
# git add .

Now, check git status again:

git status

Expected Output:

On branch main
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
	modified:   README.md
	new file:   index.html

Both files are now in the staging area!

13. Second Commit!

Let’s commit these changes with a descriptive message.

git commit -m "Add index.html and update README with project description"

Expected Output:

[main 1a2b3c4] Add index.html and update README with project description
 2 files changed, 2 insertions(+)
 create mode 100644 index.html

(Again, your commit hash will differ.)

14. Reviewing the Enhanced History

Now, git log will show both commits:

git log

Expected Output:

commit 1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b (HEAD -> main)
Author: Your Name <your.email@example.com>
Date:   Mon Dec 23 10:40:00 2025 +0000

    Add index.html and update README with project description

commit 6a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b
Author: Your Name <your.email@example.com>
Date:   Mon Dec 23 10:30:00 2025 +0000

    Initial commit: Add README.md file

You can see both snapshots, in reverse chronological order (newest first).

git log Variations for Better Readability

git log can be quite verbose. Here are some useful variations:

• --oneline: Shows each commit on a single line, with a shortened hash and message. Great for a quick overview.

  git log --oneline
  

  Example Output:

  1a2b3c4 (HEAD -> main) Add index.html and update README with project description
  6a1b2c3 Initial commit: Add README.md file
  

• --graph: Displays an ASCII art graph of the commit history, useful for visualizing branches (which we’ll cover soon!).

  git log --oneline --graph
  

  Example Output:

  * 1a2b3c4 (HEAD -> main) Add index.html and update README with project description
  * 6a1b2c3 Initial commit: Add README.md file
  

• --pretty=format:"...": Allows you to customize the output format extensively. This is advanced, but good to know it exists for complex scripting.

  git log --pretty=format:"%h - %an, %ar : %s"
  

  Example Output:

  1a2b3c4 - Your Name, 1 minute ago : Add index.html and update README with project description
  6a1b2c3 - Your Name, 10 minutes ago : Initial commit: Add README.md file
  

  (Refer to the official Git documentation for all --pretty format options if you’re curious!)

Mini-Challenge: Build Your Own History!

It’s your turn to practice!

Challenge:

1. Create a new file called styles.css in your my-first-git-project directory and add some basic CSS rules (e.g., body { font-family: sans-serif; }).
2. Modify your index.html file to link to styles.css and add a paragraph of text.
3. Stage only the styles.css file and commit it with a message like “Add basic styles.css”.
4. Stage the modified index.html file and commit it with a message like “Link styles and add content to index.html”.
5. Use git log --oneline --graph to observe your commit history.

Hint: Remember the git add <filename> command to stage individual files.

What to observe/learn:

• How to selectively stage files when you have multiple changes.
• How git log clearly separates your commits, even if they were made in quick succession.
• The importance of clear commit messages for each logical change.

Common Pitfalls & Troubleshooting

Even seasoned developers sometimes stumble with these basic commands. Here are a few common issues:

1. Forgetting git add before git commit:

   • Symptom: You’ve made changes, run git commit -m "My message", but Git says nothing to commit, working tree clean or no changes added to commit.
   • Reason: You forgot to move your changes from the working directory to the staging area. Git doesn’t know which changes you want to include in the snapshot.
   • Solution: Run git status to see your modified files, then git add <file> (or git add .) for the files you want to include, and then git commit.

2. Committing Sensitive Information:

   • Symptom: You accidentally added and committed a file containing API keys, passwords, or other sensitive data.
   • Reason: Overlooking files that shouldn’t be tracked.
   • Solution (Short-term): DO NOT push this commit to a public repository! If it’s still only on your local machine and the very last commit, you can use git reset --soft HEAD~1 to un-commit the changes, then remove the sensitive file and re-commit. For older commits or if pushed, it’s more complex and often involves tools like git filter-repo or BFG Repo-Cleaner (advanced topic for later, but crucial to know the risk!).
   • Best Practice: Use a .gitignore file (we’ll cover this in a future chapter!) to tell Git which files and folders to always ignore and never track.

3. Vague or Unhelpful Commit Messages:

   • Symptom: Your git log is full of messages like “changes”, “fix”, “update”, “stuff”.
   • Reason: Rushing or not understanding the value of good commit messages.
   • Solution: Take a moment to write a clear, concise, and descriptive commit message that explains what changed and why. A good rule of thumb: the first line should be a summary (under ~50-72 characters), followed by a blank line, then a more detailed explanation if needed. Think of it as a mini-story of your change.

Summary: You’re Now Tracking!

You’ve just mastered the core workflow of Git! Let’s recap what you’ve learned:

• The Git Workflow: Understanding the journey of changes from your Working Directory to the Staging Area and finally into the Git Repository as a Commit.
• git status: Your essential tool for seeing the current state of your project’s files – whether they’re untracked, modified, or staged.
• git add: How to meticulously select and move changes into the staging area, preparing them for your next snapshot.
• git commit: The command to create a permanent, immutable snapshot of your staged changes, complete with a descriptive message.
• git log: Your window into the project’s history, allowing you to review all previous commits. You also learned about useful variations like --oneline and --graph.

You’re no longer just editing files; you’re actively managing your project’s history, one intentional snapshot at a time. This foundation is absolutely crucial for everything else we’ll learn in Git.

What’s Next? In Chapter 4, we’ll dive deeper into managing changes, including how to inspect differences, unstage changes, and even undo mistakes. Get ready to become even more confident in navigating your Git projects!

References

• Official Git Documentation - Git Basics - Recording Changes to the Repository
• GitHub Docs - Get started with Git
• Atlassian Git Tutorial - Git status
• Atlassian Git Tutorial - Git add
• Atlassian Git Tutorial - Git commit
• Atlassian Git Tutorial - Git log

This page is AI-assisted and reviewed. It references official documentation and recognized resources where relevant.