Staging, Committing, History

In Git, the staging area (also called the index) is a crucial intermediate step between your working directory and your repository.

Think of it as a waiting room where you prepare changes before permanently saving them.

It allows you to group related changes into a single, meaningful commit.

To move changes from your working directory into the staging area, you use the git add command.

You specify the file(s) you want to stage. This tells Git, "Hey, I want to include these changes in my next commit!"

You don't have to add files one by one. Git provides convenient ways to stage multiple files or even all changes at once.

• git add . stages all new and modified files in the current directory and its subdirectories.
• git add -u stages only modified and deleted files (not new ones).

A commit is like taking a snapshot of your project at a specific point in time. It permanently records the staged changes into your Git repository.

Each commit has a unique ID, an author, a timestamp, and a commit message explaining what changes were made.

Once your changes are in the staging area, you can commit them using git commit. You should always include a clear and concise message to describe the changes.

The -m flag lets you provide the commit message directly.

The git status command is your best friend! It tells you:

• Which files are untracked (new and not yet added to Git).
• Which files have changes that are ready to be committed (staged).
• Which files have changes that are not yet staged.

Before staging or committing, it's good practice to review your changes. The git diff command helps you see exactly what's changed in your files.

By default, git diff shows changes in your working directory that are *not* yet staged.

What if you want to see the changes you've already moved to the staging area, before committing them?

You can use git diff --staged (or git diff --cached) to compare the staged changes with the last commit.

To see a chronological list of all commits in your repository, use the git log command. This shows you who made changes, when, and what their commit messages were.

It's essential for understanding your project's evolution!

The default git log output can be quite detailed. For a quick overview, you can use options to simplify it:

• git log --oneline: Shows each commit on a single line.
• git log --graph: Displays an ASCII art tree of the commit history.

You've just modified index.html and created a new file style.css. You want to include both in your next commit.

Which sequence of commands correctly stages and commits these changes?

Great job! In this lesson, you learned the core steps of Git's local workflow:

• The staging area (index) is where you prepare changes.
• Use git add to move changes to the staging area.
• A commit is a permanent snapshot of your staged changes.
• Use git commit -m "message" to save a commit.
• git status shows your working directory's state.
• git diff helps review changes.
• git log allows you to explore your project's history.

These commands are fundamental to tracking your project's progress!