How files move between three areas in Git - Mechanics & Internals

Overview - How files move between three areas

What is it?

In Git, files move through three main areas: the working directory, the staging area, and the repository. The working directory is where you edit files. The staging area is like a waiting room where you prepare changes before saving them permanently. The repository is where Git stores the final saved versions of your files.

Why it matters

This system helps you control exactly what changes get saved and shared. Without these areas, you might accidentally save unfinished work or lose track of changes. It makes collaboration and version control clear and safe.

Where it fits

Before learning this, you should understand basic file editing and saving on your computer. After this, you can learn about branching, merging, and remote repositories to collaborate with others.

Mental Model

Core Idea

Files flow from your workspace to a preparation stage, then to permanent storage, letting you control when and what changes are saved.

Think of it like...

It's like writing a letter: you draft it on your desk (working directory), put it in an envelope ready to send (staging area), and finally drop it in the mailbox to be delivered (repository).

Working Directory ──> Staging Area ──> Repository
       (edit files)       (prepare commit)    (save permanently)

Build-Up - 7 Steps

1

Foundation

Understanding the Working Directory

Concept: The working directory is where you create and change files on your computer.

When you start a Git project, your files live in the working directory. You can open, edit, add, or delete files here using your normal tools like text editors or IDEs.

Result

You have files on your computer that are not yet tracked or saved by Git.

Knowing the working directory is where you do your actual work helps you understand that Git starts tracking changes only after you tell it to.

2

Foundation

Introducing the Repository

Concept: The repository is where Git stores the history of your project safely.

Git keeps a hidden folder called .git in your project. This folder holds all the saved versions of your files and the history of changes you commit.

Result

Your project has a place to save snapshots of your work permanently.

Understanding the repository as a safe storage for your project history explains why Git can let you go back to old versions anytime.

3

Intermediate

Role of the Staging Area

🤔Before reading on: do you think Git saves changes directly from your edits to the repository, or is there a middle step? Commit to your answer.

Concept: The staging area is a middle step where you prepare which changes to save next.

After editing files, you use 'git add' to move changes to the staging area. This tells Git exactly which changes you want to include in your next commit.

Result

Changes are marked ready but not yet saved permanently.

Knowing about the staging area explains how Git lets you control and group changes before saving, avoiding accidental commits.

4

Intermediate

Moving Files with git add

🤔Before reading on: does 'git add' copy your file changes or just mark them? Commit to your answer.

Concept: 'git add' marks changes from the working directory to be included in the next commit.

When you run 'git add filename', Git takes a snapshot of that file's current state and places it in the staging area. This snapshot is what will be saved when you commit.

Result

The staging area now holds the exact version of the file you want to save.

Understanding that 'git add' snapshots files clarifies why you can keep editing files after adding them without changing the staged version.

5

Intermediate

Saving Changes with git commit

🤔Before reading on: does 'git commit' save all your working directory changes or only staged ones? Commit to your answer.

Concept: 'git commit' saves the staged changes permanently to the repository.

Running 'git commit -m "message"' takes everything in the staging area and stores it as a new snapshot in the repository. This snapshot becomes part of your project history.

Result

Your changes are now permanently saved and tracked by Git.

Knowing commits save only staged changes helps prevent confusion about what is actually recorded in your project history.

6

Advanced

Unstaging and Resetting Changes

🤔Before reading on: can you remove files from the staging area without deleting your edits? Commit to your answer.

Concept: Git lets you undo staging or discard changes before committing.

You can run 'git reset filename' to remove a file from the staging area but keep your edits in the working directory. Or use 'git checkout -- filename' to discard changes and restore the last committed version.

Result

You regain control to adjust what will be committed or revert unwanted edits.

Understanding how to unstage or discard changes prevents accidental commits and helps maintain clean project history.

7

Expert

How Git Stores Data Internally

🤔Before reading on: do you think Git stores whole files each commit or just differences? Commit to your answer.

Concept: Git stores data efficiently using snapshots and compression.

Internally, Git saves a snapshot of all files at each commit, but it uses compression and links to previous snapshots to save space. The staging area holds these snapshots temporarily before committing.

Result

Git can quickly switch versions and keep history without wasting space.

Knowing Git's internal storage explains why staging snapshots are crucial and why Git is fast and efficient even with many commits.

Under the Hood

Git tracks file changes by creating snapshots of the entire project at each commit. The working directory holds your current files. When you run 'git add', Git copies the current state of files into the staging area as a snapshot. 'git commit' then takes these staged snapshots and stores them permanently in the repository database. This design allows Git to manage versions efficiently and lets you control exactly what changes are saved.

Why designed this way?

Git was designed to be fast, reliable, and flexible for developers working alone or in teams. The three-area model lets users prepare commits carefully, avoid mistakes, and keep a clean history. Alternatives like saving every change immediately or tracking only differences were slower or less flexible. This design balances control and performance.

┌───────────────┐      git add       ┌───────────────┐      git commit      ┌───────────────┐
│ Working Dir   │ ────────────────> │ Staging Area  │ ────────────────> │ Repository    │
│ (edit files)  │                   │ (prepare)     │                   │ (save history)│
└───────────────┘                   └───────────────┘                   └───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does 'git add' save your changes permanently? Commit yes or no.

Common Belief: Many think 'git add' saves changes permanently to the project history.

Reality: 'git add' only stages changes; the commit is what saves them permanently.

Why it matters: Confusing staging with committing can cause people to think their work is saved when it is not, risking data loss.

Quick: Does 'git commit' include all your current edits automatically? Commit yes or no.

Common Belief: Some believe 'git commit' saves all changes in the working directory automatically.

Reality: Only changes that have been staged with 'git add' are included in a commit.

Why it matters: This misunderstanding leads to incomplete commits and confusion about what changes are tracked.

Quick: Does Git store only file differences internally? Commit yes or no.

Common Belief: Many think Git stores only the differences (deltas) between file versions to save space.

Reality: Git stores full snapshots of the project at each commit but uses compression and linking to save space.

Why it matters: Knowing this helps understand why staging snapshots are important and why Git is fast despite storing full snapshots.

Quick: Can you remove a file from staging without losing your edits? Commit yes or no.

Common Belief: Some assume removing a file from staging deletes their changes.

Reality: You can unstage files and keep your edits intact in the working directory.

Why it matters: This knowledge prevents accidental loss of work when adjusting commits.

Expert Zone

1

The staging area can hold different versions of the same file if you add it multiple times before committing, allowing fine-grained control.

2

Git's index (staging area) is a binary file that stores metadata and file snapshots, enabling fast operations and partial commits.

3

You can stage parts of a file (hunks) instead of the whole file using 'git add -p', which is powerful for clean commits.

When NOT to use

The three-area model is core to Git, but for very simple version control needs, tools like 'git commit -a' skip staging. In some workflows, direct commits or other version control systems like Mercurial or SVN might be preferred for simplicity.

Production Patterns

In professional projects, developers carefully stage changes to group related edits into meaningful commits. Continuous integration systems rely on clean commit histories. Advanced users use partial staging and amend commits to keep history tidy.

Connections

Transactional Databases

Both use staging and commit phases to ensure data integrity.

Understanding Git's staging and commit is like database transactions: prepare changes, then commit to make them permanent, ensuring consistency.

Drafting and Publishing in Writing

Git's areas mirror drafting (working), editing (staging), and publishing (commit).

Seeing Git as a writing process helps grasp why you prepare changes before finalizing them.

Project Management Kanban Boards

The flow from working directory to staging to repository is like moving tasks from To Do to In Progress to Done.

This connection shows how breaking work into stages improves control and clarity.

Common Pitfalls

#1 Committing without staging changes first.

Wrong approach:

git commit -m "Update files"

Correct approach:

git add .
git commit -m "Update files"

Root cause:

Misunderstanding that commits only include staged changes, so no changes get saved if nothing is staged.

#2 Assuming 'git add' copies changes permanently.

Wrong approach:

git add file.txt
# then close editor and lose changes

Correct approach:

git add file.txt
git commit -m "Save changes"

Root cause:

Confusing staging with committing leads to lost work if changes are not committed.

#3 Editing files after staging and expecting staged version to update automatically.

Wrong approach:

git add file.txt
# edit file.txt again
# commit

Correct approach:

git add file.txt
# edit file.txt again
git add file.txt
git commit -m "Updated file"

Root cause:

Not realizing staging snapshots the file at the time of 'git add', so later edits are not included unless staged again.

Key Takeaways

Git uses three areas—working directory, staging area, and repository—to manage file changes carefully.

The working directory is where you edit files; the staging area prepares changes; the repository stores commits permanently.

'git add' moves changes to staging, and 'git commit' saves staged changes to the repository.

Understanding these areas helps prevent accidental data loss and keeps your project history clean and organized.

Advanced Git users leverage staging to create precise, meaningful commits and maintain efficient workflows.

Practice

1. Which command moves files from the working directory to the staging area in Git?

easy

A. git add

B. git commit

C. git push

D. git clone

Solution

1. Step 1: Understand the role of git add

   The git add command moves files from the working directory to the staging area, preparing them for commit.

2. Step 2: Differentiate from other commands

   git commit saves staged files to the local repository, git push sends commits to a remote, and git clone copies a repository.

3. Final Answer:

   git add -> Option A

4. Quick Check:

   Staging area update = git add [OK]

Hint: Add files to staging with git add [OK]

Common Mistakes:

• Confusing git add with git commit
• Thinking git push moves files locally
• Using git clone to stage files

2. Which of these commands correctly saves staged files to the local repository?

easy

A. git commit -m "Save changes"

B. git status

C. git add .

D. git init

Solution

1. Step 1: Identify the commit command

   git commit -m "message" saves the staged files into the local repository with a message.

2. Step 2: Understand other commands

   git add . stages files, git status shows status, and git init creates a new repo.

3. Final Answer:

   git commit -m "Save changes" -> Option A

4. Quick Check:

   Save staged files = git commit [OK]

Hint: Commit staged files with git commit -m [OK]

Common Mistakes:

• Using git add instead of git commit to save
• Confusing git status with commit
• Trying to commit without staging files

3. Given these commands run in order:

echo "Hello" > file.txt
git add file.txt
git commit -m "Add file"

Where is file.txt after these commands?

medium

A. Only in the working directory

B. In the local repository and working directory

C. Deleted from all areas

D. In the staging area only

Solution

1. Step 1: Create and stage the file

   The file is created in the working directory, then moved to the staging area by git add.

2. Step 2: Commit the file

   git commit saves the staged file to the local repository. The file remains in the working directory.

3. Final Answer:

   In the local repository and working directory -> Option B

4. Quick Check:

   Commit saves staged files, working files remain [OK]

Hint: Committed files stay in repo and working directory [OK]

Common Mistakes:

• Thinking commit removes file from working directory
• Believing staged files disappear after commit
• Confusing staging area with repository

4. You ran git commit -m "Update" but Git says "nothing to commit". What is the likely cause?

medium

A. You committed files but did not push

B. You are in the wrong directory

C. You forgot to stage files with git add

D. You need to run git init again

Solution

1. Step 1: Understand the message meaning

   "Nothing to commit" means no changes are staged for commit.

2. Step 2: Identify missing staging step

   If you forgot git add, no files are staged, so commit has nothing to save.

3. Final Answer:

   You forgot to stage files with git add -> Option C

4. Quick Check:

   Stage files before commit = git add [OK]

Hint: Stage files first with git add before commit [OK]

Common Mistakes:

• Thinking commit auto-stages files
• Confusing push with commit
• Assuming git init fixes this error

5. You edited app.js in your working directory. You want to save only this file to the local repository without including other changes. Which sequence of commands correctly moves app.js through Git's three areas?

hard

A. git add . then git commit -m "Save app.js"

B. git commit -m "Save app.js" then git add app.js

C. git push then git add app.js

D. git add app.js then git commit -m "Save app.js"

Solution

1. Step 1: Stage the specific file

   Use git add app.js to move only app.js to the staging area.

2. Step 2: Commit the staged file

   Run git commit -m "Save app.js" to save the staged changes to the local repository.

3. Final Answer:

   git add app.js then git commit -m "Save app.js" -> Option D

4. Quick Check:

   Stage then commit specific file = git add + git commit [OK]

Hint: Add specific file before commit to save only it [OK]

Common Mistakes:

• Committing before adding files
• Using git push instead of commit
• Adding all files instead of just one