Master Git: Understanding Working Directory, Staging Area, and History

1. Git Areas

Git can be conceptually divided into three zones: the working directory , the staging area (also called the index), and the history (the repository).

2. What git add Does

The command git add <files> moves files from the working directory into the staging area. It performs two actions:

It records the file’s timestamp, length, and object ID in a tree‑like index.

It creates a snapshot of the file’s contents and stores it in Git’s object database ( .git/objects).

3. Staging Area Explained

The staging area is essentially a virtual directory tree that holds file indexes. It records file names and metadata (timestamp, length, etc.) but not the file contents themselves; those are kept in the object database. The index links each file name to its corresponding object.

4. How Commands Affect the Areas

In diagrams, the left side represents the working directory, the right side the repository. The region labeled index is the staging area, while master denotes the branch’s tree. HEAD points to the current commit on master.

When you run git add, the index tree updates and a new object is written to the object database. git commit writes the index tree into the repository, moving the master pointer to that tree. git status scans the working directory by comparing timestamps and lengths stored in .git/index with the actual files, which is faster than content comparison. git diff <files> compares the snapshot in the object database with the current working‑directory files, typically showing differences between the staging area and the working directory.

5. Using git reset

git reset -- <files>

undoes the last git add for those files; git reset without arguments resets the entire staging area.

Two common options: --soft (default) moves HEAD to the specified commit but leaves changes staged. --hard discards both staged and working‑directory changes; it only affects local files and should not be used after changes have been pushed.

During a merge conflict, you can resolve the conflict, then run git add, and finally git commit. To abort a merge, git reset --hard ORIG_HEAD or git reset --merge ORIG_HEAD can be used.

6. Using git checkout

git checkout -- <files>

copies files from the staging area back to the working directory, discarding local modifications. git rm --cached <file> removes a file from the index only. git checkout . or git checkout -- <path> replaces the working directory with the staged version (dangerous if you have uncommitted work). git checkout HEAD . replaces both index and working directory with the version from the current commit.

7. Using git revert

git revert

creates a new commit that undoes a previous commit, moving HEAD forward, whereas git reset moves HEAD backward and may rewrite history.

Example: with commits commit1, commit2, commit3, running git revert HEAD~1 creates a new commit that cancels commit2 while preserving commit1 and commit3. The repository state remains unchanged for git status. In contrast, git reset --soft HEAD~1 moves HEAD back, leaving the changes from the undone commit staged.

8. Other Deletion‑Related Commands

git rm --cached <file>

removes the file from the index but keeps it in the working directory. git rm <file> removes the file from both the index and the working directory. git mv <old> <new> renames a file.

To undo changes on a single file after it has been staged, use git reset HEAD <file> to unstage, then git checkout -- <file> to revert the working‑directory version.