If you have ever staged a commit and then stared at git status like it betrayed you trust me you are not alone. The difference between git add -A and git add . is small in wording and dramatic in consequences. One looks at the whole working tree and the other mindfully ignores whatever is outside your current folder.

Quick overview

Here is the cliff notes version for the people who like living dangerously but not permanently.

• git add -A updates the index across the entire repository. New files modified files and deletions anywhere in the repo get staged.
• git add . updates the index for the current directory and its subdirectories. Changes outside the current path are ignored.
• git add -u updates tracked files only. No new files are added but deletions and modifications to tracked files are staged.

Why this actually matters

Run the command from the project root and both commands behave similarly for most casual use. Run it from a nested folder and suddenly a deletion elsewhere in the project will sneak into your commit if you used -A. That has ruined more commits than any single keyboard shortcut deserves.

Real world examples

# Stage everything across the repo
git add -A

# Stage only the current folder and below
git add .

# Update tracked files only without adding new files
git add -u

# Check before you wreck yourself
git status

Practical advice for sane devs

If you are cleaning up deleted files or want your index to match the entire working tree pick git add -A. If you are focused on one subfolder maybe a Python package or a small feature in a monorepo and want to avoid unrelated deletions use git add .. If you only want to update tracked files choose git add -u.

• Use git status before staging to preview what will change
• Run a small test commit if you are unsure and then amend if needed
• For CI pipelines on GitHub or GitLab prefer explicit paths so you do not accidentally include unrelated changes

Tips for teams and devops

In team settings set clear conventions. Ask yourself what your repo layout is like. Monorepos often benefit from path based staging to keep commits focused. Smaller repos might prefer the global approach to avoid orphaned deletions.

Quick workflow checklist

• Run git status
• Decide scope for the commit
• Use git add . for local folder work or git add -A for repo wide changes
• Use git add -u when you only want to update tracked files
• Review with git diff --staged if you enjoy pain free commits

Follow these and you will avoid committing deletions from the other side of the repo. You will also be a little less tempted to blame your tools the next time something vanishes. Bonus points if you add the habit of checking pull requests on GitHub or GitLab before merging. That is responsible devops behavior and also useful for pretending you always knew what you were doing.

Short recap The global option covers the whole working tree while the path based option respects current directory boundaries. Pick the one that matches your scope for the next commit and use git status to avoid surprises.