DailyRNG
Login
Basic

Choosing what to save

I committed a `node_modules` folder and a 200-megabyte log file on my first try. That was the day I actually understood the staging area, because git happily saved everything I told it to.

What you will see

Stage this hunk? [y/n]

About 2 min of reading

Quick check

Before this new lesson, one small question about the lesson you just finished. Recall it, do not look it up.

Try It

git add is the only command that decides what actually gets saved, and I spent a whole commit to learning that. Let me stage the wrong thing, then do it right.

1

First, make a mess I can clean up. Two files in the folder: one I finished, one I half-typed and should never keep. Nothing is staged yet, so git treats both as untracked, invisible to history.

echo "login logic" > login.py echo "draft, not ready" > scratch.py

Before you run it, say out loud what it will print. Then open the answer.

What it prints
C:\Users\You\git-tut>
Use real file names you would normally reach for. The point is to stage one and leave the other alone, so the folder needs at least two files.
2

Stage just the finished one. This is the command I reached for every time and finally understood. git add login.py moves that one file into the staging box and leaves scratch.py sitting there, untracked and safe from the commit.

git add login.py

Before you run it, say out loud what it will print. Then open the answer.

What it prints
C:\Users\You\git-tut>
3

Look and see what git staged. The top of the output now lists login.py under “Changes to be committed” and scratch.py under “Untracked files”. Read it like a packing checklist, only what is staged will survive the next commit.

git status

Before you run it, say out loud what it will print. Then open the answer.

What it prints
On branch main Changes to be committed: (use "git restore --staged ..." to unstage) new file: login.py Untracked files: (use "git add ..." to include in what will be committed) scratch.py
4

Seal the box. One commit now, and history only ever sees login.py. scratch.py stays in the folder as a working file but does not become part of the snapshot. That separation is the whole lesson.

git commit -m "Add login"

Before you run it, say out loud what it will print. Then open the answer.

What it prints
[main (root-commit) abc1234] Add login 1 file changed, 1 insertion(+) create mode 100644 login.py
If the success line says "1 file changed" and mentions only login.py, the commit did the right thing. scratch.py was never in it.
5

Now the thing that got me the giant log file. I ran git add . expecting it to stage my code, and it grabbed everything, node_modules, logs, anything sitting in the folder. The dot means all of it, unchanged files included, on purpose.

mkdir logs type NUL > logs\huge.log git add .

Before you run it, say out loud what it will print. Then open the answer.

What it prints
C:\Users\You\git-tut>
This stage everything before you look. A commit with a 200-megabyte log will ship. Always glance at `git status` after the dot, before the commit.
6

Undo the mistake cheaply, before the commit. git reset clears the staging area without deleting anything from the folder, so no work is lost. I reset, deleted the log, then re-added only what I meant to save.

git reset del logs\huge.log git add .

Before you run it, say out loud what it will print. Then open the answer.

What it prints
C:\Users\You\git-tut>
7

When one staged thing is not enough. git add -p opens each change chunk by chunk and asks y or n. I used it once to catch a change I made in a hurry and deleted it live. Slow, but it is the version of git that respects the fact that you sometimes type what you did not mean to.

git add -p

Before you run it, say out loud what it will print. Then open the answer.

What it prints
Stage this hunk? [y/n]
Type y to accept a chunk and n to skip it. A blank line with no prompt means there is nothing left to stage; press Enter to move on.

Put it in order

Before you write anything, put these lines back in the right order. Click a line to move it up one step. This support step is easier than writing code from scratch, and it is here to make the last example stick.

Data Flow

Changes move from your working folder into staging, then a commit seals them into history.
1 Edit files in your working directory
↓
2 git add moves chosen changes into staging
↓
3 git commit seals the staged snapshot into history
↓
4 The next commit starts from a clean box
Why this works
The three areas

Think of git as having three rooms:

  • **Working directory*: your files exactly as they are now, messy and open.
  • **Staging area*: the exact set of changes you are about to save, like a packing box.
  • **Repository*: everything already committed, locked into history.

git add .    # move things into the box
git commit   # seal the box into history

Staging is optional but it keeps history clean. You don't have to commit a snapshot of your whole folder every time.

Why stage at all

Because not every change is ready to be saved, and not every change belongs in the same commit. Maybe you fixed a bug but also left an experiment half-typed. Stage the fix, leave the experiment. git status tells you what is waiting in the box so you can decide before you commit.

Examples

Save exactly one thing

git add login.py

This stages a single file. Nothing else moves. Reach for this when you have finished one task and want choice you reach for when you have finished one task and want to save just that task, even though other files are changed on the screen.

Save the whole folder

git add .

The dot means everything that changed. It's fast and it's what most people default to, which is exactly what got me the 200-megabyte log in my history. Before you run it, glance at git status. If something there should never be saved, add files one at a time instead.

Pick and choose by piece

git add -p

This opens the file a piece at a time and asks y or n before staging each chunk. The first time I used it I was surfaced a change I'd made in a hurry and deleted it live. -p is slow, but it is the version of git that respects the fact that you sometimes type things you didn't mean to.

Words this lesson uses

Each one is defined here on this site. Open the entry for the full definition and the other words it points at.

← The folder nobody sees
Previous Lesson
The folder nobody sees
Next Lesson
Working in a parallel universe
Working in a parallel universe →