Every open source project on GitHub, and almost every serious software project anywhere, runs on Git. Yet Git remains one of the most misunderstood tools in software: beginners confuse it with GitHub, fear merge conflicts they do not understand, and type commands they memorized without knowing what they do. This guide fixes that. You will learn what version control actually is, how Git tracks your work under the hood, why it beat every competitor, and how Git differs from GitHub.
Key Takeaways
Version control records every change to your files over time, so you can revisit any point in history, see who changed what, and experiment without fear.
Git stores your history as snapshots of the whole project, not as lists of differences, and every file is checksummed with a 40-character SHA-1 hash.
Git is distributed: your machine holds the entire project history, so committing, branching, and browsing history all work offline and fast.
A branch is just a lightweight pointer to a commit, which is why creating and merging branches is cheap and central to how teams work.
Git is the version control tool; GitHub is one of several platforms that host Git repositories online. They are not the same thing.
Adoption is overwhelming: Git is the most widely used version control system in the world, and Git's official site notes that 96% of professional developers use it, per the 2022 Stack Overflow developer survey.
What Version Control Actually Is
Version control, also called source control, is the practice of tracking and managing changes to source code over time. Atlassian's tutorial names three core benefits: a complete long-term change history of every file, branching and merging, and traceability of who changed what, when, and why.
Think of it as a time machine for your project. Every meaningful change gets saved as a checkpoint you can return to. If a new feature breaks everything, you rewind. If you wonder who introduced a bug and why, the history tells you. If you want to try a risky idea, you branch off, experiment freely, and either merge it back or throw it away. No more folders named `final-v2-REALLY-FINAL`.
How Git Stores Your Work: Snapshots, Not Diffs
Older version control systems like CVS and Subversion stored your history as a set of file changes: for each file, they recorded what differed from the previous version. Git does something different. Pro Git, the official book, explains that Git stores data as snapshots: every time you commit, Git takes a picture of what all your files look like at that moment and stores a reference to that snapshot. If a file did not change between commits, Git does not store it again; it just links to the previous identical file.
This design has two big consequences. First, almost every Git operation is local and fast, because Git has the entire history right there on your machine. Second, everything in Git is checksummed. Every file and every commit is identified by a 40-character hexadecimal SHA-1 hash, so nothing can change without Git noticing. A commit is simply, in freeCodeCamp's beginner guide, "a version of your project," and the hash is its tamper-proof name.
Git files move through three states that beginners should know: modified (you changed the file in your working directory), staged (you marked it to go into the next commit), and committed (it is safely stored in the Git database). These correspond to three parts of every Git project: the working tree (your files), the staging area (the index, where you assemble the next commit), and the Git directory (the repository itself).
Commits, Branches, and Merging
A branch is, in freeCodeCamp's words, "a pointer to a commit." That sounds abstract, but it is the reason Git branching is so powerful: creating a branch does not copy files or duplicate anything. It just creates a tiny pointer you can move forward as you commit. That is why Git encourages branching for everything, a new feature, a bug fix, an experiment.
Teams often follow a branch-based workflow. GitHub Docs describes the GitHub flow as "a lightweight, branch-based workflow that supports teams and projects that deploy regularly": create a branch, make changes, open a pull request, review, merge. Merging brings the changes from one branch into another, combining the two lines of history. Most merges happen automatically; when Git cannot reconcile two conflicting edits to the same lines, it flags a merge conflict and asks a human to decide, which is far less scary than it sounds once you see it a few times.
Here is a typical small workflow in five commands:
git init # start tracking a folder git add . # stage all changes git commit -m "Add login page" # save a snapshot git branch dark-mode # create a branch (a pointer to the commit) git merge dark-mode # merge the branch back in
Why Git Is Distributed (and Why That Matters)
Git is a distributed version control system. Atlassian explains the key difference: with Git, every developer's copy of the repository contains the full project history, not just a working copy of the latest files. That makes operations like committing, browsing blame and diffs, or reading the log dramatically faster than with centralized systems, because your machine is not asking a server for permission. As Pro Git puts it, "most operations in Git need only local files and resources to operate," so "there is very little you can't do if you're offline."
This is also why the What Is Open Source model works so well with Git: thousands of strangers can each hold a complete, trustworthy copy of a project's entire history, propose changes from their own copies, and have maintainers merge the good ones. That architecture is what lets a project like the Linux kernel absorb contributions from all over the world without a central gatekeeper slowing anyone down.
Aspect | Git (distributed) | Centralized VCS (SVN, CVS) |
|---|---|---|
Detail | Every clone holds the full project history | Only the server holds the full history |
Commits | Local and instant; you can work fully offline | Each commit needs a server connection |
Branching | Cheap pointers, so teams branch and merge constantly | Expensive copies, so branching is rare and merging is dreaded |
Speed | Most operations run on local files | Most operations wait on the network |
Examples | Git | Subversion, CVS |
Git vs GitHub: Not the Same Thing
This is the most common confusion, and GitHub's own beginner guide (by Kedasha Kerr, 2024-05-27) states it plainly: "Git is a version control system that tracks file changes and GitHub is a platform that allows developers to collaborate and store their code in the cloud."
Put simply: Git is the tool on your computer that tracks history. GitHub is one website where you can publish that history so others can view, fetch, and contribute to it. freeCodeCamp adds the memorable line: "GitHub is not Git. GitHub is just a hosting service," alongside alternatives like GitLab and Bitbucket. GitHub Docs notes that at the heart of GitHub is the Git system running locally on your computer; pushing a local repository to a remote publishes your commits so collaborators can fetch and build on them.
A Short History: Built for the Linux Kernel in 2005
Git was created by Linus Torvalds in 2005 for Linux kernel development, after the proprietary tool the kernel community had been using changed its licensing terms. Atlassian's Git hub records the origin: "Git is a free and open-source version control system, originally created by Linus Torvalds in 2005."
It was built for extremes. Git's about page says Git was "built to handle repositories with tens of millions of lines of code from the start." The numbers are striking: as of 2025, the Linux kernel source is 1.7 GB, and its entire history, 1.4 million commits, compresses to just 5.5 GB. A tool designed for that scale is more than fast enough for your project.
Git's popularity exploded in the early 2010s, when hosting services like GitHub and GitLab made sharing repositories effortless, and Git itself is free and open source under the GNU GPL v2.0. Today Atlassian calls Git "the most widely used version control system in the world today and is considered the modern standard for software development."
Why Developers Adopted It
The adoption story is simple: Git removes friction from collaboration. If you are new to contributing, our guide on how open source contributions can land you your first tech job is the natural next read, since every step of that process runs through Git.
The checklist of why teams chose Git:
Speed. Local operations mean commits, diffs, and history are instant, even with millions of commits behind them.
Cheap branching. Branches are pointers, so teams branch for every feature and merge constantly without dread.
Offline work. The full history lives on your machine, so you can commit, experiment, and review on a plane.
Integrity. SHA-1 checksums make silent corruption essentially impossible.
Open and free. GPL v2.0, no license fees, and a hosting ecosystem with free tiers everywhere.
Learn the five-command workflow above, make branching a habit, and Git stops being a source of anxiety and becomes what it was designed to be: a safety net that lets you change anything, knowing you can always come back. Read this article in Indonesian: Git Dijelaskan: Cara Kerja Version Control Sebenarnya.
Frequently Asked Questions
Is Git the same as GitHub?
No. Git is the version control software that runs on your computer and tracks file history. GitHub is a website that hosts Git repositories online and adds collaboration features like pull requests, issues, and wikis. GitLab and Bitbucket are alternative hosting platforms for the same Git tool.
Do I need an internet connection to use Git?
No. Git is distributed, so committing, branching, merging, and browsing history all work fully offline. You only need the internet to push your commits to a remote host like GitHub or to pull other people's changes.
Is Git free?
Yes. Git is free and open source software, released under the GNU General Public License version 2.0. You can use it for personal and commercial projects at no cost.
What exactly is a commit?
A commit is a saved version of your project at a point in time. It records a snapshot of all your files, a message describing the change, and a unique 40-character SHA-1 hash that identifies it. Commits chain together to form your project's complete history.