📁 Chapter 5: File States Explained — Git's "Lifecycle"

The Four States of Files

In the world of Git, every file has four possible states, like a person's daily routine —

┌──────────┐     git add      ┌──────────┐    git commit   ┌──────────┐
  │ Untracked │ ──────────────→  │ Staged   │ ─────────────→  │Committed │
  │           │                  │          │                 │          │
  └──────────┘                  └──────────┘                 └──────────┘
       ↑                            │                              │
       │         Edit file          │                              │
       │    ┌───────────────────────┘                              │
       │    │                                                      │
       │    ▼                                                      │
       │  ┌──────────┐          Modify committed file              │
       │  │ Modified  │ ←──────────────────────────────────────────┘
       │  │           │
       │  └──────────┘
       │       │
       │       │ git restore / git checkout
       │       ▼
       │    (Discard changes)
       │
       │  git rm --cached
       └────────────────────  (Becomes untracked)

State	Meaning	Real-life Analogy
Untracked	New file that Git doesn't know about yet	Fresh fruit on the counter, not yet in the fridge
Modified	A tracked file has been changed	Dish taken out of the fridge with the recipe modified
Staged	Changes placed in the staging area, waiting to be committed	Dish plated, ready to be served
Committed	Safely stored in the Git database	Finished product archived, save point created

Hands-on Demo: File State Transitions

# Scenario: developing "My First Website"

# 1. Create a new file — Untracked
echo 'body { color: blue; }' > style.css
git status
On branch main
Untracked files:
  (use "git add <file>..." to include in what will be committed)
        style.css
nothing added to commit but untracked files present

# 2. Add to staging area — Staged
git add style.css
git status
On branch main
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        new file:   style.css

# 3. Commit — Committed
git commit -m "feat: add base styles"
[main b2c3d4e] feat: add base styles
 1 file changed, 1 insertion(+)
 create mode 100644 style.css

# 4. Modify a committed file — Modified
echo 'body { color: red; font-size: 16px; }' > style.css
git status
On branch main
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   style.css

.gitignore — Tell Git "Don't Track These"

Some files you don't want Git to track, like build artifacts, log files, password configs, etc. This is where the .gitignore file comes in.

# Create .gitignore file
cat > .gitignore << 'EOF'
# Dependency directories
node_modules/
vendor/

# Build artifacts
dist/
build/
*.o
*.pyc

# Logs
*.log
logs/

# OS files
.DS_Store
Thumbs.db

# IDE files
.vscode/
.idea/
*.swp

# Environment variables (never commit passwords!)
.env
.env.local
EOF

⚠️ Warning: There's a big pitfall here that I learned the hard way — if a file is already tracked by Git, adding it to .gitignore won't work! You need to first remove it from Git's tracking: git rm --cached <file>. This is especially important for .env files — if you accidentally committed a password, even if you delete it later, it can still be found in the history. Always create .gitignore at the very beginning of your project!