The Working Directory: What Git Actually Watches

Learning Objectives

By the end of this lesson you will be able to:

Define the working directory and distinguish it from the repository
Predict what git status will say after creating or editing a file
Explain what "untracked" means and why Git starts out ignoring your files
Use a .gitignore file to keep noise out of your repository

The Room You're Standing In

The working directory is simply the folder you're in and the files you can see, open, and edit. It's your desk. Nothing mysterious about it — the mystery is only ever about what Git thinks of it.

There are two things living in that folder at the same time:

Your files — the visible ones, exactly as they are right now
The repository — the hidden .git folder, holding every version you have committed

Git's job is to compare those two and tell you the difference. That is genuinely all git status does.

Watch It Happen

Inside your qa-notes repository, create a file:

echo "Login smoke checklist" > checklist.md
git status

Git answers:

On branch main

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        checklist.md

nothing added to commit but untracked files present

Git noticed the file immediately — you didn't have to tell it anything. But look at the word it used: untracked.

"Untracked" Is a Deliberate Choice

An untracked file is one Git can see but has never been asked to record. It's not in any commit; Git knows nothing about its history and is making no promises about it.

This surprises beginners, who expect a repository to protect everything in the folder automatically. It doesn't, and that's on purpose. A real project folder is full of things that must never enter the history:

Passwords, API tokens, and .env files
Screenshots, videos, and 400 MB of test evidence
Generated files — build output, node_modules, target/, __pycache__
Your editor's junk — .DS_Store, .idea/, *.swp

If Git committed everything by default, every repository on earth would be a swamp of leaked credentials and machine-generated noise. Instead, Git waits to be told. You choose what becomes history.

Keeping the Noise Out: `.gitignore`

Some files you'll never want tracked, and having Git list them as "untracked" forever is its own kind of noise. Create a file named .gitignore in the repository root:

# Test evidence — too large for the repo
screenshots/
*.mp4

# Secrets — never, under any circumstances
.env
credentials.json

# OS and editor junk
.DS_Store
.idea/

Now git status stays clean and shows only what actually matters. One rule per line; a trailing / means "this whole folder"; * matches anything.

.gitignore itself should be committed — it's part of the project's shared configuration, and every teammate benefits from it.

Pro Tip: Add .env and your credentials files to .gitignore before you make your first commit. Removing a leaked secret from Git history afterward is a genuinely difficult operation, and the secret must be rotated anyway — the history is already out there.

The Mental Picture So Far

qa-notes/                  ← your working directory
├── checklist.md           ← a file you can see and edit
├── .gitignore             ← rules for what to ignore
└── .git/                  ← the repository: all committed history

The next module explains how a file travels from the left side of that picture into the right side — and why Git makes you do it in two deliberate steps.

Key Takeaways

The working directory is the visible folder and its files; the repository is the hidden .git folder
git status reports the difference between what's on disk and what's been committed
New files start as untracked: Git sees them but records nothing until you ask
Untracked-by-default protects you from committing secrets, huge files, and generated junk
.gitignore lists paths Git should permanently ignore, and the file itself belongs in the repository