Three Trees

When we make a commit, we first need to run git add first. Why is that?

You can definitely design a system to snapshot a folder directly. This results in a two-part system like this

• the current folder, and

• the change history

The downside for this design is that each snapshot takes all changes as one set. If you've changed ten files, the next commit will take all these ten files. Maybe five of them are on data processing, and the other five on model. It will be more reasonable to separate them into two commits, each commit grouping relevant changes.

The staging area

To solve this issue, Git has an intermediate area called the staging area. Only changes in the staging area will be commited. It functions as a buffer zone between the working tree and commit history. This adds more flexibility when it comes to making commits.

With a staging area, you can add five files, commit them. Then handle the remaining five. This ends up with two commits where each commit is more atomic, as revelant changes are grouped togerther.

The three trees

Here are the three .

• the working tree: the folder that you see in the filer explorer, which reflects what the HEAD points to.

• the staging area: the intermediate zone holding changes to be commited. The staging area is similar to a cart. git add moves changes into the cart and git commit empties the cart.

• the commit history

You can look at what're inside the three trees using git status.

How changes flows

• Changes starts in the working tree, where you edit them;

• They move into the staging area via git add;

• Then enter the commit history once you git commit.