The four areas

Why this matters

Almost every confusing Git moment is a question about location: "I saved the file, why does Git say nothing changed?", "I committed, why can't my colleague see it?", "I pulled, where did my edits go?". Git keeps your project in four places at once. Once you can picture them, the answers become obvious, and every command in the course becomes "move something from here to there".

The picture

Try it

Click a file to move it between the areas. Every click prints the command that would have done the same thing in a terminal.

The first three areas live on your computer. Only the fourth involves the network.

One change, start to finish

Watch a single edit to docs/faq.md travel through all four areas. Ana starts one commit ahead of the remote.

Edit. She adds a question to the FAQ and saves. The change is in the working tree only:

$ git status

On branch main
Your branch is ahead of 'origin/main' by 1 commit.
  (use "git push" to publish your local commits)

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
	modified:   docs/faq.md

no changes added to commit (use "git add" and/or "git commit -a")

Stage. git add copies the change into the staging area:

$ git add docs/faq.md
$ git status

On branch main
Your branch is ahead of 'origin/main' by 1 commit.
  (use "git push" to publish your local commits)

Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
	modified:   docs/faq.md

Commit. git commit turns the staging area into a snapshot in the local repository:

$ git commit -m "docs: explain how to add a trail (#27)"

[main 2f543f1] docs: explain how to add a trail (#27)
 1 file changed, 4 insertions(+)

$ git status

On branch main
Your branch is ahead of 'origin/main' by 2 commits.
  (use "git push" to publish your local commits)

nothing to commit, working tree clean

The working tree is clean (it matches the newest commit), and the branch is now two commits ahead of the remote: two snapshots exist only on Ana's computer.

Push. git push sends those commits to the remote:

$ git push

To https://gitlab.com/northwind-trails/trailguide.git
   0d9eb38..2f543f1  main -> main

$ git status

On branch main
Your branch is up to date with 'origin/main'.

nothing to commit, working tree clean

All four areas now agree. Ben can fetch the two commits; the pipeline runs; the change is visible on GitLab.

The commands by area

Three commands are read-only and always safe: status, diff, log. The rest move things, forward or backward.

Why the staging area exists

Beginners often ask why git add is a separate step. Two reasons that matter in practice:

• Choosing. You can commit part of your work: the finished FAQ answer now, the half-written guide later. Small, focused commits are easier to review and to undo.
• Checking. git diff --staged shows exactly what the commit will contain, before it exists. Read it, catch the debug line or the typo, fix, stage again.

IDEs hide the staging area behind checkboxes (VS Code's "Staged Changes" list, IntelliJ's ticked files), but it is always there.

Do and don't

Common mistakes

• "I committed but the pipeline did not run." The pipeline watches the remote. Push.
• "I edited the file after git add and the commit has the old version." The staging area holds the content at the time of git add. Stage again.
• "git diff shows nothing but git status says modified." The change is staged; git diff compares the working tree with the staging area, which now match. Use git diff --staged.