Git for Non-Engineers

You're a designer prototyping in code, maybe with tools like Claude or Cursor. But how do you change things without breaking what already works? How do you collaborate on it? How do you share it with engineers and customers?

This guide is a visual crash course on git, the tool engineers use to collaborate on code. It will give you a robust mental model and is the first step towards solving the problem of robustly collaborating on code.

Git saves snapshots. Every time you commit, it stores a complete picture of your files and links it to the one before. Those links are the line you just watched appear.

A branch sounds technical. It's exactly what it sounds like: A deviation from your initial code that runs in parallel to it. For example, let's say I wanted to experiment with a new hero animation.

I might create a branch called "ayon/hero_animation". On that branch, I'd modify the hero section of my site. The original code on my main branch is safely untouched. Once I'm ready I can merge my new code into my main branch.

Your work lives in four places, and a small handful of commands transition between them, and push to send them up to GitHub, where teammates and your customers (via a hosting provider) can see them. Later, you pull to bring everyone else's work back down.

That is the whole daily loop. Two extras worth naming: status tells you which box your changes are sitting in, and init just means "make this folder a repository." You will lean on status constantly. You run init once.

Branches let two ideas move forward at the same time. When you are happy with one, a merge weaves it back into the trunk with a single commit that has two parents.

If the two branches touched different things, git stitches them together and you never notice. The only interesting case is when they touched the same thing.

A merge conflict sounds like a crisis. It is just two people changing the same line such that you have to choose who is right.

Git shows you both versions and waits. You keep one, or write a new line that blends them, and save. That is the entire ritual.

Connect your GitHub repository to Vercel or Netlify one time and deploying stops being a task you do. It becomes something that just happens.

Every push builds your site. Every branch gets its own private preview link, a real working version you can click through and send to a client before anything is live. Merge to main and the same machinery ships it to the world. You stop deploying and spend that time designing instead.

Here's the cool part: you no longer have to type any of this.

Claude Code and Cursor can run git for you. You describe the outcome in plain English and they translate. "Save this as a checkpoint and open a pull request called Hero redesign" is a complete, correct instruction.

Because these tools can read your repository, they pick up your branch names, your habits, and your conventions, and they tend to match them. You review what comes back the way you would review a junior's work: by looking, not by memorizing flags.

The same idea scales up. A cloud agent works in its own copy of the project in the cloud, makes a branch, and opens a pull request while you do something else. Waiting on the other side is CI/CD, a set of automatic gates in front of your main branch that protect it.

Open a request and checks run on their own. Red keeps the door shut. Green means it is safe, and the deploy you saw earlier happens by itself. The repository, not any one person, becomes the source of truth.

Working alone, git forgives. On a real project with real users, a few habits preserve trust. None of them are technical.

Once the basics are reflex, two techniques earn their keep.

The first is rebase. While you worked, main moved on, and you need those new commits. One way is a merge. It ties the two lines together with a fresh commit and leaves the fork-and-join knot from earlier. Rebase takes the other path. It lifts your commits off, slides your branch up to today's main, and replays your work on top, one commit at a time. You get fresh copies of each, marked x′ in the picture, sitting in a single straight line, as if you had branched off today.

Same destination as a merge, with a cleaner shape. A straight line reads like one story. It is easy to review, easy to follow months later, and easy to undo a single step. The one rule is to rebase only work that is still yours and unshared. Rebase rewrites history, so never replay commits other people have already built on.

The second is worktrees. A worktree checks out a branch into its own folder, while every folder shares one repository. That is the difference from cloning the project twice: not two copies you keep in sync, but several windows onto the same history and the same branches. A commit you make in one folder is already there in the others. The only catch is that a branch can be open in one folder at a time.

It also retires stashing. Stashing is serial: one folder, one branch at a time, with your half-done work shelved while you switch. Worktrees are parallel: every branch stays open in its own folder, each with its own dev server. Nothing gets hidden. You glance at the other window.

This is where it shines for design. Start from your one project folder. For each idea, ask your agent for a fresh folder on a new branch, and it sets up the worktree for you. A few ideas, a few folders, all off the same repo. Point an AI agent at each one with a different brief. Because the folders are separate, the agents never trip over each other, and each runs its own preview on its own port. You watch the variations take shape side by side, keep the winner, and delete the rest.

You do not need any of this on day one. Run status until it is automatic. Add and commit small changes often. Set up Vercel or Netlify. Open one pull request and watch the preview link appear. Let an agent do the typing while you keep your eyes on the work.

Git became clear the day I quit memorizing commands and started seeing the graph. I hope this guide does the same for you.