After modifying files in your working directory or creating new ones, Git needs to know which specific changes you want to include in the next snapshot, or commit. This is where the concept of the staging area (sometimes called the index) comes into play. Think of the staging area as a preparation space where you gather all the changes you intend to save together in the next commit.

The command used to add changes to this staging area is git add. It tells Git, "Take the current state of this file (or these files) and prepare it for the next commit." This step is significant because it allows you to selectively choose which modifications become part of the project's history. You might make several edits but only want to group related changes into a single, logical commit.

Staging Individual Files

The most common way to use git add is to specify the exact file(s) you want to stage. If you've modified a file named README.md and created a new file main.py, you can stage the changes in README.md like this:

git add README.md

If you run git status now, you'll see that README.md has moved from the "Changes not staged for commit" section (or "Untracked files" if it was new and just added) to the "Changes to be committed" section. The file main.py would still be listed as unstaged or untracked.

Staging Multiple Files

You can stage multiple specific files by listing them after the git add command:

git add README.md main.py styles.css

This command stages the current state of all three listed files.

Staging All Changes

Often, you'll want to stage all modifications and new files within your current working directory and its subdirectories. You can achieve this using a period (.) which represents the current directory:

git add .

This command looks at all files from the current directory downwards. It stages:

Modifications to already tracked files.
Newly created files.

Be mindful when using git add . It adds everything in the current path, so ensure you don't accidentally stage temporary files, build outputs, or sensitive information that should ideally be listed in your .gitignore file (which we discussed previously).

Another common option is git add -A (or git add --all):

git add -A

This command stages all changes throughout the entire repository, regardless of your current directory. This includes modifications, new files, and deleted files. While powerful, use it with the same caution as git add . to avoid staging unintended changes.

Visualizing the Workflow

The git add command is the bridge between your working directory and the staging area, preparing changes for the final step of saving them to the repository history with git commit.

The git add command moves changes from the Working Directory to the Staging Area. Subsequent git commit operations save the contents of the Staging Area to the Repository.

Remember, git add doesn't save changes permanently in the history; it only prepares them. You still need to use git commit (covered next) to record the staged snapshot into the repository's timeline. Running git add multiple times before a commit is perfectly normal; each execution adds the specified file's current state to the staging area, overwriting any previously staged version of that same file.

Was this section helpful?