Imagine writing an important document. You save the first draft as report_v1.docx. After making edits, you save a new copy: report_v2.docx. Soon, your folder is a mess of files like report_final.docx and report_final_actually_final.docx. It’s confusing, and going back to a specific previous version is a nightmare.

Software development is like this, but a thousand times more complex. Multiple people work on the same code simultaneously. A small change can break everything. How do teams manage this chaos? They use a version control system, or VCS.

A VCS is like a time machine for your project. It records a snapshot of your files every time you save a change. This history allows you to review older versions, compare differences, and revert mistakes without losing progress. For a team, it’s essential. It lets developers work on different features at the same time and then merge their changes together smoothly.

Version control systems generally come in two flavors: centralized and distributed. Understanding the difference is key to seeing why modern tools like Git are so powerful.

A Centralized Version Control System (CVCS) uses a single, central server to store the entire project history. Developers “check out” files from this server to work on them and then “check in” their changes. It’s a simple model, like a library where everyone borrows books from one main desk.

A Distributed Version Control System (DVCS) is different. Instead of just checking out the latest version of files, every developer gets a full copy of the entire project history on their local machine. The central server is still there, but it acts more like a primary point of contact than a single source of truth.

The distributed model has several big advantages. Because everyone has a full history, you can work offline, committing changes locally without needing a network connection. It's also faster, since most operations happen on your own computer. If the central server goes down, you still have your complete local copy, making data loss much less likely. This structure is built for collaboration and resilience.

Git is the most popular distributed version control system in the world. Created by Linus Torvalds, the same mind behind the Linux operating system, Git was designed for speed, simplicity, and powerful, non-linear workflows.

At its core, Git thinks about data as a series of snapshots. Every time you save your work, or commit, Git takes a picture of what all your files look like at that moment and stores a reference to that snapshot. It doesn't store the differences between files, but rather the full file content. If files haven't changed from one version to the next, Git simply links to the previous identical file it has already stored. This makes it incredibly efficient.

This snapshot-based architecture is what enables Git's powerful features like branching and merging, which we'll explore later. It allows developers to create isolated experimental timelines (branches) and then easily integrate their work back into the main project. It's the foundation of modern, collaborative software development.

Time to check your understanding of these foundational concepts.

This knowledge sets the stage for everything that comes next. Now that you know what version control is and why Git is structured the way it is, you're ready to start using it.