How Version Control Works: Git Explained for Beginners

Saving a file preserves its current contents. It does not automatically preserve a clear history of how the file changed, why it changed, or which version still worked before a problem appeared.

That distinction becomes especially important in AI-assisted development.

A coding assistant can modify several files in seconds. Some changes may be useful, while others may introduce errors, remove existing behavior, or affect parts of the project you did not intend to change. Without version control, it can be difficult to understand what happened or return to a stable state.

Git solves this problem by recording meaningful checkpoints in a project’s history.

This article explains how Git works conceptually before we begin using Git commands in the next guide.

What You Will Learn

By the end of this guide, you should be able to explain:

• what version control is;
• how Git differs from ordinary file saving;
• what a working directory is;
• what the staging area does;
• what a commit represents;
• how branches create separate lines of development;
• how local and remote repositories differ;
• why Git is especially valuable in vibe coding workflows.

You do not need to memorize commands yet. The goal is to build a mental model that makes later Git commands easier to understand.

What Version Control Means

Version control is a system for recording changes to files over time.

It allows you to compare versions, identify who made a change, understand why the change was made, and return to an earlier state when necessary.

Imagine writing a document without version control.

You might create files such as:

project-final
project-final-2
project-final-revised
project-final-revised-new
project-final-revised-new-fixed

This approach creates several problems.

You may not remember:

• which version is actually current;
• what changed between copies;
• which version contains a bug;
• whether two copies contain different useful changes;
• which version another person is using.

Git replaces that informal collection of copies with a structured history.

Instead of duplicating the whole project manually, Git records selected changes as commits.

A simplified history might look like this:

A ── B ── C ── D

Each letter represents a commit.

For example:

A: Create initial project
B: Add navigation
C: Add contact form
D: Fix form validation

The project history now has a clear sequence.

You can inspect what changed between commits, return to an earlier point, or create a separate branch to experiment without immediately changing the main line of development.

Git Is Not the Same as Saving a File

Saving and committing are related, but they solve different problems.

When you save a file, your editor writes the current contents to storage.

When you create a Git commit, Git records a checkpoint based on selected project changes.

Suppose you edit three files:

index.html
styles.css
notes.md

You save all three files.

At that point, the changes exist on your computer, but Git has not necessarily recorded them as a commit.

You may decide that only index.html and styles.css belong to the current feature. The notes file may be unrelated.

Git allows you to select the relevant changes before recording the checkpoint.

This is one reason a commit is more useful than a simple backup copy. A good commit represents a meaningful unit of work.

Examples include:

• add a search form;
• fix a navigation bug;
• update installation instructions;
• remove an unused dependency;
• add tests for input validation.

A commit should help a future reader understand what changed and why.

The Three Main Areas in a Basic Git Workflow

A beginner-friendly Git model has three main areas:

1. the working directory;
2. the staging area;
3. the repository history.

The basic flow looks like this:

Working directory
       ↓
Staging area
       ↓
Commit history

Each area has a different purpose.

The Working Directory

The working directory is the project folder you can see and edit.

It contains the current versions of files such as:

README.md
index.html
app.js
styles.css

When you open a project in VS Code and change a file, you are changing the working directory.

For example, suppose app.js originally contains:

function greet(name) {
  return `Hello, ${name}`;
}

You edit it to:

function greet(name) {
  if (!name) {
    return "Hello";
  }

  return `Hello, ${name}`;
}

The saved file is now different from the last committed version.

Git can detect that difference.

However, the change is not yet a new commit. It is only a modification in the working directory.

The Working Directory Can Contain Mixed Work

The working directory may contain several kinds of changes at once.

For example:

• a completed bug fix;
• an unfinished feature;
• a temporary debugging statement;
• a documentation update;
• a generated file;
• an accidental configuration change.

This is normal during development.

The staging area exists partly because not every current change should automatically become part of the same commit.

The Staging Area

The staging area is where you select the changes that should be included in the next commit.

It is sometimes described as a preparation area or an index.

Suppose you changed:

app.js
styles.css
notes.md

The JavaScript and CSS changes belong to a user-interface improvement. The notes file contains personal reminders.

You may stage only:

app.js
styles.css

Then create a commit describing the interface improvement.

The notes file remains modified in the working directory but is not included in that commit.

This gives you control over the project history.

Why the Staging Area Matters

Without a staging area, Git would have to record every current change together.

That would encourage large, confusing commits.

A useful commit should normally contain changes that belong together.

For example:

Good commit:
Add validation to the contact form

This commit may include:

contact-form.js
contact-form.test.js

A less useful commit might combine:

• contact form validation;
• color changes;
• documentation edits;
• package updates;
• unrelated debugging code.

The staging area helps separate these concerns.

Staging Is Not a Permanent Save

Staging a file does not create a permanent history entry.

It only prepares the selected version for the next commit.

You can still change the file again before committing.

That creates an important distinction:

Working directory version
Staged version
Last committed version

A single file can temporarily have all three states.

For example:

1. You edit a file.
2. You stage it.
3. You edit it again.

Now Git may see:

• one set of changes already staged;
• another set of newer changes still only in the working directory.

This can seem confusing at first, but it gives experienced developers precise control over what enters a commit.

For beginners, a simpler habit is often better:

1. finish one small task;
2. review the files;
3. stage the relevant changes;
4. commit;
5. begin the next task.

The Commit History

A commit is a recorded checkpoint in a Git repository.

A commit normally includes:

• the selected file changes;
• the author identity;
• the date and time;
• a commit message;
• a unique identifier;
• a connection to the previous commit.

This creates a chain of project history.

A simplified history might look like:

A ── B ── C

Each commit knows which commit came before it.

That relationship allows Git to reconstruct earlier states and compare one point in history with another.

A Commit Is More Than a Snapshot Name

A commit is often explained as a snapshot, which is useful for beginners.

However, Git stores project history efficiently. It does not behave like a folder full of complete manual copies.

From a practical perspective, you can think of each commit as a recoverable project state with a message explaining its purpose.

For example:

a83f21c Add README
b4e9d72 Add form layout
c12a8f4 Validate empty email input

The short strings are abbreviated commit identifiers.

Git can use those identifiers to inspect or reference specific points in history.

Good Commit Messages Matter

A commit message should explain the purpose of the change.

Weak messages:

Update
Fix
Changes
Work

Better messages:

Add empty-state message to task list
Fix duplicate form submission
Document WSL setup requirements
Remove unused API client

A future reader should be able to scan the history and understand how the project evolved.

This becomes especially important when AI tools generate changes quickly. A clear commit history helps distinguish intentional work from experiments and failed attempts.

A Repository Is the Project Plus Its History

A Git repository contains the project and the version-control information Git uses to track it.

When Git is initialized in a project folder, it creates internal repository data.

You normally do not edit that internal data manually.

The repository allows Git to answer questions such as:

• Which files have changed?
• Which changes are staged?
• What was the previous version?
• Who created a commit?
• Which branch is active?
• How does the local history differ from the remote history?

The repository is not only the visible source files.

It also includes the structured history behind them.

Local Repositories and Remote Repositories

A local repository exists on your computer.

A remote repository exists somewhere else, such as GitHub.

The local repository contains the history available on your machine. You can create commits locally without an internet connection.

The remote repository provides a shared or off-device copy of the Git history.

A common relationship looks like this:

Your computer
└── Local Git repository
        ↓ push
GitHub
└── Remote Git repository

What Push Means

A push sends local commits to a remote repository.

It does not simply upload the current folder as a random collection of files. It transfers Git history that the remote does not yet have.

What Pull Means

A pull retrieves remote changes and integrates them into the local repository.

This matters when:

• you work on more than one computer;
• another developer changes the project;
• an automated service modifies repository files;
• you edit a file directly on GitHub.

The Remote Is Not Automatically Current

A common beginner assumption is that GitHub updates whenever a local file is saved.

It does not.

The typical sequence is:

Edit files
→ Stage changes
→ Commit locally
→ Push commits

Until the push occurs, the new commits may exist only on your computer.

Similarly, a change made on GitHub does not automatically appear in your local folder. You must retrieve it.

What a Branch Is

A branch is a separate line of development.

The default branch usually represents the main project history.

You can create another branch to work on a feature or experiment without immediately changing the default branch.

A simplified branch history looks like this:

main:       A ── B ── C
                  \
feature:           D ── E

The feature branch started from commit B.

Commits D and E belong to the feature branch, while commit C belongs to the main branch.

Later, the feature may be merged back:

main:       A ── B ── C ───── F
                  \           /
feature:           D ── E ───

Commit F represents the integration of the feature work.

Why Branches Are Useful

Branches allow you to:

• build a feature separately;
• test an experiment;
• fix a bug without interrupting other work;
• review changes before integration;
• keep unfinished work away from the stable branch.

In AI-assisted development, branches can provide an additional safety boundary.

For example, you might create a branch before asking a coding agent to perform a large refactoring. If the result is poor, the main branch remains unchanged.

Branches Are Not Full Project Copies

A branch may feel like a duplicate project, but Git manages branches more efficiently than manually copying the entire folder.

Branches are references to lines of commit history.

This allows developers to switch between different project states without maintaining folders such as:

app-main
app-feature
app-feature-new
app-feature-final

The Git commands article will later show how branches are managed in practice. For now, the important point is that branches separate work without abandoning version history.

How Git Detects Changes

Git compares the current project state with recorded or staged versions.

It may classify files as:

• untracked;
• modified;
• staged;
• committed.

Untracked

An untracked file exists in the working directory but has not yet been added to Git’s tracked history.

Example:

new-notes.md

Git sees the file but does not assume it belongs in the repository.

This prevents every temporary file from being recorded automatically.

Modified

A modified file was previously tracked, but its current contents differ from the last relevant recorded version.

Example:

README.md

You changed the file after the last commit.

Staged

A staged change has been selected for the next commit.

Committed

A committed change has been recorded in repository history.

A file can move through these states:

Untracked
   ↓
Staged
   ↓
Committed
   ↓
Modified
   ↓
Staged
   ↓
Committed

Understanding these states makes Git commands much easier to interpret.

Git Is Not Exactly the Same as a Backup System

Git protects project history, but it should not be treated as the only backup strategy.

A local Git repository may be lost if the storage device fails.

A GitHub repository provides an off-device copy, but remote repositories can also be deleted, corrupted through forceful history changes, or made inaccessible through account problems.

For important projects, consider:

• a local repository;
• a remote repository;
• protected access;
• account recovery methods;
• organization-level backup policies;
• separate backups when required.

Git is primarily a version-control system. It is excellent at tracking project changes, but complete disaster recovery may require additional measures.

Why Git Matters More in Vibe Coding

AI coding tools can produce changes faster than most developers can inspect them manually.

That speed is useful, but it creates risk.

An AI assistant may:

• modify several files;
• rename functions;
• add dependencies;
• change configuration;
• remove code it considers unnecessary;
• introduce a solution that works only for one case;
• edit files unrelated to the request.

Git gives you evidence.

Before an AI change, you can create a clean checkpoint.

After the change, you can inspect exactly what differs.

A safe loop looks like:

Start from a clean repository
→ Create or confirm a checkpoint
→ Ask the AI for one small change
→ Inspect modified files
→ Test the result
→ Commit only when verified

This workflow is more reliable than repeatedly asking the AI to repair its own edits without preserving known-good states.

Git Does Not Review the Code for You

Git can show what changed. It does not decide whether the change is correct.

You still need to ask:

• Does the new behavior match the requirement?
• Did unrelated files change?
• Were tests added or updated?
• Did a secret enter the repository?
• Did the AI remove important error handling?
• Can the application still run?
• Is the change small enough to understand?

Git provides the history and comparison tools. Human judgment remains responsible for accepting the result.

A Practical Mental Model

You can summarize the basic Git workflow with four questions.

What Have I Changed?

This refers to the working directory.

You inspect which files differ from the last known state.

What Will Go Into the Next Commit?

This refers to the staging area.

You select the changes that belong together.

What Have I Already Recorded?

This refers to commit history.

You review the checkpoints already stored in the repository.

What Exists Somewhere Else?

This refers to remote repositories.

You compare the local history with GitHub or another remote location.

The full model looks like this:

Working directory
    ↓ select changes
Staging area
    ↓ create checkpoint
Local commit history
    ↓ share commits
Remote repository

If you understand this sequence, commands such as add, commit, and push become much less mysterious.

Common Beginner Misunderstandings

“I Saved the File, So Git Recorded It”

Saving changes the working file.

Git records the change only after it is staged and committed.

“GitHub Is Git”

Git is the version-control system.

GitHub is a hosting and collaboration platform built around Git repositories.

“A Commit Uploads My Code”

A commit records changes locally.

A push sends local commits to a remote repository.

“Everything Modified Must Go Into One Commit”

The staging area allows you to select only related changes.

“A Branch Is a Backup Folder”

A branch is a separate line of commit history, not a manually duplicated project directory.

“Private Repositories Make Secrets Safe”

A private repository reduces visibility but is not a proper secret-management system.

Credentials should still be excluded and protected.

“Git Can Automatically Decide Which AI Changes Are Good”

Git shows differences and history.

It cannot determine whether the implementation is correct, secure, or appropriate.

A Beginner-Friendly Checkpoint Strategy

When using Git with AI coding tools, create commits at meaningful points.

Useful times to commit include:

• after the initial project setup;
• before asking an AI agent for a significant change;
• after one feature works and has been tested;
• after fixing a specific bug;
• after updating documentation for a completed change;
• before experimenting with a different approach.

Avoid waiting until the end of the day to create one enormous commit containing unrelated work.

A clearer history might look like:

Create initial project structure
Add task input form
Store tasks in memory
Add empty-state message
Fix duplicate task submission
Document local setup

This sequence is easier to review and recover than:

Finish app

Verify Your Understanding

Before moving to the command tutorial, make sure you can explain the following in your own words:

• A working directory contains the files you are currently editing.
• The staging area selects changes for the next commit.
• A commit records a checkpoint in local history.
• A branch creates a separate line of development.
• A local repository exists on your computer.
• A remote repository may exist on GitHub.
• Saving, committing, and pushing are different actions.
• Git tracks changes, but it does not judge whether code is correct.
• Small commits make AI-generated changes easier to review.

You do not need perfect terminology yet. You need a clear picture of how a change moves from an edited file into project history.

Conclusion

Git works by separating current work from recorded history.

You edit files in the working directory. You select relevant changes in the staging area. You create commits in the local repository. You use branches when work needs its own line of development. You push commits when you want to share them with a remote repository such as GitHub.

• Previous article: How to Create Your First GitHub Repository

The most important distinction is that saving a file is not the same as recording a checkpoint.

For vibe coding, this distinction is essential. AI tools can make changes quickly, but Git gives you a controlled way to inspect, organize, and reverse those changes.

The next article will turn this mental model into a practical workflow using essential commands such as clone, status, add, commit, log, push, and pull.

Frequently Asked Questions

Do I need GitHub to use Git?

No.

Git can track files and create commits entirely on your computer. GitHub is useful when you want an online remote repository, collaboration features, or off-device project history.

Does Git save every file automatically?

No.

Git detects changes, but you choose which files to stage and commit. Files can also be excluded using .gitignore.

How often should I create commits?

Create a commit when one small, meaningful unit of work is complete and verified.

In AI-assisted development, committing before a risky change and after a successful result creates useful recovery points.

• Next article: Git Basics: Clone, Add, Commit, and Push