git-stage

View documentation for the original command

$ tldr git add

git add [options] [--] [pathspec...]
git add -A | --all
git add -u | --update

-A, --all
    Stage all changes from all tracked and untracked files in the working directory, including new files, modifications, and deletions.

-u, --update
    Stage modifications and deletions for files that are already tracked. New, untracked files are ignored.

-p, --patch
    Interactively select and stage specific hunks of changes within files, providing fine-grained control over what gets staged.

.
    A common pathspec indicating to stage all changes in the current directory and its subdirectories. Similar to --all when executed from the repository root.

...
    Specifies one or more files or directories to stage. Only changes within these specified paths will be added to the index.

-n, --dry-run
    Perform a 'dry run'; show what would be staged without actually modifying the index or working tree.

-f, --force
    Allows adding files that match ignore rules defined in .gitignore or similar configurations.

-N, --intent-to-add
    Record only the fact that the path will be added later. The file content is not staged, but its path is marked for addition.

While git-stage is not a standalone executable command in Git, it conceptually refers to the act of preparing changes from the working directory to be included in the next commit. This crucial step is primarily performed by the
git add command.

The staging area, also known as the index, acts as a temporary buffer between your working directory and your repository. When you make modifications to files, create new files, or delete existing ones, these changes are initially in your working directory.

Using git add (or 'staging' them) moves these specific changes into the staging area. This allows you to meticulously craft your next commit by selecting only the relevant modifications. You can stage a subset of changes from a file, add newly created files, or mark files for deletion. Only changes present in the staging area will be recorded when you execute git commit. This flexibility is a core strength of Git's workflow, enabling clean, focused commits.

The command git-stage is not a direct executable Git command. The actual operation of staging changes is performed by git add.

git add prepares changes for a commit; it does not itself create a commit. You must run git commit afterwards.

Be cautious with git add . or git add -A, as they stage all detected changes, potentially including unfinished work you didn't intend to commit.

Once changes are staged, they can be unstaged using commands like git restore --staged <file> or git reset <file>.

The staging area, also known as the index, is a unique feature of Git that provides an intermediate buffer between your working directory and your repository. It allows you to build up a commit incrementally by selecting specific changes from various files, rather than committing all modifications at once. This enables more precise and logical commits.

To stage all changes (new, modified, deleted) in the current directory and subdirectories:
git add .

To stage a specific file:
git add <filename>

To stage all modified and deleted files (but not new untracked files):
git add -u

To interactively select parts of files to stage:
git add -p

The concept of staging changes is fundamental to Git's design, introduced from its inception by Linus Torvalds. The git add command has been a core component since the very first versions of Git, serving the purpose of populating the index (staging area) with desired changes for the next commit. Its functionality has remained largely consistent, reflecting its foundational role in Git's unique workflow.

git add(1), git commit(1), git status(1), git restore(1), git reset(1)