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.