Git & Version Control

Picture two people editing the same document at once, each saving over the other’s work. By the end of the afternoon, half the changes are gone and nobody’s sure which version is correct. That nightmare is exactly what Git exists to prevent. Git is a version control system: it tracks every change to a project’s code over time, remembers who changed what and why, and lets many people work on the same files at once without clobbering each other. The project itself lives in a repository (“repo” for short) — a folder Git is watching closely.

Commits: saving with a memory

When you’ve made a meaningful chunk of changes, you bundle them into a commit — a saved snapshot of the project at that moment, with a short message explaining what you did (“Fix login button colour,” “Add invoice download”). A commit is more than a save; it’s a save with a memory. Months later, anyone can scroll back through the history and see the project evolve, commit by commit. If something breaks, the team can pinpoint the exact commit that caused it and undo just that change. Good commit messages are a small kindness to your future colleagues, who will absolutely be reading them when they’re trying to work out why a feature behaves the way it does.

Branches: a safe parallel workspace

Here’s the move that makes team coding possible. Instead of editing the shared, working code directly, you create a branch — a parallel line of work that splits off from the main line (usually called main). On your branch you can make commits freely, even half-finished and broken ones, and none of it touches what everyone else sees. The shared code stays stable while you experiment.

Think of main as the trusted, always-working version, and a branch as a sandbox copy you can mess up without consequences. When your work is ready, you bring it back.

This is why a team of twenty engineers can all work at once: each has their own branch for their own feature or fix, and they only combine the finished pieces.

Merging: bringing work back together

When your branch is done and reviewed, you merge it — Git combines your changes back into main, weaving your commits in with everyone else’s. Most of the time this is automatic and effortless. Occasionally two people change the same line of the same file in different ways, and Git can’t decide which version wins. That’s a merge conflict. It sounds scary but it’s routine: Git simply shows you both versions side by side and asks a human to pick, or blend, the right answer. You resolve it, commit the resolution, and carry on. Conflicts are a normal part of collaboration, not a sign anything is broken.

The everyday loop: clone, pull, push

Three more words round out the daily vocabulary, and they’re all about moving code between your computer and the shared copy that lives on a server (often GitHub, GitLab, or Bitbucket).

You clone a repo once, to copy the whole project down to your machine. Each day you pull to fetch everyone else’s latest changes, so you’re working from current code rather than yesterday’s. When your own work is committed, you push it up to the shared server so others can see it. Strung together, the rhythm of a normal day looks like this: pull the latest, create a branch, make some commits, push your branch, then open it to be merged back into main.

Why it matters

You don’t need to use Git yourself to benefit from understanding it. When an engineer says “it’s on a branch,” they mean the work exists but isn’t part of the shared code yet — it’s not “done” in the way that matters to customers. “It’s merged” means it has landed in main and is on its way toward release. “We hit a merge conflict” explains a delay that’s nobody’s fault, just two streams of work overlapping. And the constant emphasis on small commits and clear messages isn’t fussiness — it’s what lets a team move fast without losing track of how their own product got the way it is. Git is the quiet machinery that turns a crowd of individuals into a team that can build one thing together without stepping on each other.

Spot it: Git in action

Read each situation and decide for yourself, then tap a card to flip it and check your answer.

Sort the Git actions

Drag each item into the bucket it belongs to — or tap an item, then tap a bucket. Hit Check placement when you’re done.