If you've ever worked on a document with a friend and ended up with files named report_final.docx, report_final_v2.docx, and report_FINAL_actually_this_one.docx, you already understand the problem Git solves. Now picture that same chaos, except instead of a five-page report it's a codebase with a hundred thousand files and forty engineers all editing it at once. That's the world Git was built for.
At its core, Git is a distributed version control software system that manages versions of source code or data [Source 1]. The short version: it remembers every change you make, lets you rewind to any point in history, and lets a whole team work on the same code without stepping on each other's toes. The longer version is what the rest of this piece is about.
Write for sansxel
Want your work in the Learn library? Apply for a hardlocked byline.
Version control is the practice of tracking changes to files over time. Before tools like Git, programmers did this by hand or with clunky centralized systems where one server held the One True Copy and everyone had to check files in and out like library books. If the server went down, work stopped. If you were on a plane, you were out of luck.
Git took a different approach. It's distributed, meaning every developer who clones a project gets the entire history of that project on their own machine [Source 1]. Your laptop isn't just holding a copy of the latest code. It's holding the whole story: every commit, every branch, every change anyone has ever made. You can work offline, commit offline, branch offline, and sync up with your team later.
This is the key shift to internalize. There's no central authority that owns the truth. Every clone is a full repository. Teams pick a particular copy (usually one hosted somewhere public) and agree to treat it as the canonical one, but that's a social convention, not a technical requirement.
What Git actually does for you
Think of Git as a time machine plus a merge engine. Two jobs, deeply intertwined.
The time machine part is straightforward. Every time you tell Git to save a snapshot (a commit), it records what changed, who changed it, when, and why (assuming you wrote a halfway-decent commit message). You can walk backward through that history at any time, see exactly what the code looked like on a particular Tuesday in March, and roll back if something broke.
The merge engine part is where Git earns its reputation. Because the system is built for collaboration, it has to handle the case where you and a coworker both edited the same file at the same time. Git tries to combine your changes automatically, and when it can't, it tells you exactly which lines are in conflict and lets you sort it out. This is what makes Git used to control source code by programmers developing software collaboratively [Source 1].
Branches: the killer feature
The single idea that makes Git click for most people is the branch.
A branch is a parallel timeline. You're working on the main version of your project, and you want to try something risky, maybe rewrite the login system. Instead of editing the main code and praying, you create a branch called new-login, do your work there, and leave the main timeline untouched. If your experiment works, you merge it back. If it doesn't, you throw the branch away and nothing is lost.
In practice, a healthy Git workflow involves dozens or hundreds of branches over a project's lifetime. Each new feature, each bug fix, each weird hunch gets its own branch. Branches are cheap, fast, and easy to throw away. That cheapness is the point. It changes how you think about coding, because the cost of trying something is essentially zero.
Commits, the unit of change
A commit is the atomic unit of Git. It's a snapshot of your project at a moment in time, plus a message explaining what changed and (ideally) why.
Good commit messages are an art. The format most teams converge on is a short summary line, then a blank line, then a longer explanation if needed. Future you, six months from now, trying to figure out why a piece of code exists, will thank present you for writing Fix off-by-one error in pagination when result count is exactly page_size instead of fixed bug.
Commits chain together to form a history. Each commit points to its parent, building a graph that Git can traverse. When you merge two branches, you create a commit with two parents, weaving the timelines back together.
A typical day with Git
Here's roughly what using Git looks like once it's part of your routine:
git pull # grab the latest changes from the team
git checkout -b fix-typo # make a new branch
# ... edit some files ...
git add . # stage your changes
git commit -m "Fix typo in welcome banner"
git push # send your branch up to the shared host
That's it. That's the loop. Pull, branch, edit, stage, commit, push. You'll do this hundreds of times a week and eventually it becomes muscle memory, like saving a document or hitting undo.
There's more, of course. git rebase for cleaning up history. git stash for setting work aside temporarily. git log for browsing the past. git diff for seeing what's changed. But the core loop above will take you a remarkably long way.
Git is not GitHub
This confuses everyone at first, so let's nail it down.
Git is the underlying tool. It runs on your computer and manages your repository. It's open and works on its own.
GitHub is a company and a website that hosts Git repositories online. It's a proprietary developer platform that lets developers create, store, manage, and share their code, and it uses Git to provide distributed version control [Source 2]. On top of that, GitHub adds a bunch of stuff Git itself doesn't do: access control, bug tracking, feature requests, task management, continuous integration, and project wikis [Source 2]. GitHub is headquartered in San Francisco and has been a subsidiary of Microsoft since 2018 [Source 2].
You can use Git without ever touching GitHub. Plenty of teams host their own Git servers or use competitors. But for most public open-source projects, GitHub is where the action happens, which is why the two names get used almost interchangeably in casual conversation.
Bisect, or how to find the commit that broke everything
One of Git's quietly brilliant features is git bisect. The setup: something used to work, and now it doesn't. Somewhere in the last two hundred commits, somebody broke it. Which one?
Bisect does a binary search through your history. You tell Git a known good commit and a known bad commit. Git checks out the commit halfway between them. You test it. Good or bad? Based on your answer, Git narrows the range and picks a new midpoint. After about log2(N) rounds, you've found the exact commit that introduced the bug.
This works beautifully when failures are clean and reproducible. Real software is messier. Tests get flaky, regressions don't show up monotonically, and the meaning of "broken" can shift as a codebase diverges from its upstream. Researchers have started exploring whether large language models can help with the harder cases, augmenting bisect with chain-of-thought reasoning to handle commits whose effects are subtle or semantic rather than a clean pass/fail [Source 5]. It's an interesting hint at where developer tooling is heading: the old plumbing of Git, plus a layer of machine reasoning on top.
Why Git won
Git isn't the first version control system, and it isn't the only one. So why did it eat the world?
A few reasons. It's fast. It's distributed, so you don't need a network to do real work. Branching and merging are cheap, which encourages the kind of fearless experimentation that makes good software. And it's free, open, and runs everywhere.
There's also the network effect. Once GitHub took off, hosting open source on Git became the default. New developers learned Git first because that's what every tutorial used. Tooling matured around Git: editors, code review tools, CI systems, deployment pipelines. The ecosystem fed itself.
The result is that today, if you're writing software with anyone else, you're almost certainly using Git. Not because someone mandated it, but because it works, and because everyone else is using it too.
Where to go next
If you're new to Git, the best thing you can do is start using it on a real project, even a tiny personal one. Make a folder, run git init, commit some files, break something on purpose, recover. Most of Git's reputation for being scary comes from people learning it under pressure on someone else's important code. Learn it on your own time, on stuff that doesn't matter, and it stops being scary.
The deeper material (rebasing, the reflog, interactive history rewriting, hooks, submodules) can wait. The basic loop of pull, branch, commit, push will carry you through your first year easily. Everything else is built on that foundation, and you'll pick it up as you need it.
Git isn't glamorous. It's plumbing. But it's the plumbing that holds modern software development together, and once it clicks, you'll wonder how anyone ever shipped code without it.
