Introduction

In Git, adding a directory already works recursively by default. If you run git add path/to/folder, Git stages matching files from that folder and its subdirectories, subject to .gitignore, the current pathspec, and whether you also want deletions included.

The basic recursive add behavior

To stage everything inside a folder tree:

git add path/to/folder

That command walks the directory recursively. You do not need a special "recursive add" flag for normal use.

If you want to stage everything from the current directory downward, use:

git add .

This is why most Git workflows do not mention recursion explicitly. It is built into the directory behavior already.

Know the difference between git add . and git add -A

The command most people want is often not just "add files recursively" but "stage all changes, including deletions."

For that, git add -A is often clearer:

git add -A path/to/folder

Useful distinction:

• 'git add path/to/folder stages new and modified files under that path'
• 'git add -A path/to/folder also stages deletions under that path'

If files were removed and you expect Git to notice, -A is usually the safer choice.

.gitignore still applies

Recursive does not mean unconditional. If a file matches ignore rules, Git will skip it unless you explicitly override that behavior.

For example:

node_modules/
*.log

Then:

git add .

will not stage those ignored files.

If you intentionally need one ignored file, you can force it:

git add -f path/to/file.log

That exception should be used carefully, because it bypasses the ignore policy for that path.

Submodules are different

One common source of confusion is submodules. If a nested directory is a Git submodule, git add . in the parent repository does not recursively stage the submodule's internal file changes as if they were normal files.

Instead:

• you commit changes inside the submodule itself
• then the parent repo records the updated submodule pointer

So if a folder behaves differently from normal recursion, check whether it is a submodule rather than a plain directory.

Review what was staged

After a recursive add, verify the staging area:

git status
git diff --staged

This matters because recursive adds can stage more than you intended, especially when large directory trees contain generated files, local config, or temporary artifacts that were never added to .gitignore.

A safe workflow is:

1. run git add on the intended directory
2. inspect git status
3. adjust .gitignore if necessary
4. unstage anything accidental before committing

That is much better than discovering unwanted files in the commit after the fact.

Common Pitfalls

The biggest mistake is assuming "recursive add" also means "ignore my ignore rules." Git still respects .gitignore unless you force a specific file.

Another mistake is expecting git add . to behave like a magic cleanup command. If deletions matter, use git add -A or verify whether the deleted paths were actually staged.

Developers also forget that submodules are separate repositories. Their changes are not staged recursively as ordinary child files.

Finally, do not blindly stage a whole tree without reviewing git status. Recursive staging is convenient, but it can also pull in generated or secret files you did not mean to commit.

If you are unsure what a broad add will capture, stage a narrower path first and expand from there. That keeps the review surface smaller and makes accidental inclusions easier to catch.

Summary

• 'git add <folder> already adds files recursively under that folder.'
• Use git add -A <folder> when you also want deletions staged under that path.
• '.gitignore rules still apply to recursive adds.'
• Submodules are separate and must be handled in their own repositories.
• Always review the staging area after a broad recursive add.