Welcome to this lesson on Git Add, Git Commit, and Git Log Basics. In this lesson, you will learn how to manage changes efficiently in Git by understanding how your work moves through Git’s workflow—from your initial workspace to the project's history. You’ll explore the three key stages: the working directory, the staging area, and the repository. You'll also learn how to use essential Git commands, including git add to stage your changes, git commit to save them in the project’s history, and git log to review the history of your commits. By the end of this lesson, you'll have the foundational knowledge to manage changes in your Git projects effectively.

In Git’s workflow, managing changes efficiently involves understanding how your work moves from being just an idea on your screen to being safely stored in your project history. This journey happens in three key stages:

1. Working Directory: This is where your active files live. Any time you edit a file, add new ones, or remove others, it happens here. Think of it as your workspace, where all the initial work takes place.

2. Staging Area (Index): Before saving your work permanently, you have a chance to review and decide which changes should be kept. The staging area serves as a middle ground, where you can prepare and review changes. You can think of it as a waiting room for the changes you want to keep, while others can stay in the working directory until you’re ready to include them.

3. Repository (Commit History): Once you’ve decided which changes to keep, you move them to the repository. The repository is where all your project’s progress is permanently recorded. Every time you save a snapshot of your project, it gets stored here, along with a history of everything that’s happened.

Now that you have a sense of the workflow—how changes move from your workspace (the working directory), to the waiting room (the staging area), and finally to the project’s memory (the repository)—let’s revisit the example from our first lesson: Bob and Alice preparing for a surprise party.

Bob and Alice are collaborating on organizing a party, where they need to handle tasks like creating a guest list, planning the menu, and setting up decorations. Each task involves multiple revisions and contributions, making Git's workflow an ideal tool to manage these changes smoothly.

Using this example, we will understand how this flow works in action.

After understanding the flow of how changes move through Git's workflow, let’s focus on the first step in making your work part of the project: staging your changes with git add. git add is the command that moves changes from your working directory to the staging area. It’s like preparing your changes for the next save, allowing you to review and choose which files or updates should be included in the next commit. However, it’s important to note that git add doesn’t make any permanent changes to the repository. It just stages your updates, putting them in line for the next save (or commit).

Whether you're adding new files or making changes to existing ones, you must use git add to stage them. This command is crucial for ensuring that both newly created files and modifications to existing files are prepared for the next commit.

Imagine Alice has completed her guest list in the guest_list.txt file. At this point, the changes only exist in her working directory, but they aren’t part of the official project history yet. To prepare these changes for saving, Alice uses the staging area.

To prepare these changes for saving, Alice will stage the updated guest list using the following command:

This tells Git that Alice's updated guest list should be included in the next save.

If Alice wanted to stage all her changes at once—including other updates like her decorations plan—she could have used:

This command stages all the modified files in her working directory, allowing her to prepare everything for the next commit in one step.

After checking the status with git status, Alice can now ensure that her changes to guest_list.txt are staged properly. Here's what she sees:

This indicates that the guest_list.txt file is staged and ready to be included in the next commit. If needed, Alice can unstage the file with git rm --cached guest_list.txt.

With her changes staged, Alice can now proceed to learn about committing, which involves saving these staged changes to the project's history—the repository.

For more details on using git add, you can refer to the official documentation: Git Add Documentation.

Now that Alice has staged her changes with git add, the next step is to save those changes to the project’s history. This is where committing comes in.

git commit is the command that permanently records the changes in the staging area into the repository. You can think of it as taking a snapshot of the project at that moment, capturing the current state of all the files that have been staged. Each commit creates a historical point you can reference later, allowing you to keep track of your project's progress.

It's important to note that committing doesn't automatically push the changes to a shared repository or server (like GitHub). Instead, it saves the changes locally in your project's history.

After staging her updated guest list, Alice is ready to commit it to the repository, which means permanently saving this version of the guest list into the project’s history. To do this, she uses the following command:

In this example, the -m flag allows Alice to include a short message describing the changes she's made. This message is important because it helps others (and Alice herself) understand what was changed and why, when looking at the commit history later.

By committing her changes, Alice has now created a permanent snapshot of the guest list, which is stored in the repository and can be referred back to at any point.

After running git commit -m "Create guest list", the output confirms that your changes were saved successfully. It shows details like the number of files changed and lines added. This reassures you that the changes have been stored in your project's history. You might see output like:

Bob can commit without using the -m option directly. In this case, Git will open the default text editor for her to write a detailed commit message. This method allows her to provide not only a concise subject line but also a more detailed description of the changes in the message body if needed.

When Bob runs the command:

Git opens the text editor configured for such tasks (like Vim, Nano, or any other default editor), allowing her to write the commit message. The editor will typically display a prompt with guidance about writing commit messages at the top, followed by an empty section where she can enter her custom message.

Here's an example of what Bob might write in the editor:

After providing a comprehensive commit message, Alice can save and close the editor to complete the commit. This method offers more flexibility, especially for significant changes that require additional context or explanation.

For more details on using git commit, you can refer to the official documentation: Git Commit Documentation.

In any Git project, there are often files or directories that you don’t want to track in version control. These could include temporary files, logs, build outputs, or files that are a work in progress. To manage this, Git uses a special file called .gitignore, which lists patterns to tell Git which files to ignore. This helps ensure that unnecessary or sensitive files are not accidentally added to the repository. It's crucial to add and commit the .gitignore file to the repository to ensure consistent rules for ignoring files are applied throughout the project.

The .gitignore file is typically created manually at the root of the project. You can create it yourself using a text editor. For more information, refer to the official documentation: Gitignore Documentation.

To understand better, let's explore an example. Imagine Bob is working on a music playlist for the party project, but he’s still experimenting and isn’t ready to include it in the repository. He first creates the .gitignore file using the following command:

Then, he adds the following line to the .gitignore file:

Now, if Bob creates a playlist.txt file and runs git status, Git will not include it in the list of tracked files. This allows Bob to work on the file freely without worrying about committing it prematurely. If Bob later decides the playlist is ready to be shared, he can remove the entry from .gitignore and include the file in his next commit. Using .gitignore ensures that only the necessary files are tracked, keeping the repository clean and organized.

In the diagram, each marked point for Alice and Bob represents a commit. Initially, Alice's first two commits are not yet in the main repository, so Bob can't see them. However, the final commit, "Combine guest list and decorations," is in the main repository, making it visible to Bob. We'll discuss how commits reach the main repository in a later lessons.

Now, let’s take a look at the commits Alice has made for different aspects of the party preparation:

1. "Create guest list"
2. "Plan decorations"
3. "Combine guest list and decorations"

Similarly, Bob has his own commits, such as:

1. "Plan menu"
2. "Create music playlist"
3. "Update menu for vegetarians"

Each commit represents a specific point in time where distinct work was completed and saved to the repository. By organizing their work into smaller, focused commits, Bob and Alice maintain an organized and comprehensible project history.

After making several commits, it’s useful to review the history of those changes. The git log command helps you do just that by showing a list of all the commits made in your project, along with important details like the author, date, and commit message.

Imagine Alice and Bob want to see all the commits they've made while preparing for the party. By running:

They will see something like this:

For each commit, there’s a long string of letters and numbers (such as 9d1e9b8f3b14fd93d69b64ae5b2f634344f5c620). This is the commit hash—a unique identifier that Git generates for each commit. It allows you to reference or revert to this specific commit later if needed.

Then, you can see the author of the commit, the date when the commit was made, and the commit message, which describes the changes. In this case, Alice combined the guest list and decorations, and Bob updated the menu for vegetarians.

You may also notice (HEAD -> main) next to the first commit. This means that this commit is currently at the tip of the main branch, and "HEAD" is pointing to it. We'll talk more about branches and how they work later on.

For longer projects, scrolling through the entire commit history may not always be practical. If Alice and Bob want to focus only on the most recent changes, they can limit the number of commits displayed by running:

This command will show just the last 3 commits, allowing them to quickly review the latest updates without the need to sift through older commits.

In some cases, Alice or Bob may need to search for specific commits. They can filter the commit history by author or keyword to find relevant information. For example, if Bob wants to see only the commits he made, he can use:

If they need to find commits related to a specific topic, such as updates to the menu, they can search by keyword in the commit messages. Running:

will display all the commits that mention "menu" in their messages, helping them locate relevant changes efficiently.

If you need further information and options for using the git log command, you can refer to the official documentation: Git Log Documentation.

In this lesson, you learned how Git manages changes through the working directory, the staging area, and the repository. You now understand how to use git add to stage changes and git commit to save them as snapshots in the project’s history.

You’ve also explored how to review the history with git log, allowing you to see past commits, search by author or keyword, and focus on specific changes.

Now, it’s time to put these concepts into practice by creating your own commits, viewing the log, and using these Git commands to manage changes effectively.