How to Recursively Add Files and Folders in Git

Git stages file changes in the index, the area Git uses to prepare the next commit. To include files inside nested directories, use git add with a repository-wide or directory path. The command stages changes; it does not create a commit or send anything to a remote repository.

How git add Stages Files Recursively

When you give git add a directory path, Git stages eligible changes under that path, including files in its subdirectories. You can also stage changes across the working tree with git add -A or use git add . to stage changes from the current directory downward. These commands do not require a separate recursive option.

The path matters: a command run from a subdirectory only addresses the path scope described by that command. Choose the repository root when you intend to stage the whole repository, or name a directory when you want a narrower selection. Ignore rules still apply to untracked files unless you deliberately override them.

Stage All Changes from the Repository Root

To stage changes throughout a repository, first move to its root directory, then run git add -A. It stages additions, modifications, and deletions throughout the working tree. This is useful when you have changed files in several parts of a project and want one consistent repository-wide selection.

Run this self-contained example from a shell with Git installed. It creates a temporary repository, adds two nested files, stages the changes from its root, and prints the short status. The temporary directory is removed when the script finishes.

work_dir="$(mktemp -d)"
trap 'rm -rf "$work_dir"' EXIT
cd "$work_dir"
git init -q
mkdir -p src/lib
printf 'app\n' > README.md
printf 'module\n' > src/lib/module.txt
git add -A
git status --short

Use git add . when you specifically want to stage changes from the current directory downward. From the repository root, that normally covers the same working-tree paths as git add -A. From a subdirectory, git add . is limited to that directory and its descendants, while git add -A stages changes across the repository. If you want a predictable whole-repository selection, run git add -A at the root.

Stage a Specific Directory

To limit staging to one project area, run git add path/to/directory/ from the repository root, replacing the example path with the directory you want. Git includes eligible added and modified files below that path. A directory path also lets Git stage tracked files removed from that directory, so the index reflects those deletions.

This narrower choice is useful when unrelated work is present elsewhere in the working tree. Check that the path names the intended directory before staging; git add records the selected changes in the index, not in a separate copy of the directory. If you need to stage just one file, pass its file path instead.

Handle Ignored Files

A .gitignore file tells Git which untracked paths to leave out of ordinary staging. For example, a pattern such as *.log can keep generated log files out of git add -A, git add ., and directory-based staging. Ignore rules are useful for build output, local settings, and other files that should not enter commits.

If a specific ignored file should be tracked, inspect why it is ignored, then deliberately stage that path with git add -f path/to/file. The force option overrides ignore rules for the path you specify. Use it only when that file belongs in the repository; forcing generated or private files into the index can expose unwanted content. Adding a pattern to .gitignore also does not remove a file that Git already tracks.

Review Staged Changes Before Committing

After staging, run git status to see which paths are staged and whether other changes remain unstaged. For a concise view, git status --short marks staged paths in the first status column and unstaged changes in the second. Review the list before creating a commit, especially after repository-wide staging, and confirm that no ignored or unrelated files were included.

Staging is only preparation for a commit. A commit records the staged snapshot in local repository history; pushing is a separate operation that sends commits to a remote. You can stage recursively without committing or pushing, and you can revise the index by staging the intended paths before you commit.