If you've ever ended up with a folder called report_final_v3_ACTUALLY_FINAL.docx, you've already felt the problem Git exists to solve. Version control is just a system for tracking how a set of files changes over time, who changed them, and why - so you never have to solve that problem by renaming files again.
The problem before version control
Without it, teams fall back on two bad options: email files back and forth and hope nobody overwrites someone else's edit, or keep a folder full of dated copies and manually figure out what changed between them. Both break down fast once more than one person is editing, or once you need to answer "what did this file look like last Tuesday, and why did it change?"
What Git actually is
Git is a distributed version control system: a tool that records snapshots of a project's files over time, lets multiple people work on independent copies of the full history at once, and gives you a reliable way to combine everyone's changes back together. "Distributed" is the key word - unlike older systems that kept the one true history on a central server, every clone of a Git repository carries the entire history. There's no single point of failure, and you can commit, branch, and look at history entirely offline.
Where it came from
Linus Torvalds created Git in 2005 to manage the Linux kernel's source code, after the kernel project's previous tool (a proprietary system called BitKeeper) became unusable for licensing reasons. The design goals were blunt and specific: handle a codebase with thousands of contributors, be fast, and make branching close to free. Those goals are still visible in how Git behaves today - operations that are slow or awkward in other systems (creating a branch, comparing history, working offline) are exactly the things Git was built to make effortless.
What a commit actually is
This is the one idea that makes the rest of Git click: a commit isn't a diff. It's a complete snapshot of every tracked file at that point in time, plus a pointer back to the commit (or commits) that came before it. Git is clever about storage - unchanged files aren't duplicated - but conceptually, you should think of history as a chain of full snapshots, not a stack of patches. That's part of why operations like checking out an old version or creating a branch are so fast: Git isn't replaying a sequence of changes, it's just pointing you at a snapshot that already exists.
Git vs. GitHub (they're not the same thing)
This trips up almost everyone early on: Git is the version control tool that runs on your own machine and manages history. GitHub, GitLab, and Bitbucket are separate, unrelated companies that host Git repositories on the internet and layer collaboration features on top - pull requests, issue tracking, code review, CI/CD pipelines. You can use Git with no hosting platform at all (plenty of solo developers do), and the hosting platforms are themselves just talking plain Git underneath. Understanding that split early will save you a lot of confusion once this series gets to remotes.
What this series assumes
Nothing beyond basic comfort with a terminal - you don't need any prior Git or programming experience. If you've never typed a command in a terminal before, it's worth getting comfortable with that first, since every Git command in this series is typed, not clicked (even though GUI tools exist and are mentioned where relevant).