# Why teams keep history: version control without fear > What version control is, Git vs GitHub and how the two differ, and why looking around a repository can't break anything. - Course: [Git and GitHub for Product People](https://productovi.com/courses/git-for-product.md) - Module: Git in plain words - Lesson 1/15, ~28 min - Source: https://productovi.com/courses/git-for-product/why-teams-keep-history ## Where you work **Alex Tutor:** Welcome to the course. You've just joined the product team at **CatChow**, a small online shop of about thirty people that sells cat food, treats and litter. Here you'll learn to read the team's work on GitHub (history, branches, pull requests, releases) and even make a small change yourself. ## A price nobody remembers changing **Alex Tutor:** The shop's website lives in a repository on GitHub. Developers change it every week, and outside their team few people can tell what changed or why. Now you've got access too. How does it feel? **Sofia:** A bit scary, honestly. It looks like one wrong click could break the whole shop. **Alex Tutor:** We'll take that fear apart in this module. But first, a real question from support: why does delivery cost 59 UAH now instead of 49? Marketing says it wasn't them. Without a shared history, that's a week of asking around. With Git, it's a two-minute search. ## What is version control? Start with final-v3 **Alex Tutor:** Picture a price list in a shared folder: `prices.xlsx`, then `prices-new.xlsx`, then `prices-final-v3.xlsx`. Two people edit at once, one overwrites the other, and the old numbers are gone. ![A desk buried under nearly identical paper copies of one price list, each with a different coloured sticky flag; a confused person compares two of them.](https://productovi.com/courses/git-for-product/inline/why-teams-keep-history-illustration-2.webp) *Many copies, no history: which one is real, and who changed what?* **Sofia:** Painfully familiar. And nobody knows which file is the real one. **Alex Tutor:** **Version control** fixes exactly that. A version control system saves every state of the project as a separate step, and each step records who made it, when, and a short note on why. **Alex Tutor:** Each saved step is a **commit**, and the chain of commits is the project's **history**. One project with a memory instead of ten half-copies. ![A cat walks along a path leaving paw prints; inside each print is a tiny snapshot of the same web page at a different moment.](https://productovi.com/courses/git-for-product/inline/why-teams-keep-history-illustration-3.webp) *Each commit is one saved step, and the trail of them is the project's history.* > **Exercise:** What does version control give a team that a shared folder of files doesn't? ## Git vs GitHub: not the same thing **Sofia:** So what is GitHub, and what's the difference between Git and GitHub? People say them as if they're one word. **Alex Tutor:** They're related but different. **Git** is the version control system itself: it records commits. Engineers run it on their laptops and type commands like `git commit` in a terminal. **Alex Tutor:** **GitHub** is a website that stores Git projects and adds teamwork on top: pull requests, reviews, issues, releases. Git is the engine; GitHub is the office built around it. ![Git is the version control system that records commits on engineers' laptops; GitHub is the website around it with pull requests, reviews, issues and releases.](https://productovi.com/courses/git-for-product/diagrams/m1-l1-git-vs-github.png) **Sofia:** Please tell me I don't need the terminal. **Alex Tutor:** You don't. Everything in this course happens in the GitHub web UI, in the browser. When an engineer mentions a command, I'll translate it, but you'll never have to type one. > **Exercise:** Git and GitHub are two names for the same tool. ## What a repository remembers **Alex Tutor:** A project together with its whole history is a **repository**, or repo. Ours is `catchow/website`: page templates, texts, images and a config file with prices. **Alex Tutor:** Here's a slice of its main branch, `main`. In our diagrams time runs top to bottom: the oldest commit is at the top, the newest at the bottom. Each dot is a commit with its message. ```text Commit graph, oldest first: Recent history of `main` in catchow/website 1. commit 1c2e7d0 on main "Add delivery page" 2. commit 5b8f3a2 on main "Update cat food photos" 3. commit 9d04e61 on main "Fix typo in footer" 4. commit a41c09e on main "Raise delivery price to 59 UAH" (highlighted) 5. commit e7c3b19 on main "Add summer promo banner" ``` *Five commits, oldest first. The highlighted one changed the delivery price.* **Sofia:** The fourth one: "Raise delivery price to 59 UAH". That's our mystery, solved in seconds! **Alex Tutor:** And notice the messages are in English. Most teams write them that way, whatever language they speak in the office. One warning: GitHub's own commit list runs the other way, newest on top. > **Exercise:** In this diagram, which commit was made most recently? ## Who did it, and why **Alex Tutor:** The commit also names its author: Daniel, one of our web developers. He's in the chat, let's ask him. **Daniel:** Hi! Yes, that was me, three weeks ago. The courier company raised its rates and finance asked us to pass the increase on. It's all in the commit message and the linked pull request. **Sofia:** So the answer sat in the repo the whole time. Nobody had to remember it. **Daniel:** That's the point. I don't remember what I changed last Tuesday either. The history does. **Alex Tutor:** Look at what that commit carried: the change itself, the author, the date and time, a message and a unique id, `a41c09e`, called a hash. Git records these for every commit, always. > **Exercise:** Which of these does Git record with every commit? Select all that apply. **Alex Tutor:** Daniel will often just send a hash in the chat instead of a link. Worth knowing what that string is. > **Exercise:** Daniel writes in the chat, "The price change is `a41c09e`." What is `a41c09e`? ## Why it's safe to look around **Sofia:** Okay, but the fear is still there. What if I click something and the site breaks? **Alex Tutor:** Reading can't break anything. Opening files, commits and pull requests changes nothing. The site changes only when someone merges a change into `main`, and at CatChow that always goes through review first. ![A visitor with hands behind his back calmly studies a tiny web page inside a museum display case, with a cat sitting beside him.](https://productovi.com/courses/git-for-product/inline/why-teams-keep-history-illustration-4.webp) *Reading files, commits and pull requests changes nothing on the site.* **Alex Tutor:** And even a bad change isn't a disaster. Git never throws history away, so the team can undo a commit with a new one or go back to any earlier state. We'll practise that in the last module. **Daniel:** True story: I once broke the checkout button. The fix was the `Revert` button on my pull request, a quick review of the undo, and a two-line apology in Slack. **Sofia:** That's oddly comforting. > **Exercise:** Opening files, commits and pull requests on GitHub can change the live CatChow website. **Alex Tutor:** Daniel's checkout story raises a fair question: what's the right way to undo a change that's already in `main`? > **Exercise:** A commit in `main` broke the checkout button. Which way of undoing it keeps the history honest? ## What history gives a product team **Alex Tutor:** Let's sum up what history gives you as a PM, not just the engineers. **Alex Tutor:** You can **compare** any two versions, find **who** changed a line and why, **restore** an earlier state, and let several people **work in parallel** without overwriting each other. **Sofia:** The delivery price case used the second one: finding who and why. **Alex Tutor:** Right. Most of your time on GitHub will be that kind of detective work, far more than editing. > **Exercise:** Match each CatChow situation with what version control lets the team do. ## Four icons to know **Alex Tutor:** Last thing. Four objects show up on every repository page, each with its own icon. Learn them now; they'll keep coming back. ```text Four objects on a repository page - [Repository] catchow/website: The project with its full history - [Commit] a41c09e Raise delivery price: One saved step with author, time and message - [Branch] main: A line of commits; `main` is the accepted version - [Tag] v2.4.0: A permanent name on one commit, usually a version ``` **Sofia:** Branch and tag are new. Repository and commit I've got. **Alex Tutor:** Branches get a whole module later. For now: a **branch** is a parallel line of work, and a **tag** is a permanent name on one commit, usually a version like `v2.4.0`. **Sofia:** So a tag is how the team says "this exact commit is what we released". **Alex Tutor:** Exactly. Now try to recognise the four without their names, the way they appear in lists and menus. > **Exercise:** Match each numbered icon with the object it stands for. ## Explain it to a colleague **Alex Tutor:** Best test of understanding: explain it to someone else. **Sofia:** Our content marketer keeps the site texts in a shared doc with versions like "v5-final". I'd love to win her over. **Alex Tutor:** Then write her two or three sentences: what the team gains from keeping site texts in the repository's history. **Alex Tutor:** Keep it plain: no commands and no jargon she'd have to google. > **Exercise:** Write 2–3 sentences to a content marketer who keeps site texts in a shared doc ("v5-final"): why keep them in the website repository's history instead? **Alex Tutor:** Next lesson we open the repository page itself and read it from top to bottom: files, the latest commit, branches and the README. **Sofia:** And find the full story behind those 59 UAH. - Next lesson: [Repository and commits: reading a GitHub repo page](https://productovi.com/courses/git-for-product/reading-a-repository-page.md) --- Productovi Learning. Free, no sign-up needed to read.