Git Staging, Meaningful Commits, and History Review

Welcome to your third lesson. In our last session, you successfully created a professional project repository, complete with a proper folder structure, a .gitignore file, a README.md, and you published it to your GitHub account. This is the solid foundation upon which we will build your e-commerce application.

Today, we'll shift from setup to the daily rhythm of a developer. This lesson will teach you how to use Git to stage changes, write meaningful commits, and inspect project history. You'll learn how to make changes to your project, save them as distinct "snapshots" in your history, and look back at the work you've done. This edit-stage-commit cycle is the most fundamental and frequently used workflow in Git.

The Core Git Workflow

Every time you work on your project, you'll move your changes through three key areas. Understanding these areas is crucial for using Git effectively.

Working Directory: This is your main project folder (ecommerce-store) where you actively edit your files.
Staging Area: This is an intermediate area where you gather the specific changes you want to include in your next "snapshot." It lets you be precise about what you save.
Repository: This is the history of all the snapshots (commits) you've saved. It's stored in the hidden .git folder.

This workflow is often summarized as: Edit, Add, Commit. You edit files in your working directory, add the finished changes to the staging area, and then commit them to the repository.

The following short video provides a great visual explanation of this three-area model.

Git Crash Course #4 - Staging Files

Watch this segment from the "Git Crash Course" series by Net Ninja. It clearly explains the relationship between the working directory, staging area, and repository.

Pay close attention to the flow described from the beginning of the video. The shopping cart analogy is a helpful way to think about the staging area.

Making and Staging Your First Change

Let's put this into practice. Open your ecommerce-store project in VS Code and open the integrated terminal.

First, create a new file that will eventually become your store's homepage.

touch client/index.html

Now, open client/index.html in VS Code and add some basic HTML structure:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>My E-Commerce Store</title>
</head>
<body>
  
</body>
</html>

Save the file. You've just made a change in your working directory.

How does Git see this change? The most important command for checking the state of your project is git status. Run it now:

git status

You'll see a section called "Untracked files" with client/index.html listed in red. "Untracked" means Git sees a new file in your working directory, but it's not part of your project's history or the staging area yet.

To tell Git you want to include this new file in your next commit, you need to "stage" it using the git add command.

git add client/index.html

You've just moved the file from the working directory to the staging area. Now run git status again. Notice that index.html is now green and listed under "Changes to be committed."

The staging area is a powerful feature that allows you to craft your commits precisely. For a deeper dive into the concept and the git add command, the official GitHub guides are an excellent resource.

Git Guides - git add

This guide explains the purpose of the staging area and the different ways you can use git add.

Focus on these parts: The explanation of what the staging area is. Thinking of git add as git stage can be helpful. The list of common usages. The discussion on staging all files versus specific files. It's a good practice to be explicit and add files individually or by directory to avoid accidentally committing unwanted changes. The brief section on unstaging a file using git reset. We will look at the more modern git restore command for this later.

Committing Changes with a Meaningful Message

Now that your change is staged, you can save it permanently to the repository's history. This is done with the git commit command. A commit should be a logical, self-contained unit of work—like fixing a single bug or adding a specific feature.

Every commit requires a message. This message is crucial for you and your future colleagues to understand the history of the project.

Run the following command to commit your staged file:

git commit -m "Add initial HTML structure for client homepage"

The -m flag allows you to write your commit message inline. You've now created your second commit! The first was the "Initial commit" from the previous lesson.

Writing good commit messages is a critical skill for professional developers. They should be clear, concise, and written in the present tense (e.g., "Add feature" not "Added feature").

Git Guides - git commit

This guide explains what a commit is and provides excellent examples of how to write effective commit messages.

Please read the introduction and the "Examples of Git Commit" section. Start with the section about commits to understand their role. Then, jump down to the examples section. Pay close attention to the style: present tense and directive (e.g., "create," "translate," "update"). This is the convention we will follow.

Viewing and Comparing Changes

Let's practice the cycle one more time and learn how to inspect our work.

Edit: Open client/index.html again and add a heading inside the <body>:
```
<body>
  <h1>Welcome to the Store!</h1>
</body>
```
Check Status: Run git status. It will now show client/index.html as "modified" in red. This means the file in your working directory is different from the last version you committed.
View Differences (git diff): Before staging, you can see the exact changes you've made using git diff.
```
git diff
```
This command compares your working directory to the staging area. You'll see the line <h1>Welcome to the Store!</h1> with a + sign, indicating it was added. The following video explains how to interpret the output of git diff.

Git Tutorial for Beginners: Learn Git in 1 Hour

This clip from "Git Tutorial for Beginners" by Programming with Mosh clearly breaks down the diff command and its output.

Watch the segment from the beginning of the clip. The key is understanding that git diff shows unstaged changes, and the + and - signs represent additions and deletions.

Stage: Now, add your modified file to the staging area.
```
git add client/index.html
```
View Staged Differences: To see what changes are staged and will be in your next commit, you use git diff with the --staged flag.
```
git diff --staged
```
This compares the staging area to your last commit. The output will look the same as before, because you staged the change you just made.
Commit: Finally, commit your work with another descriptive message.
```
git commit -m "Add main heading to client homepage"
```

Inspecting Your Project's History

Now that you have a few commits, how do you look back at them?

The primary command for this is git log.

git log

This will show you a list of all your commits, starting with the most recent. Each entry includes:

A long, unique commit hash (like d6a5c1e...).
The author, date, and commit message.

For a more compact view, you can use:

git log --oneline

This shows just the first seven characters of the commit hash and the message for each commit.

To see the specific changes made in a single commit, you use git show followed by the commit's hash. Copy the hash (or just the first 7 characters) from your git log output for the commit where you added the heading, and run:

git show <your-commit-hash>

This will display the commit information and the full diff of the changes made in that snapshot.

The video you watched earlier also has excellent sections on using git log and git show.

Git Tutorial for Beginners: Learn Git in 1 Hour

These sections from the same tutorial will walk you through inspecting your commit history.

First, watch the segment on git log from the start of the clip. Then, watch the following segment on git show from its beginning to understand how to view a specific commit's contents.

A Quick Note on Undoing Mistakes

What if you stage a file by accident? You can "unstage" it with the git restore command.




# To unstage a file:
git restore --staged <file-name>

This moves the file from the staging area back to the working directory. Your changes are safe; they are just no longer prepared for the next commit.

Conclusion

In this lesson, you've mastered the fundamental day-to-day workflow of a Git user. This cycle of editing files, staging changes, and creating well-messaged commits is the heartbeat of version control.

Here are your key takeaways:

The three areas of Git are the Working Directory, the Staging Area, and the Repository.
git status is your go-to command to check the state of your project.
git add <file> moves changes from the working directory to the staging area.
git commit -m "message" saves staged changes to the repository's history as a new snapshot.
Commit messages should be in the present tense and describe the change clearly.
git diff shows unstaged changes, while git diff --staged shows staged changes.
git log lets you browse your project's commit history.
git show <hash> allows you to inspect the details of a specific commit.

So far, all our work has been on the main branch. This is generally not a safe practice for professional projects. In our next lesson, you will learn how to use feature branches to work on new changes in isolation and then safely integrate them using a GitHub Pull Request. This is a cornerstone of collaborative software development.

Recommended resources