If you've ever worked on a PowerPoint presentation with other people, you already understand the problem that Git solves. You just never had a name for it.
Let me explain.
The presentation from hell
You're building a slide deck for a big meeting. You start with a first draft. You save it as Q3_presentation.pptx and send it to your manager.
She comes back with feedback. "Move the revenue slide before the roadmap. Add a slide on customer churn. The fonts are all wrong."
So you rework it. Now you have a decision to make. Do you save over the original file? Or do you create a new one?
Most people create a new one. Q3_presentation_v2.pptx. Smart. You want to keep the old version around, just in case.
Your manager reviews v2. More feedback. More changes. Now you've got Q3_presentation_v3.pptx. Then your colleague adds his section and saves it as Q3_presentation_v3_tom.pptx. Then your manager makes her own edits and saves it as Q3_presentation_v3_FINAL.pptx. Then someone changes something after "final" and you end up with Q3_presentation_v3_FINAL_really_final.pptx.
You know this story. Everyone knows this story. It's chaos. Nobody knows which version is the real one. Nobody knows what changed between versions. And if something breaks, good luck figuring out when it happened and who did it.
This is the problem that Git solves.
What Git actually does
Git is a version control system. That sounds technical, but you already understand the concept. You were doing version control with those _v2 and _v3 file names. You were just doing it badly.
Git does the same thing, but properly. It keeps track of every change made to a set of files, who made the change, when they made it, and why. Think of it as a detailed logbook that sits alongside your project and records everything that happens.
The difference is that you don't need twenty copies of the same file. Git stores one file and remembers its entire history. You can go back to any point in time and see exactly what the file looked like. You can compare any two versions side by side. You can undo specific changes without losing everything else.
Now imagine this power applied to something much bigger and more complex than a slide deck. Software projects have hundreds or thousands of files, with dozens of people working on them at the same time. Without a system like Git, it would be impossible to keep track of anything.
The words that confuse everyone
Git has its own vocabulary, and it sounds intimidating if you've never heard it. But every concept maps to something you already do in your daily work.
Commit: saving your work with a note
A commit is the most basic unit in Git. It's a snapshot of your work at a specific moment, with a short message explaining what you changed.
Going back to the presentation analogy, think of it this way. You open the deck, you add the customer churn slide your manager asked for, and you save. In Git terms, that save is a commit. And the note you attach to it might say: "Added customer churn slide after revenue section."
The note matters. Six months from now, if someone needs to understand why the churn slide was added, they can look at the commit history and see the note. They'll know exactly what happened and when.
People typically make several commits a day. Small, frequent saves with clear descriptions. "Fixed typo on slide 4." "Updated Q3 numbers with latest data." "Removed the old org chart." Each one is a checkpoint you can go back to if something goes wrong.
Push: sharing your work with the team
When you're working on your laptop, your changes only exist on your machine. Nobody else can see them. A push is the act of uploading your commits to a shared location where your team can access them.
In our analogy, it's like working on the presentation on your own computer all morning, then saving it to the shared drive after lunch so your colleagues can see what you've done.
Until you push, your work is private. This is actually a nice feature. It means you can experiment, make mistakes, and clean things up before anyone sees them. When you're ready, you push. Your commits show up on the shared version and everyone can see your changes.
Pull Request: asking for a review before your changes go live
This one is where it gets interesting.
Imagine you've reworked the entire presentation. New structure, new slides, updated numbers. Before you replace the official version on the shared drive, you want your manager to review it. So you send her a message: "Hey, I've made some big changes to the deck. Can you take a look before I swap it in?"
That's a Pull Request, or PR for short.
A PR is a formal way of saying: "Here are the changes I want to make. Please review them." Your colleagues can look at exactly what you changed, line by line. They can leave comments. "This number looks wrong." "Can you reword this sentence?" "Love what you did with the new structure." You can have a back and forth, make adjustments, and only once everyone is satisfied does the change get merged into the official version.
This is one of the most important ideas in modern software development. No one person just pushes their changes directly into the live product. They open a PR, get it reviewed, get approval, and then merge. It's quality control built into the process.
So where does GitHub fit in?
Git is the system. GitHub is the place where teams use that system together.
Going back to our analogy one more time: Git is the concept of version control. GitHub is the shared drive where everyone keeps their files, reviews each other's work, and discusses changes.
GitHub is a website (github.com) that hosts Git projects and adds a layer of collaboration tools on top. It gives you a visual interface to see commit history, review pull requests, track issues, and manage who has access to what. It's where developers go to work together on code, the same way your team might use Google Drive or SharePoint to collaborate on documents.
There are alternatives to GitHub, just like there are alternatives to Google Drive. GitLab and Bitbucket do similar things. But GitHub is by far the most popular, so it's the one you'll hear about the most.
One last thing: software is never final
Here's where the presentation analogy breaks down a little. Presentations have an end date. The meeting happens, you present, and the deck is done.
Software doesn't work like that. Software is never done. There are always bugs to fix, features to add, performance to improve, and security updates to apply. The "presentation" keeps evolving forever. Version 3 doesn't become "final." It becomes the starting point for version 4.
That's why version control matters so much in software. It's not just about keeping track of a few drafts over a couple of weeks. It's about maintaining a living, breathing record of a project that might span years, with hundreds of people contributing to it over time. Git makes that possible.
And now, when someone mentions a commit, a push, or a pull request, you'll know exactly what they mean. It's the same thing you've been doing with your _v2_FINAL_really_final.pptx files. Just a lot more organized.