Git add . stages all your changes at once, preparing them to be saved into your version history
When you run git add . in your project folder, you are telling Git to notice every file you have created, edited, or deleted since your last save point. The period means "everything in this folder and all folders inside it." Git marks these changes as staged — ready to be bundled into a snapshot — but does not actually save them yet. That happens when you run git commit afterward.
Think of it like gathering papers on your desk before filing them. git add . is the gathering step. git commit is the filing step. Until you commit, you can still change your mind about what goes into the snapshot.
Key Takeaways
- git add . stages all modified, new, and deleted files in your current folder and subfolders, but does not save them yet.
- You can stage only some files by using git add filename instead, which gives you more control over what goes into each snapshot.
- After staging with git add ., you must run git commit -m "your message" to actually save the snapshot to your history.
- If you stage something by mistake, git reset filename removes it from the staging area without deleting the file itself.
- Staging lets you group related changes together, so your version history stays organized and easier to understand later.
The difference between staging and saving
Git has two separate steps for a reason. When you edit a file, Git sees the change right away. But that change is unstaged — Git is watching it, but it is not part of any snapshot yet. Running git add . moves those changes into the staging area, a temporary holding space. The files are still on your computer; nothing is locked in.
This matters because you might edit five files but only want to save three of them in this snapshot. You can run git add file1.txt file2.txt file3.txt to stage only those three, leaving the other two unstaged. Then git commit saves only the staged files. The unstaged ones stay on your computer, unchanged and unrecorded.
If you use git add . and then realize you staged something you should not have, you can unstage it with git reset filename before you commit. Once you commit, the snapshot is permanent in your history.
When to use git add . versus adding specific files
git add . is fastest when every change you have made is something you want to save right now. If you have edited three related files and created one new configuration file, and all four changes belong in the same snapshot, git add . saves you from typing four separate commands.
Use git add filename when you have made changes that should go into separate snapshots. For example, you might have fixed a bug in one file and started a new feature in another. Those are two different reasons for changes, so they should be two different snapshots. Staging them separately keeps your version history clear — someone reading it later (including you, six months from now) can understand why each change was made.
A good rule: if you can describe all your staged changes in one sentence, git add . is probably fine. If you need two sentences, split them into two commits.
What files git add . actually stages
git add . stages three kinds of changes: files you have edited, files you have created, and files you have deleted. It does not stage files that Git is not already tracking. If you create a new file but never run git add on it, Git ignores it forever until you explicitly add it.
It also respects your .gitignore file, a list of files or patterns Git should never track. If you have a folder called node_modules listed in .gitignore, running git add . will skip it, even if the folder exists and has changed. This is useful for keeping large generated folders, temporary files, and secrets out of your version history.
You can see what git add . would stage before you run it by typing git status. This shows you which files are unstaged, which are staged, and which Git is ignoring. It is a safe way to double-check before you commit.
The workflow: add, commit, and push
After you run git add ., the next step is git commit -m "describe what you changed". The message should be short and clear — "Fixed login button alignment" or "Added user email validation" — so that when you look back at your history, you understand what each snapshot contains.
If you are working with others or backing up your work to a service like GitHub, the final step is git push, which sends your committed snapshots to the remote copy. But git push only sends commits; it ignores unstaged changes. So the order is always: edit files, git add, git commit, git push.
Many people run these three commands together as a habit: git add ., then git commit -m "message", then git push. This works fine for small projects or when you are the only person working on the code. For larger projects or teams, taking a moment to stage only the files that belong together keeps the history cleaner.
Common mistakes and how to fix them
The most common mistake is running git add . and then committing without checking what you staged. You might accidentally commit a file with passwords, API keys, or personal information. Always run git status before git commit to see exactly what is staged.
Another mistake is staging a file, committing it, pushing it, and then realizing it should not be in your history. Removing it later is possible but messy — you have to rewrite history or create a new commit that deletes it. It is easier to catch the mistake before you push. If you have not pushed yet, git reset HEAD~1 undoes your last commit and unstages the files, letting you fix it.
If you have already pushed, you can create a new commit that removes the file: git rm --cached filename stages the deletion, then git commit and git push send it. The file disappears from future versions, though it remains in the old snapshots. For truly sensitive information like passwords, you should change the password anyway, since it was visible in the history.
Frequently Asked Questions
What is the difference between git add . and git add -A?
git add . stages changes in your current folder and all subfolders. git add -A does the same thing from anywhere in your project. If you are in a subfolder, git add . only stages changes in that subfolder and below, while git add -A stages everything in the entire project. For most people, git add . is sufficient.
Can I undo git add . before I commit?
Yes. Run git reset to unstage everything, or git reset filename to unstage a specific file. The files themselves are not deleted; they just move back to unstaged. You can then stage only the files you want and commit.
What happens if I run git add . twice?
Nothing changes the second time. Once files are staged, running git add . again does not duplicate them or cause problems. If you have made new changes since the first git add ., the second one stages those new changes too.
Do I have to use git add . or can I just commit?
You must stage before you commit. git commit without git add first will fail or commit nothing. Some tools let you skip the staging step with git commit -a, which stages and commits all tracked files in one command, but this removes the safety of reviewing what you are saving.
Why would I ever use git add filename instead of git add .?
When your changes belong in separate snapshots. If you fixed a bug and started a new feature in the same session, staging them separately keeps your history clear and makes it easier to undo one change without losing the other. It also prevents accidentally committing unfinished work.