Save the modified files temporarily

Staging Modified Files

Staging modified files in Git is a core operation that allows developers to commit changes from the working directory to the repository in batches. The Staging Area, as a buffer layer between the working directory and the repository, provides more granular version control capabilities.

The Nature of the Staging Area

The Staging Area is an abstract concept of the .git/index file, which records the current snapshot of files to be committed. When executing the git add command, Git will:

1. Calculate the SHA-1 hash of the file
2. Store the file content in the object database (.git/objects)
3. Update the index file records

# View the contents of the staging area (low-level command)
git ls-files --stage

Basic Staging Operations

Staging a Single File

git add README.md

This command saves the current state of README.md in the working directory to the staging area. If the file has been staged before, Git will update the file version in the staging area.

Staging Multiple Files

# Stage all .js files
git add *.js

# Stage all files in the src directory
git add src/

Interactive Staging

git add -p

Interactive mode displays file diff chunks (hunks) one by one, allowing you to choose:

• y: Stage the current chunk
• n: Do not stage
• s: Split into smaller chunks
• e: Manually edit the chunk

Advanced Staging Techniques

Staging Partial File Modifications

// Example file: utils.js
function calculate(a, b) {
  // Change 1: Fix addition logic
  return a + b;
}

// Change 2: Add multiplication function
function multiply(x, y) {
  return x * y;
}

Using git add -p, you can stage only the addition logic fix without including the new function:

Stage this hunk [y,n,q,a,d,e,?]? y   # Choose to stage the addition fix
Stage this hunk [y,n,q,a,d,e,?]? n   # Do not stage the multiplication function

Unstaging Changes

# Remove a single file from the staging area (keep working directory changes)
git reset HEAD file.txt

# Use path-specific unstaging
git restore --staged src/app.js

Handling Special Scenarios

Staging Deleted Files

When a file is manually deleted, you need to explicitly inform Git:

rm obsolete.js
git add obsolete.js  # or use git rm

Staging Renamed Files

Git automatically detects renames, but explicit operations are more reliable:

git mv old-name.txt new-name.txt

Skipping the Staging Area

Although you can bypass staging and commit directly, it is not recommended:

git commit -a -m "Commit all changes directly"

Status Checks and Comparisons

Viewing Staged Differences

git diff --cached

Displays the differences between the staging area and the last commit.

Working Directory vs. Staging Area

git diff

Shows unstaged changes in the working directory.

Automated Staging Patterns

Using .gitignore to Exclude Files

Create a .gitignore file to avoid accidentally staging files:

# Ignore log files
*.log

# Ignore dependency directories
node_modules/

Pre-commit Hook Automation

Add a script to .git/hooks/pre-commit to automatically format staged files:

#!/bin/sh
git stash -q --keep-index
npm run lint-staged
RESULT=$?
git stash pop -q
exit $RESULT

Exploring Underlying Principles

The actual storage format of the staging area can be viewed using low-level commands:

git ls-files --stage
100644 7f96a28f7a4d1d2a3e4d5c6b7a8f9e0d1c2b3a4 0       README.md

Field meanings:

1. File permission mode
2. SHA-1 hash of the file content
3. Staging number
4. File path

Cross-Platform Considerations

For Windows systems, note the following:

• Case sensitivity in filenames
• Automatic line ending conversion (core.autocrlf)
• Long path support (requires enabling core.longpaths)

git config --global core.autocrlf true