What Version Control Is and Why Git

Sooner or later every developer asks: "what did I change yesterday that broke everything?", "how do I get back the version that worked last week?", "how can two people edit one project without overwriting each other's work?". The answer is a version control system (VCS) — a program that keeps the history of every change in a project. Today the industry standard is Git: almost every company uses it, and working with it is checked in practically every job interview.

The "final_v2_final" problem

Without version control, a project folder sooner or later starts to look like this:

my-site/
├── index.html
├── index_old.html
├── index_backup_12_09.html
├── index_final.html
├── index_final_v2.html
├── index_final_v2_FINAL.html
└── index_final_v2_FINAL_Murad_fixes.html

It is unclear which version is current, how the copies differ, and who changed what and why. You can only go back to a copy you remembered to make, and when two people work together they have to send archives back and forth and copy each other's changes by hand.

A version control system solves this differently: the folder keeps a single index.html, and the history is stored separately. Each saved point in the history is called a commit. A commit stores the state of the files, the author, the date and a message describing what was changed and why:

Commit 3   Aysel   12.09   "Add contact form"
Commit 2   Murad   10.09   "Fix mobile menu"
Commit 1   Aysel   08.09   "Create site structure"

A project together with the database of its entire history is called a repository ("repo").

Local, centralized and distributed systems

Local VCSs (for example, RCS from 1982) kept the history on a single computer: working together was awkward, and a disk failure destroyed everything.

Centralized systems (CVS, SVN, Perforce) keep the full history on one server, and developers get only the current version of the files from it. Without a network you can neither record a change in the history nor look at it; if the server is down, the whole team is stuck. SVN (Subversion) can still be found in older corporate projects and in game development.

Distributed systems (Git, Mercurial) give every developer a full copy of the repository with the entire history. Committing, browsing history and creating branches all work offline, and the server is needed only to exchange changes. If the server disappears, the history can be restored from any team member's computer.

 Centralized (SVN)                     Distributed (Git)

       [ Server ]                           [ Server ]
       (history)                            (history)
      /    |     \                         /    |     \
[Aysel] [Murad] [Leyla]              [Aysel]  [Murad]  [Leyla]
 files   files   files               history  history  history
                                     + files  + files  + files

Snapshots instead of a list of differences

Many older systems store the first version of a file and then a chain of changes to it. Git thinks in snapshots: on every commit it records what the whole project looked like. To save space, unchanged files are not copied — the new snapshot simply points to the version that is already stored.

             index.html     style.css     app.js
Commit 1  →  index v1       style v1      app v1
Commit 2  →  index v2       style v1 ↺    app v1 ↺
Commit 3  →  index v2 ↺     style v2      app v1 ↺

↺ — the file has not changed: Git does not copy it, it points to the stored version

That is why any version of the project can be retrieved in full and quickly, and every snapshot is protected by a checksum — a hash such as 9d03f5a…: if data gets corrupted, Git will notice. The details come in the "Git Internals" section.

Git is not GitHub

Git is a program that runs on your computer. Linus Torvalds created it in 2005 for developing the Linux kernel. Git is free, open source, and works without the internet or any account.

GitHub, GitLab and Bitbucket are online services (hosting platforms) that store copies of Git repositories. They add tools for teams: pull requests, code review, issues, CI/CD.

An analogy: Git is a camera that takes pictures of your project, and GitHub is a cloud album where you discuss them with your team. You can take pictures without an album.

💡 "What is the difference between Git and GitHub?" is a common interview question. Short answer: Git is a version control tool; GitHub is a service for hosting repositories and collaborating on top of Git.

Project history as a time machine

This is what the history of a small real project looks like in the terminal (we will cover the commands later; for now just look at the result):

git log --oneline

e41b7c2 (HEAD -> main, origin/main) Merge pull request #12 from aysel/contact-form
9d03f5a Validate contact form fields
6ab2e18 Add contact form
3c7f9e0 Fix mobile menu overlap
b58d41a Add course cards section
71e2c9d Add header and navigation
0f3a6b4 Initial commit: project structure

Each line is one commit, newest first. On the left is the short hash (a unique identifier), on the right is the message. HEAD -> main shows where you are now, and origin/main shows which state is on the server. You can open any commit and see exactly what changed in it:

 <nav class="menu">
-  <a href="#about">About</a>
+  <a href="#about">About us</a>
+  <a href="#contact">Contact</a>
 </nav>

Lines starting with - were removed, lines with + were added — this view is called a diff. Thanks to the history you can return a file to any earlier state and find the commit that introduced a bug.

The path of a change: from edit to main

In a team, every change follows the same path (each step has its own topics in this course):

1. Edit           you change files in your editor
      ↓
2. Commit         you record a snapshot in your local repository
      ↓
3. Push           you send your commits to the server (for example, GitHub)
      ↓
4. Pull request   you ask the team to review the changes
      ↓
5. Merge          after code review the changes land in the main branch

Steps 1–2 happen only on your computer: until you push, your colleagues cannot see your commits. A pull request is a feature of the hosting platform, not of Git itself (GitLab calls it a merge request): that is where colleagues discuss the code and press the merge button.

Common mistakes

1. "Git and GitHub are the same thing." Git works completely locally, without an account or the internet. GitHub is just one of the places you can send a copy of your repository to.
2. "Version control is only for teams." Even on your own, Git lets you experiment safely and roll back failed changes, and public repositories are part of a developer's portfolio.
3. "I committed, so my code is safe." A commit lives only on your disk until you send it to a server. If your laptop dies before you push, the commits are gone.
4. Storing everything in the repository. Passwords, .env, node_modules and large videos do not belong in Git: the history remembers everything forever (more in the .gitignore topic).
5. One huge commit a week. A time machine only works if the history has stops along the way. Commit in small, logical steps.

Summary

• A version control system keeps the history of changes: who changed what, when and why.
• A commit is a saved snapshot of the project with an author, a date and a message; a repository is the project together with its whole history.
• Centralized systems (SVN) keep the history on a server; distributed systems (Git) keep it on every developer's machine.
• Git stores snapshots of the whole project and does not duplicate unchanged files.
• Git is a program on your computer; GitHub, GitLab and Bitbucket are hosting platforms with team tools.
• The typical path of a change: edit → commit → push → pull request → merge into main.

Practice

1. Find a folder on your computer with files named like "final", "copy" or "old". Write down which problems from this lesson you have already run into.
2. Open a popular open-source project on GitHub (for example, vuejs/core) and go to its list of commits. Find the author, date and message of the latest commit, open it and look at the diff.
3. Draw a diagram of a three-developer team for a centralized and a distributed system. Answer in writing: what happens in each case if the server is down for a whole day?
4. You and a friend are building a landing page for a café in Baku. Describe in 5–7 steps how the change "add a menu section" travels from your editor to the main branch, using the words: commit, push, pull request, code review, merge.

💡 The free book Pro Git on the official Git website is an excellent reference for the whole course.