Why teams keep history: version control without fear

CatChow keeps its website in a repository on GitHub. Support has a question: why does delivery now cost 59 UAH instead of 49? Marketing says it wasn't them. Without a shared history, that's a week of asking around.

Picture the usual alternative: prices.xlsx, prices-new.xlsx, prices-final-v3.xlsx in a shared folder. Two people edit at once, one overwrites the other, the old numbers are gone, and nobody knows which copy is the real one.

Version control fixes exactly that. It keeps one project and saves every state of it as a separate step. Each step is a commit, and it records who made it, when, and a short message on why. The chain of commits is the project's history.

A shared drive also lives in the cloud. What it doesn't give you is the explained trail of changes, a way back to any earlier state, and safe parallel work for several people. And version control publishes nothing by itself: getting a change onto the live site is a separate, deliberate step.

People say "Git" and "GitHub" as if they were one word. They are two different things that work together.

Git is the version control system itself. It records commits and keeps the history. Engineers run it on their own laptops and type commands in a terminal: git commit saves a step, git log lists the history, git push sends new commits to the shared copy of the project.

GitHub is a website that stores Git repositories and adds teamwork on top: pull requests to propose and discuss changes, reviews, issues for tasks and bugs, and releases. Think of Git as the engine and GitHub as the office built around it. Other hosting sites exist, but the Git underneath is the same.

For a PM or a marketer this split is good news. Everything you need to read (files, commits, history, pull requests) is in the GitHub web interface, in the browser. When an engineer mentions a command, it helps to know what it does, but you never have to type one.

A project together with its whole history is a repository, or repo. CatChow's is catchow/website: page templates, texts, images and a config file with prices. Its main line of work is the main branch, called main.

In this course, history is drawn as dots on a line. Each dot is one commit with its message next to it. Time runs top to bottom: the oldest commit is at the top, the newest at the bottom. To find what happened last, look at the last dot.

In the CatChow history the fourth dot reads "Raise delivery price to 59 UAH". The support mystery is solved in seconds, without asking anyone.

One warning before you open GitHub itself: its commit list runs the other way, newest on top, like a news feed. Always check which way a list is sorted before you say what came first. Also notice that the messages are in English: most teams write them that way, whatever language they speak in the office.

The delivery-price commit names its author: Daniel, a CatChow web developer. Asked in the chat, he barely remembers it: the courier company raised its rates and finance asked to pass the increase on. He doesn't need to remember. The history does.

Git records the same five things for every commit, always:

• the changes to the files;
• the author;
• the date and time;
• the commit message, a short note on what changed and why;
• a unique id, the commit hash, such as a41c09e.

Some things are not part of a commit, even though you'll see them nearby on GitHub. Who approved the change belongs to the pull request, a GitHub feature. Whether the change is live on the website depends on deployment, which Git doesn't track. So when you need "who signed this off?" open the pull request, and for "is it on the site yet?" ask the team or check the release, not the commit.

Every commit gets a unique id called the commit hash. Git calculates it from the commit's contents, so no two commits share one. The full hash is 40 characters of digits and the letters a–f; people almost always quote just the first seven, like a41c09e, which is enough to point to one commit in a project.

That's why engineers paste hashes into chats and tickets: a hash is a precise address. On GitHub you can paste it into the search box of the repository, or open a link that ends in /commit/a41c09e, and you'll land on that exact change with its author, time, message and diff. In a terminal the same lookup is git show a41c09e.

Don't confuse a hash with the other names you'll meet. A branch has a readable name like main and moves forward as work is added. A tag such as v2.4.0 is a human-friendly label pinned to one commit, usually a release. The hash is Git's own id, and it never changes.

The usual fear on a first visit to GitHub is that one wrong click will take the shop down. It won't. Reading changes nothing: opening files, commits, branches and pull requests is as safe as reading a page in a wiki.

The live site changes only through a deliberate chain of steps. Someone proposes a change in a pull request, a colleague reviews it, the change is merged into main, and then it's deployed to the site. At CatChow every merge into main goes through review first, so a stray click by a visitor can't skip that chain.

Even a bad change that does reach the site isn't a disaster. Git keeps the whole history, so the team can undo a commit with a new one or go back to any earlier state. That's why this course encourages you to click around freely: open old commits, compare versions, read discussions. The worst that can happen is that you learn how the team works.

Once a commit is in main, the team doesn't erase it. They add a revert: a new commit that applies the exact opposite change. The bad line comes out, the old one goes back, and the history now shows both the mistake and the fix, with an author and a reason for each.

Engineers do this with git revert a41c09e, which creates that undo commit. On GitHub a merged pull request has a Revert button: it opens a new pull request that undoes the whole change, and the team reviews and merges it like any other.

Why not just delete the bad commit? Because main is shared. Everyone has already pulled those commits, and rewriting them breaks their copies and hides what happened. Many teams protect main so that its history can't be rewritten at all.

For a PM this means the history is trustworthy. If something was broken on Tuesday and fixed on Wednesday, you'll find both commits, and a revert in the log is a normal, healthy sign rather than a scandal.

History isn't only for engineers. For a PM or a marketer it does four everyday jobs:

• Find who and why. Support asks why delivery costs 59 UAH; the commit names Daniel and the reason.
• Undo. Yesterday's banner broke the mobile layout; a revert brings back the earlier state.
• Work in parallel. Two developers change different pages on the same day, and neither overwrites the other.
• Compare. You want to see how the delivery page read in March; open the old version next to today's.

Most of your time on GitHub will be this kind of detective work, far more than editing. A good habit is to start from the question you have ("what changed on the delivery page last week?") and pick the job that answers it, rather than scrolling through everything.

The same jobs help outside the code too. When site texts live in the repository instead of a shared doc called "v5-final", the content team gets one current version, a clear record of edits and a safe way back.

Four objects show up on every repository page, each with its own small icon. Learn them now; they'll come back in every lesson.

• Repository: the project with its full history. The icon looks like a book.
• Commit: one saved step with an author, a time and a message. The icon is a dot on a line.
• Branch: a parallel line of work. The icon is a line that splits in two. main is the accepted version that the site is built from; a whole module later covers branches.
• Tag: a permanent name on one commit, usually a version such as v2.4.0. The icon looks like a price tag. It's how the team says "this exact commit is what we released".

On GitHub these icons appear in lists and menus without labels, for example in the branch switcher or next to search results. Recognising them at a glance saves you from opening the wrong thing, and it makes engineers' screenshots much easier to read.