What git add . Does and When You Should Use It

git add . stages all your changed files at once for your next commit

When you run git add . in your project folder, you tell Git to prepare every file you've modified, created, or deleted since your last commit. The period means "everything in this folder and all subfolders." Git moves those changes into the staging area — a holding zone between your working files and your actual commit. Nothing is permanent yet; you can still unstage files or change your mind before you commit.

This is different from git add filename.txt, which stages only one specific file, or git add . in a subfolder, which stages only changes within that subfolder. The period is a wildcard that means "all changes, everywhere below this point."

Key Takeaways

git add . stages every modified, new, and deleted file in your project folder and all subfolders at once.
Staging is not the same as committing — files stay in the staging area until you run git commit, and you can unstage them with git reset if you change your mind.
Using git add . is fast for small projects or when you want to commit everything, but it can accidentally stage files you meant to keep out of version control.
A .gitignore file tells Git which files to skip when you use git add ., so you can use it safely without staging secrets, build files, or temporary data.

How the staging area works

Git has three zones: your working directory (the files you actually edit), the staging area (files queued for the next commit), and the repository (all your saved commits). When you run git add ., you move files from zone one to zone two. They sit there until you commit them into zone three.

You can see what's staged by running git status. Files in green are staged and ready to commit. Files in red are changed but not staged. This lets you review what you're about to save before you actually save it. If you staged something by mistake, git reset filename.txt unstages just that file, or git reset unstages everything.

When git add . is the right choice

Use git add . when you've made changes across multiple files and you want to commit all of them together. This is common when you finish a feature, fix a bug that touches several files, or refactor code. It's faster than typing out each filename one by one.

It's also safe if you've set up a .gitignore file. That file tells Git which files to ignore — things like node_modules folders, .env files with passwords, compiled code, or temporary editor files. When you run git add ., Git skips anything listed in .gitignore, so you don't accidentally commit secrets or clutter.

When git add . can cause problems

If you don't have a .gitignore file, git add . will stage everything, including files you meant to keep private. A common mistake is committing a .env file that holds database passwords or API keys. Once it's in your commit history, removing it is messy — the file stays in older commits even if you delete it later.

Another risk is staging work-in-progress files you're not ready to commit yet. If you're experimenting in a file and accidentally run git add ., that half-finished code goes into your next commit. You can unstage it with git reset, but only if you catch it before you commit.

Setting up .gitignore to use git add . safely

Create a file named .gitignore in your project root (the top-level folder). List one pattern per line for files Git should skip. For a Node.js project, a basic .gitignore might look like this:

node_modules/ .env .DS_Store *.log

The first line ignores the node_modules folder. The second ignores .env files that hold secrets. The third ignores macOS system files. The fourth ignores any file ending in .log. After you create or edit .gitignore, git add . will skip all of these automatically. You only need to set it up once per project.

Alternatives to git add .

If you want more control, use git add filename.txt to stage one file at a time. This takes longer but lets you review each change before staging it. For a middle ground, git add -p (patch mode) walks you through each change in each file and asks whether to stage it. This is useful when one file has multiple unrelated changes and you want to commit them separately.

You can also use git add -u to stage only files you've modified or deleted, skipping new files. This is helpful if you've created temporary files you don't want to commit yet.

What happens after you stage files

After you run git add ., the files sit in the staging area until you commit them. Run git commit -m "Your message here" to save them to your repository with a description of what changed. The message should be short and clear — "Fix login button alignment" or "Add user search feature" — so you and your team can understand what each commit did.

Once you commit, those changes are saved in your project history. You can see them with git log, revert to them if something breaks, or push them to a remote repository like GitHub so others can see your work.

Frequently Asked Questions

Does git add . delete files from my computer?

No. git add . only tells Git to track changes — it doesn't delete anything. If you've deleted a file in your working directory and run git add ., Git stages that deletion so the file will be removed from the repository when you commit. But the file stays on your computer until you actually commit.

Can I undo git add . if I change my mind?

Yes. Run git reset to unstage everything, or git reset filename.txt to unstage just one file. This moves files back from the staging area to your working directory without changing the files themselves. Your edits stay intact.

What's the difference between git add . and git add -A?

In most cases, they do the same thing. Both stage all changes in your project. The difference matters only if you're in a subfolder — git add . stages changes in that subfolder and below, while git add -A stages changes everywhere in the project. For simplicity, use git add . from your project root.

Should I always use .gitignore?

Yes. Even small projects benefit from a .gitignore. At minimum, ignore your language's dependency folder (node_modules for Node.js, venv for Python) and any .env file that holds secrets. Most code hosting sites like GitHub offer template .gitignore files for your language when you create a new project.

What if I staged a file with a password in it?

If you haven't committed yet, run git reset filename.txt to unstage it, add the filename to .gitignore, and commit without it. If you already committed, the file is in your history. Change the password immediately, then research how to rewrite your commit history using git filter-branch or git filter-repo — this is complex and worth learning only if the secret was real and exposed.

This guide is for general information only and is not medical, financial, legal, or other professional advice. For decisions specific to your situation, consult a qualified professional. See our Editorial Policy.