The Difference and Usage of git add and git commit for Recording Changes

In the previous articles, you've learned everything from installing Git to creating a GitHub repository and even cloning someone else's repository to your PC with `git clone`. You are now at the starting line of development using Git and GitHub.

This time, we will focus on two essential commands for recording changes, `git add` and `git commit`, which you'll use most frequently in your development work. It's easy to think, "Aren't they both just commands for saving changes?" but these two have completely different roles. Understanding this difference is a crucial key to mastering Git. Let's get to it!

Basic Git Concepts: A Quick Review of the 3 "Places"

To understand the difference between `git add` and `git commit`, let's first review the concept of the "three places" in the basic Git workflow. This concept will clarify the roles of the two commands.

• Working Directory: The folder on your PC where you are actually editing your files.
• Staging Area: A "waiting room" where you temporarily place the changes you want to commit (record).
• Local Repository: The place where changes from the staging area are officially recorded and stored as a history (commit).

It might be easier to understand this flow by comparing it to "shopping."

1. You walk around the store and pick up items (file changes) (work in the Working Directory).
2. You put the items you want to buy into your shopping cart (add them to the Staging Area with `git add`).
3. You go to the cashier, pay for all the items in your cart, and finalize the purchase (record them in the Local Repository with `git commit`).

As you can see, `git add` is the act of "selecting" what to put in the cart, while `git commit` is the act of "confirming the purchase" to record it. Their roles are completely different.

The Role of `git add`: "Choosing" What to Commit

The main role of the `git add` command is to select only the changes from the working directory that you want to include in the next commit and send them to the staging area. Why is this extra step necessary?

It's to keep the change history in meaningful units. For example, imagine you were working on two different tasks at the same time: "fixing a typo in the header" and "implementing a new footer feature." If you lump both of these changes into a single commit, it will be hard to understand what that commit was for when you look back at the history later.

This is where `git add` comes in. If you first `git add` and commit only the file with the typo fix, and then `git add` and commit the footer feature files as a separate commit, your change history will be very clean and organized. In this way, `git add` is a crucial step for improving the quality of your commits.

The Role of `git commit`: "Recording" the Changes

The role of the `git commit` command is to permanently save all the changes that are in the staging area as a single "save point" in the local repository. This is the core operation of version control in Git.

A commit must always be accompanied by a "commit message." This is a brief note explaining "what was changed" at that save point. Writing good commit messages is extremely important for your future self and other team members to understand the history.

git commit -m "Fix navigation link in header"

The moment you run this command, the contents of the staging area are captured as a snapshot and recorded in the repository with a unique ID. Once a history is committed, it will not disappear unless you intentionally manipulate it.

In Practice! Concrete Examples of Using add and commit

Now, let's use the `my-first-repo` folder to see how `git add` and `git commit` behave with actual file operations.

Preparation: Modify Two Files at Once

First, please edit and save both `index.html` and `style.css`.

• `index.html`: Make some changes, like adding an `

  ` tag.

• `style.css`: Make some changes, like adding a style for the `body`.

If you run `git status` in this state, it will report that two files have been modified.

git status

Case 1: Committing Only One File

This is a scenario where you "want to commit only the HTML changes first." Use `git add` to specify only the file you want to commit.

git add index.html

If you check `git status` at this point, you'll see that only `index.html` has been staged, while `style.css` remains in the working directory.

[Image: The output of git status, showing index.html in green and style.css in red.]

Now, execute the commit in this state.

git commit -m "Update HTML structure"

With this, only the changes to `index.html` have been recorded. If you run `git status` again, you'll see that only the changes to `style.css` remain.

Case 2: Committing All Changes at Once

Next, let's try committing the remaining changes to `style.css` and the changes for a newly added `script.js` file all at once. First, create the new file.

echo "console.log('Hello, Git!');" > script.js

Next, use `git add .` to stage all changes in the current directory (the modification of `style.css` and the new addition of `script.js`) at once.

git add .

Finally, commit all these changes together.

git commit -m "Adjust CSS styles and add JS file"

Now, all changes have been recorded, and your working directory is clean. If you run `git status`, it should show "nothing to commit, working tree clean."