Staging Changes with Control

Staging is the act of selecting changes for the next commit. The git add command does not permanently save a version; it moves selected changes from the working directory into the staging area.

The staging area exists so that a commit can be deliberate. You can review a group of changes, include only the ones that belong together, unstage mistakes, and then commit the final selection.

Suppose a repository contains two modified files and one new folder containing a new file. Git status may report the older files as modified and the new folder as untracked.

To stage every change across the repository, use either:

git add --all

or:

git add -A

These two forms perform the same role in the workflow described here: they stage all detected changes across the project.

To stage changes under the current directory, use:

git add .

The dot means the current directory and everything beneath it. The command's scope therefore depends on where you are when you run it.

If you run git add . from the repository root, it can stage changes throughout the project tree. If you first enter a subdirectory and run the same command there, only changes in that directory and its descendants are selected.

The asterisk form behaves differently:

git add *

In the demonstrated workflow, this stages visible new or modified paths matched from the current directory, but a deleted file remains unstaged. This makes the asterisk form less complete than --all, -A, or a correctly scoped dot when deletions must also be included.

You can also stage a specific file:

git add 1.txt

Or a file at a path:

git add my-folder/3.txt

A filename pattern can select files by extension in the current directory:

git add *.txt

In the demonstrated use, this stages matching text files in the current directory, while files in nested folders and deleted files are not included by that pattern.

To move staged changes back out of the staging area without discarding the working-directory edits, use:

git reset

After reset, the files remain modified, new, or deleted in the working directory, but they are no longer selected for the next commit.

This is useful when a broad add command included too much or when you want to reorganize the next commit.

A commit should represent a coherent saved change. The staging area gives you a checkpoint before permanence.

Without this intermediate step, every modified file would be committed together whether or not the changes belonged to the same task. Staging allows you to separate unrelated work and verify what will be recorded.

The command form matters because different forms have different scopes. A broad command can be efficient when all current changes belong together. A specific path is safer when only part of the working directory should be committed.

Use the following review loop:

1. Run git status to inspect all pending changes.
2. Choose a staging scope.
3. Run the appropriate git add command.
4. Run git status again to verify what moved into the staging area.
5. If the selection is wrong, run git reset and stage again more precisely.

Example: stage the whole repository from its root.

git status git add . git status

Example: stage only one file.

git add 1.txt git status

Example: stage a file inside a folder.

git add my-folder/3.txt git status

Example: stage everything, reconsider, and return the changes to the working directory.

git add --all git status git reset git status

Use git add --all or git add -A when every detected project change belongs in the next commit.

Use git add . when you intentionally want the current directory and its descendants.

Use an exact file path when you want precise control.

Use a pattern such as *.txt only when its current-directory scope matches your intent.

After any broad staging operation, use git status as the verification step rather than assuming the selection is correct.

Broad staging is fast but can group unrelated changes.

Narrow staging provides control but requires more commands.

The current directory changes the meaning of git add ., so running the command from the wrong location can stage less than expected.

The asterisk and extension patterns do not behave like a complete repository-wide selection in the demonstrated workflow. Deleted files or nested files may remain outside the staging area.

Git reset removes changes from staging, but it does not, by itself, erase the working-directory edits. Discarding edits requires a different command and a separate decision.

Git add selects the content of the next commit. Choose the command form according to scope, confirm the result with git status, and use git reset when the staging selection needs to be rebuilt.