Welcome to Git Mastery, a series where we'll learn Git from the ground up, starting with the absolute basics and gradually moving toward advanced workflows, Git internals, hooks, automation, and professional development practices.
Whether you're a student, hobbyist, open-source contributor, or professional developer, Git is one of the most important tools you'll ever learn.
Let's begin.
What Is Git?
Git is a distributed version control system (DVCS) — a tool that tracks every change made to your files over time, so you always know what changed, when it changed, and who changed it.
But that definition alone doesn't really capture what Git feels like to use. A better way to understand it is through a problem every developer has run into.
You start a project. Things are going well. Then you make a change that breaks everything. You try to undo it manually, but you can't remember exactly what you had before. So you do what most people do without a version control system — you start creating backup folders:
project-final
project-final-v2
project-final-v2-fixed
project-final-v2-final
project-final-v2-final-final
Within a week, you have ten folders, no idea which one is actually the latest, and a growing sense of dread every time you open the project.
Git solves this completely. Instead of managing folders manually, Git lets you take a snapshot of your entire project at any meaningful moment — a snapshot called a commit. Each commit is stored safely, labeled with a message you write, and linked to every commit before it. Your project's history becomes a clean, navigable timeline rather than a pile of duplicated folders.
And because Git is distributed, every developer working on a project has a full copy of that entire history on their own machine. There is no single point of failure. No central server going down means everyone loses their work.
Why Do We Need Version Control?
Code changes constantly. Features get added, bugs get fixed, experiments get tried and sometimes abandoned. Without a system to track all of that, even a solo project becomes fragile fast.
Consider a simple scenario. On Monday your app works perfectly. You spend the rest of the week adding a new feature. On Friday something is broken and you have no idea why. Without version control, your options are grim: scroll through every file trying to spot what changed, or manually rewrite code you only half-remember.
With Git, the answer is two commands away. You look at the history, find the last commit where everything worked, and either revert to it or compare it line by line against your current code to pinpoint exactly what went wrong.
But version control is not just a safety net for mistakes. It also changes how confidently you can work. When you know every change is recorded and reversible, you stop being afraid to experiment. You try things. You refactor aggressively. You move faster, not slower, because the cost of being wrong drops to nearly zero.
And when you add other developers to the picture, version control becomes the thing that makes collaboration possible at all. Without it, two people editing the same file at the same time means one person's work silently overwrites the other's. With Git, changes from multiple people are tracked separately and merged deliberately, with conflicts surfaced clearly rather than hidden.
Version control is not about being cautious. It is about having the freedom to be bold.
A Brief History of Git
The World Before Git
For the first decade of Linux development (1991–2002), changes to the kernel were managed through a simple patch-based system. Contributors would submit patches via email to mailing lists, and Linus Torvalds would manually apply them to his source tree. CVS had been around since the 1980s and was the most popular version control system at the time, but it was not a good fit for Linux kernel development.
The BitKeeper Era (2002–2005)
In 2002, the Linux kernel development team adopted BitKeeper, a proprietary distributed version control system created by Larry McVoy's company BitMover. BitKeeper offered a free license to the Linux kernel community, but came with significant restrictions: developers couldn't work on competing version control projects while using BitKeeper, and they couldn't reverse engineer the software.
Despite the controversy around using proprietary tools for an open-source project, BitKeeper worked and it raised the bar for what any replacement would need to deliver.
The Crisis That Sparked Git
The critical incident occurred in 2005 when Andrew Tridgell, a kernel developer, created a tool called SourcePuller that could communicate with BitKeeper repositories. BitMover claimed this constituted reverse engineering of their protocols, violating the license agreement. This dispute led to the revocation of the free BitKeeper license for the Linux kernel project, leaving thousands of developers without their primary collaboration tool.
Torvalds' response was characteristically blunt: "I'll do something that works for me, and I won't care about anybody else."
Ten Days That Changed Software Development
Exactly twenty years ago, on April 7, 2005, Linus Torvalds made the very first commit to a new version control system called Git and in that first commit, he'd written enough of Git to use Git to make the commit itself.
Two key principles drove its development: speed, essential to handle a high volume of changes efficiently, and the widespread use of a hashing system (SHA-1) not primarily for security, but to detect file corruption, a problem Torvalds had already encountered with BitKeeper.
Torvalds needed a system that could handle applying patches in under three seconds, as kernel development often required processing 250 patches simultaneously.
What's in a Name?
When asked about the name, Torvalds described the tool as "the stupid content tracker" and offered several interpretations: a random three-letter combination that is pronounceable and not used by any common UNIX command; or simply the British slang word for a silly or contemptible person. There are several theories, but Torvalds has said he simply liked the word, which he'd learned from the Beatles song I'm So Tired.
From Kernel Tool to World Standard
Within days, Git was functional. Within weeks, the Linux kernel was using it. By June 2005, Git was already managing Linux kernel releases. By December 2005, Git 1.0 was released.
Though quickly adopted by kernel developers, Git didn't win everyone over right away it faced complaints for the first few months and years due to its steep learning curve and unusual mental model. But its strengths were undeniable.
Today, huge numbers of start-ups, collectives, and multinationals including Google and Microsoft use Git to maintain the source code of their software projects. Commercial hosting companies like GitHub (founded 2007), Bitbucket (founded 2010), and GitLab (founded 2011) built entire businesses on top of it. GitHub alone has over 40 million registered developers and was acquired by Microsoft for $7.5 billion in 2018.
Linus Torvalds himself admitted he never expected Git to become this big it was simply built to solve Linux's problem. That problem turned out to be everyone's problem.
Top comments (0)