Monday, 26 May, 2025 9:07 PM
Does Git start tracking the files after adding them into the staging area?
New Section 1 Page 1
Yes, Git starts tracking new files only after they are added to the staging
area using git add
📁 1. New Files (Untracked)
• When you create a new file, Git doesn’t track it initially.
• After you run git add filename, Git starts tracking it.
✏ 2. Modified Files (Tracked)
• For already tracked files, Git automatically notices changes.
• But those changes are not committed until you stage them with git add.
Git File Tracking Lifecycle Diagram If You Modify an Existing File (Tracked File)
[Edit: report.py]
[You create a file: report.py] ↓
(Git notices the change)
↓ ↓
┌──────────────────┐ git add report.py
│ Working Directory│ ↓
(Moves change to Staging)
│ (Untracked File) │ ↓
└──────────────────┘ git commit -m "Updated script"ls
↓ ↓
(Change is saved to Repository)
git add report.py
↓
┌────────────────────┐
│ Staging Area │
│ (File is now │
│ ready to commit) │
└────────────────────┘
↓
git commit -m "Initial commit"
↓
┌────────────────────┐
│ Git Repository │
│ (File is committed │
│ and tracked) │
└────────────────────┘
Git
New Section 1 Page 2
Cd
New Section 1 Page 3
🔑 First, Understand the 3 Git Areas
Before we get into git reset, you need to understand how Git stores your work. Every file goes through
these 3 stages:
Area Description
Working Directory Your actual files on disk. What you see in your code editor.
Staging Area (Index) A temporary place where you gather changes before committing.
Repository (HEAD) Where Git stores permanent commits. HEAD points to the latest commit.
🧪 Sample History: A → B → C → D
Imagine you’ve made 4 commits in a Git repo:
css
CopyEdit
A -- B -- C -- D (HEAD)
You’re currently on commit D. Now you want to go back to commit C using different types of resets.
git reset --so C
📜 Command:
bash
CopyEdit
git reset --soft C
🔍 What happens:
Area What Changes
HEAD ✅ moves to commit C
Staging ✅ keeps changes from D
Working Directory ✅ keeps changes from D
🔁 Git’s internal state:
sql
CopyEdit
HEAD → C
Staging area: contains changes from D
Working directory: contains changes from D
✅ Use When:
You want to undo a commit but keep the changes staged (ready to recommit).
git reset --mixed C (default)
📜 Command:
bash
CopyEdit
git reset C
or
bash
CopyEdit
git reset --mixed C
🔍 What happens:
Area What Changes
HEAD ✅ moves to commit C
Staging ❌ cleared (D’s changes are now unstaged)
Working Directory ✅ keeps changes from D
🔁 Git’s internal state:
sql
CopyEdit
HEAD → C
Staging area: empty
Working directory: contains changes from D
✅ Use When:
You want to undo a commit, and review or modify the changes again before staging.
git reset --hard C
📜 Command:
bash
CopyEdit
git reset --hard C
🔍 What happens:
Area What Changes
HEAD ✅ moves to commit C
Staging ❌ cleared
Working Directory ❌ cleared (D’s changes are deleted)
🔁 Git’s internal state:
pgsql
CopyEdit
HEAD → C
Staging area: empty
Working directory: reset to commit C
🚨 Warning:
This will permanently delete changes from commit D, including any local edits. Use this only if you’re
sure you don’t need them.
✅ Use When:
You want to discard all uncommitted changes and completely revert to a past commit.
🖼 Visual Summary Table
Command HEAD Moves? Staging Area Working Directory Behavior
Summary
--soft ✅ Yes ✅ Keeps D's ✅ Keeps D's changes Undo commit only
changes
--mixed (default) ✅ Yes ❌ Emptied ✅ Keeps D's changes Undo + unstage
--hard ✅ Yes ❌ Emptied ❌ Emptied (lost Full rese
forever)
New Section 1 Page 4
a
New Section 1 Page 5
