git add

You've just finished making changes to several files, but you don't want to commit everything at once. Maybe some changes are ready to go while others are still experimental, or perhaps you want to group related changes into separate commits. This is where git add comes in. It's the command that tells Git which changes you want to include in your next commit, moving them from your working directory to the staging area.

Think of the staging area as a preparation zone for your commit. When you modify a file, Git notices the change but doesn't automatically include it in your next commit. You have to explicitly add it with git add. This might seem like an extra step, but it gives you precise control over what goes into each commit. You can make changes to ten files but only commit five of them, keeping your commit history clean and focused.

The most straightforward use is git add filename.js, which stages all changes to that specific file. If you've modified auth.ts and you're happy with those changes, running git add auth.ts prepares them for commit. The file moves to the staging area, and Git will include those changes when you run git commit. You can add multiple files at once with git add file1.js file2.ts file3.css, which is handy when you've made related changes across several files.

Staging Patterns and Options

A common pattern is staging everything at once with git add . or git add -A. The dot version stages all changes in the current directory and its subdirectories, while -A stages everything in the entire repository. Teams often use these when all their changes belong together in a single commit. But be careful—it's easy to accidentally stage files you didn't mean to include, like debug logs or temporary test files. Always run git status first to see what you're about to stage.

Sometimes you want to stage parts of a file but not everything. You've made two unrelated changes to the same file, and they should really be in separate commits. Running git add -p filename.js starts an interactive session where Git shows you each change and asks if you want to stage it. You can respond with 'y' to stage a section, 'n' to skip it, or 's' to split it into smaller pieces. This is incredibly useful for maintaining a clean commit history where each commit has a single, clear purpose.

Working with New and Deleted Files

When you create a new file, Git sees it as "untracked"—it knows the file exists, but it's not part of the repository yet. Running git add newfile.js tells Git to start tracking the file and stages it for your next commit. After that first commit, Git tracks the file automatically, and future changes only need to be staged, not the file itself.

Deleting files works similarly. If you delete a file from your filesystem, Git notices it's missing but doesn't automatically stage the deletion. You need to run git add deleted-file.js to stage the deletion for commit. Alternatively, you can use git rm filename.js, which deletes the file and stages the deletion in one step. Most developers use git add -A after deleting files since it catches all changes including deletions.

Pull Request Workflows

In pull request workflows, staging becomes part of how you tell your story. Each commit in your PR should make sense on its own, solving one problem or adding one feature. By carefully choosing what to stage, you create a series of commits that reviewers can follow logically. Instead of one massive commit that changes 50 files, you might make five commits that each focus on a specific aspect of your feature.

Some teams use Git hooks that run checks when you stage files, like linters or formatters. When you run git add, these hooks might automatically fix formatting issues or warn you about problems. If a hook modifies files, you might need to run git add again to stage the fixes before committing.

The staging area gives you a chance to review your changes before committing them. After staging files with git add, you can run git diff --staged to see exactly what you're about to commit. This is your last chance to catch mistakes before they become part of your repository history. You can also unstage files with git reset filename.js if you realize you staged something by mistake.

Understanding git add means understanding that commits are intentional snapshots of your work, not automatic saves. You choose what to include, when to include it, and how to organize your changes into meaningful units. This control is what makes Git powerful for collaboration—each commit can tell a clear story about what changed and why.