What Does git add . Do? A Simple Guide to Staging Changes in Git

When you’re working with Git, you’ll quickly run into the command git add .. It’s short, it’s common, and it can be a little confusing if you’re not sure what’s happening behind the scenes.

This guide walks through what git add . actually does, why it matters, how it compares to similar commands, and when its behavior can change depending on your setup.

The basics: what git add . really does

In plain language, git add . tells Git: “Take all my changes in this folder (and its subfolders) and put them in the staging area.”

Three key ideas sit behind that:

1. Your working directory
   This is the set of files and folders you’re editing on disk right now.

2. The staging area (also called the index)
   Think of this as a “pending changes” list. Only staged changes are included in the next commit.

3. A commit
   A snapshot of staged changes, with a message, stored in your Git history.

When you run:

git add . 

Git:

• Looks at the current directory (the dot . means “here”)
• Recursively includes all tracked and new files under this directory
• Adds changes to the staging area, so they’re ready for your next git commit

You haven’t committed anything yet; you’ve just said, “These changes should be in my next commit.”

What exactly gets staged with git add .?

git add . handles different kinds of file changes:

So, if you:

• Edit app.js
• Create notes.txt
• Delete old-config.json

Then run:

git add . 

All three changes are staged together.

How git add . differs from similar commands

There are a few other git add patterns you’ll often see. They look similar, but they behave differently.

git add . vs git add -A vs git add *

1. git add .

• Scopes to the current directory downward
• Stages:
  • Modified tracked files
  • New files
  • Deletions within that directory tree

2. git add -A (or git add --all)

• Acts on the entire repository
• Stages:
  • Modified tracked files
  • New files
  • Deletions anywhere in the repo
• Doesn’t matter which subdirectory you run it from

3. git add *

• Uses the shell’s wildcard, not Git’s pathspec logic
• Only includes visible files in the current directory:
  • No recursion into subdirectories
  • No dotfiles (.env, .gitignore, etc.), unless your shell is set up specially
• Much easier to accidentally skip files you care about

A quick comparison:

Why git add . matters in everyday Git use

1. It defines what goes into your next commit

Git doesn’t automatically commit everything you change. You choose what goes in by staging:

git add . git commit -m "Describe my changes" 

The commit only includes what was in the staging area at that time. git add . is how you quickly say, “Stage everything I just did here.”

2. It lets you build logical, focused commits

You don’t have to stage everything at once. You can:

• Edit multiple files
• Stage only some of them with git add file1.js file2.css
• Leave the rest unstaged for a later commit

But if you do want all the changes in your current directory, git add . is the shortcut that gets you there.

3. It updates the index, not the history

A common misunderstanding is thinking git add . “saves” something permanently. It doesn’t:

• The index (staging area) is temporary and can be changed
• The history (commits) is where things are permanently recorded

You can always adjust:

git reset HEAD file.txt # Unstage just this file git restore file.txt # Throw away local changes in this file (careful!) 

When git add . behaves differently

The exact impact of git add . depends on your environment and habits. Several factors can change what actually gets staged.

Variables that affect what git add . stages

1. Your current working directory

   • Run git add . in the project root: it sees the entire repo tree.
   • Run it in a subfolder: it only operates from that folder downward.

   Example:

   # In /project/src git add . 

   This won’t touch changes in /project/docs or /project/scripts.

2. Your .gitignore and other ignore rules

   Files matching ignore patterns are left alone by git add . (unless you use force options like git add -f).

   Common examples:

   • Build outputs (dist/, build/)
   • Dependency folders (node_modules/, vendor/)
   • Local config (.env, *.log)

3. Whether files are tracked already

   • Tracked files: If Git already knows about the file, changes to it will be staged by git add ..
   • Untracked files: Brand new files are added and staged.
   • Ignored files: Normally skipped.

   So two users in the same repo, but with slightly different .gitignore rules or histories, can see different sets of files staged by the same git add . command.

4. Your Git version and configuration

   • Modern Git versions handle pathspecs (.) in consistent, documented ways.
   • Some global or repo configs can subtly shift behavior (for example, how line endings are stored, or how renames are detected), which can affect what Git sees as a “change” to be staged.

5. Operating system and filesystem behavior

   • Case sensitivity: On case-insensitive filesystems (common on Windows and some macOS setups), renaming File.txt to file.txt can behave differently than on Linux.
   • Permissions/executable bits: Some filesystems treat permissions differently, which can influence which changes Git thinks need staging.

Different user profiles, different experiences with git add .

The core meaning of git add . doesn’t change, but how practical or “safe” it feels can vary a lot depending on how and what you’re developing.

1. Beginner vs. experienced Git user

• Beginner:

  • Often uses git add . as a quick “add everything” tool.
  • Might accidentally stage files that shouldn’t be committed (temporary notes, large test data, IDE settings).
  • May not check what’s staged with git status or git diff --staged.

• Experienced user:

  • Uses git add . deliberately, often after confirming the working tree state.
  • Sometimes prefers more selective commands:
    • git add -p to stage only parts of a file
    • Explicit filenames for fine-grained control

The behavior is the same, but the workflow around it looks very different.

2. Small script projects vs. large monorepos

• Small project (few files, one or two folders):

  • git add . typically stages exactly what you expect—there just isn’t much there.
  • Less risk of accidentally committing big, generated directories.

• Large monorepo (many services, tools, generated files):

  • git add . from the repo root can stage a lot more than you intended.
  • Developers might:
    • Run it only from specific subdirectories
    • Use .gitignore heavily to avoid noise
    • Prefer git add -p or explicit paths

The bigger and more complex the repo, the more you feel the blast radius of git add ..

3. Different tech stacks and build setups

• Frontend with bundlers and build outputs

  • Build tools generate bundles, maps, and cache directories.
  • If .gitignore isn’t set up well, git add . can pull in these large, noisy files.

• Back-end code with compiled artifacts

  • Compiled binaries, logs, temporary data can accumulate.
  • Solid ignore rules are essential to keep git add . focused on source code.

• Data-heavy projects (data science, ML)

  • Massive datasets and model files may live alongside source code.
  • The difference between staging a few KB and several GB hinges on:
    • Folder layout
    • Ignore patterns
    • Where you run git add . from

Same command, very different risk profile.

4. Solo vs. team workflows

• Solo developer

  • May accept “messier” commits and use git add . more casually.
  • Fewer concerns about confusing others with noisy diffs.

• Team / shared repo

  • Commit quality, readability, and size matter more.
  • People tend to:
    • Stage changes more selectively
    • Avoid committing editor configs or local environment files
    • Coordinate on shared .gitignore and conventions

Again, git add . doesn’t change, but expectations around how it should be used do.

The missing piece: your own setup and habits

At its core, git add . stages all changes under your current directory so they’re ready to be committed. That part is consistent.

What varies is:

• Where in the repo you usually run it
• How well your .gitignore files are maintained
• How big and complex your project structure is
• Whether you prefer quick “everything at once” commits or carefully curated ones
• How much risk you’re comfortable with if extra files are accidentally staged

Understanding these moving parts is what turns git add . from a mysterious incantation into a predictable tool. The remaining question is how it fits into your own workflow, with your current repository layout, team practices, and comfort level with Git’s staging features.