The three states in Git (modified, staged, committed)

The Three States in Git (Modified, Staged, Committed)

When managing files, Git categorizes them into one of three basic states: modified, staged, and committed. Understanding these states and their transitions is core to mastering Git workflows.

Modified State

The modified state indicates that files have been changed in the working directory but are not yet tracked by Git. At this stage, changes exist only in the local working copy and are not yet under Git's version control.

// Example: Modifying a component file in a frontend project
// src/components/Button.js
import React from 'react';

- function Button({ text }) {
+ function Button({ text, onClick }) {
  return (
-   <button>{text}</button>
+   <button onClick={onClick}>{text}</button>
  );
}

Common scenarios include:

1. Editing source code file contents
2. Renaming or moving files
3. Deleting files

Check modification status with:

git status
# Sample output:
# Changes not staged for commit:
#   modified:   src/components/Button.js

Staged State

The staged state means changes have been marked for the next commit. Use the git add command to move changes from the working directory to the staging area.

# Stage a single file
git add src/components/Button.js

# Stage all changes
git add .

Purpose of staging area:

• Selective committing: Only stage specific changes
• Batch committing: Break large changes into logical commits
• Preview commits: View upcoming changes with git diff --cached

// Continuing modifications after staging creates new unstaged changes
// src/components/Button.js
function Button({ text, onClick }) {
  return (
    <button 
      onClick={onClick}
+     className="primary-btn"
    >
      {text}
    </button>
  );
}

Check current status:

git status
# Sample output:
# Changes to be committed:
#   modified:   src/components/Button.js
#
# Changes not staged for commit:
#   modified:   src/components/Button.js

Committed State

The committed state means changes are securely stored in Git's local database. Use git commit to permanently store staged content as Git objects.

git commit -m "Add onClick prop to Button component"

Characteristics of commits:

• Generates unique SHA-1 hash identifiers (e.g., a1b2c3d)
• Creates new commit objects containing author, timestamp, and message
• Moves current branch pointer to the new commit

View commit history:

git log --oneline
# Sample output:
# a1b2c3d (HEAD -> main) Add onClick prop to Button component
# e4f5g6h Initial project setup

State Transition Practice

Complete workflow example:

1. Modify CSS file:

/* src/styles.css */
- body { margin: 0; }
+ body { margin: 0; font-family: 'Arial'; }

2. Check status:

git status
# Changes not staged for commit...

3. Stage changes:

git add src/styles.css

4. Modify file again:

/* src/styles.css */
body { 
  margin: 0; 
  font-family: 'Arial';
+ background: #f5f5f5;
}

5. Commit initial changes:

git commit -m "Update base font family"

6. Process remaining changes:

git add src/styles.css
git commit -m "Add page background color"

Advanced State Management

Partial staging:

# Interactive staging
git add -p src/components/Button.js

Undoing changes:

# Discard working directory changes
git checkout -- src/components/Button.js

# Unstage changes (keep working directory)
git reset HEAD src/components/Button.js

Visualization tools:

gitk
git gui

Relationship Between States and Branches

When switching branches, Git automatically handles file states based on commit status:

# New branches inherit current commit state
git checkout -b new-feature

# Branch switching may change working directory files
git checkout main

Uncommitted changes may persist during branch switches or cause conflicts, while committed changes are permanently associated with specific commit objects.