Why Version Control? Core Concepts of Git

Learning Objectives

By the end of this lesson you will be able to:

• Explain what a version control system (VCS) is and why it matters.
• Distinguish between centralized and distributed version control.
• Define Git's core objects: repository, commit, working directory, staging area.
• Explain the three-state model that Git uses to track files.

What Problem Does Version Control Solve?

When you write software, documents, or configuration files, you change them repeatedly. Without a system to track those changes, teams resort to practices such as saving files as report_final_v2_reallyfinal.docx. This approach fails at scale: you cannot easily see who changed what, when, or why, and you cannot safely revert to an earlier state if a change breaks something.

A version control system (VCS) is software that records changes to a set of files over time, so you can recall specific versions later, compare changes, and merge work done by multiple people. Git, created by Linus Torvalds in 2005 to manage the Linux kernel source code, is currently the most widely used VCS in professional software development.

Centralized vs. Distributed Version Control

In Git, when you clone a repository, you receive a complete copy of the project's history, not just the latest snapshot. This means you can commit, branch, and inspect history entirely offline; you only need network access to synchronize with others (via push and pull).

Git's Three-State Model

Git tracks files through three conceptual areas:

1. Working directory: the actual files on disk that you edit.
2. Staging area (index): a holding area where you place changes you intend to include in your next commit.
3. Repository (.git directory): where Git permanently stores committed snapshots as objects, along with metadata (branches, tags, configuration).

A file's change goes through this pipeline: you modify it in the working directory, you stage it (git add), then you commit it (git commit), which records a permanent snapshot in the repository.

Working Directory -- git add --> Staging Area -- git commit--> Repository (.git)

Snapshots, Not Diffs

A common misconception is that Git stores a series of file-based diffs, like some older systems. Instead, each commit in Git stores a snapshot of the entire project at that point in time. If a file has not changed between commits, Git stores a reference to the identical file it already has, rather than storing it again. This design makes operations like branching and checking out old versions fast, because Git does not need to reconstruct a file from a chain of patches.

Every commit is identified by a SHA-1 hash (a 40-character hexadecimal string, e.g. e83c5163316f89bfbde7d9ab23ca2e25604af290) computed from the commit's content and metadata. This hash guarantees integrity: if any bit of the commit's data changes, the hash changes too.

Common Mistakes at This Stage

• Confusing Git with GitHub. Git is the version control tool that runs on your machine; GitHub (and similar platforms like GitLab or Bitbucket) is a hosting service for Git repositories that adds collaboration features. You can use Git fully without ever touching GitHub.
• Assuming you need constant network access. Because Git is distributed, most day-to-day work (viewing history, committing, branching) happens locally.
• Believing commits are diffs. As explained above, commits are snapshots, though Git compresses storage efficiently behind the scenes.

Recap

• Version control systems track changes to files over time and enable collaboration and recovery.
• Git is a distributed VCS: every clone has the complete project history.
• Git manages three areas: working directory, staging area, and repository.
• Commits are snapshots identified by SHA-1 hashes, not incremental diffs.
• Git and GitHub are different things: Git is the tool, GitHub is a hosting platform.