Git is one of the best pieces of software ever written. Branches let you try an idea without touching the real thing. Every working copy is a fully isolated world. Nothing is ever really lost — the history is a perfect, total undo. If you sat down to design the ideal system for changing things without fear, you would land somewhere very close to Git.

And almost nobody who isn't an engineer will touch it.

The usual story is that Git is too powerful for normal people — that designers, founders, and PMs need something simpler. We think that story is exactly backwards. Git isn't hard because of its power. It's hard because of its words. "Detached HEAD." "Stash." "The index." "Rebase." These aren't hard ideas wearing plain names; they're plain ideas wearing hostile names. The power is fine. The vocabulary is a language test at the door.

So most tools "solve" this by hiding Git behind a Save button. It works right up until it doesn't — and the moment something goes wrong, the user is stranded in a system they were never allowed to understand. You can't reason your way out of a machine whose parts were deliberately kept from you. Hiding the power to spare people the words just means they meet the words for the first time in an emergency.

We took the opposite path. Keep every bit of the power. Translate every term into a word a normal person already knows. You don't dumb it down — you build a phrasebook.

Two jobs, not one

Look closely at Git and you find two different kinds of work tangled together, and the trick is to treat them completely differently.

Most of it is machinery. Committing after a change, pushing so the work is backed up, pulling in what moved, stashing before you switch, merging when two copies drift apart — these are steps a computer should simply do. There's no judgment in a commit. Nobody stands at a fork in the road agonizing over whether to run git fetch. Asking a non-engineer to drive these by hand isn't empowering them; it's handing them the manual transmission on a car that could have driven itself. So in medit there's an auto-git mode: it commits, pushes, pulls, stashes, and merges in the background, and surfaces each commit as a quiet card in the chat as it goes. You make changes; the history takes care of itself. Nobody types a Git command, because there was never a decision in typing one.

But some of Git genuinely is judgment, and those moments can't be automated away — only faced. Which working copy becomes the real one. Whether a file is shared across every copy or each keeps its own. Which copies a rule should apply to. Whether to overwrite a version that has drifted. A machine can't answer these, because they're about what you want, not about what Git can do. Automate them and you'd just be guessing on the user's behalf — which is how the Save button strands people in the first place.

That split is the entire design. Hide the machine; translate the decision. Almost all of Git turns out to be machine, so we fold that whole mechanical layer away. What's left is a short list of real choices, and that is where the phrasebook lives. We never set out to make non-engineers fluent in Git. We set out to make sure the only things they ever have to decide are things a person can actually decide — asked in words they already own.

The phrasebook

Here's a sample of the translation, Git term on the left, the words a person actually thinks in on the right.

• git checkout <branch> → "Make this the main one." Promote the copy you were experimenting in to become the real thing. No "detached head," no ceremony.
• .gitignore → "Private to your machine." Files that stay on your computer and never travel — a local database, secret keys.
• The index / tracked → "In version control." Whether Git is allowed to keep a file's history. It's a permission, so we phrase it as one: a checkbox.
• symlink → "Shared with all." One file every working copy sees. Change it anywhere, all of them see it.
• cp at branch creation → "Its own copy." Each working copy gets a copy of main's file to change alone. Main's is never touched.
• No link / no copy → "Its own, empty." Each working copy starts blank — the right answer for caches the project regenerates.
• release/*, !(prod), regex → "Name starts with…" You describe which copies you mean in words — starts with, contains, is exactly — and watch them match live. No pattern syntax.
• rm -rf <worktree> → "The safety folder." Nothing is ever deleted. A file about to be removed is set aside where you can always retrieve it.

None of this hides Git. Every one of these is still doing the full Git operation underneath. We just stopped making the word the price of admission.

The verbs

The phrasebook so far is mostly nouns — names for things. But the moments that actually rattle people are actions: the buttons that pick up your work and carry it somewhere it can't easily come back from. Auto-git handles the routine merges that just keep copies in sync. These are the other kind — where you deliberately decide to combine two lines of work, and the direction is a real choice.

Git names those actions after their machinery. merge, checkout, rebase — each describes what the engine does, and leaves the part you actually care about, what happens to the work you have open, for you to work out. git merge feature: which way does the work flow? git checkout main: what happens to what I was doing? You can't tell from the words; you have to already know the plumbing.

So we renamed every action after its intent, and anchored all of them to one fixed point — the copy you have open right now.

• Branch off → "Duplicate." "Branch" is a botany metaphor; duplicate is what actually happens — you get another copy to work in, starting from this one. Everyone has duplicated a file.
• Merge another copy into yours → "Add into open." Their work comes to you. It flows in; you stay put.
• Merge yours into another, and keep going → "Send work here." The other direction — your work goes out to that copy, and you carry on where you are.
• Merge and delete → "Finish into here." Your work goes into that copy, and this one is done — folded in and closed behind you.
• Switch and delete, no merge → "Switch & drop open." You leave for the other copy, and the one you had open is thrown away, work and all. The most dangerous button in the app — and it says so plainly.

Look at what happened to merge. Git has one word for it. To a person it was never one action: pulling someone's work into mine, pushing mine out to theirs, pushing mine and being finished here — three different intentions, three different consequences, and Git makes you tell them apart with arguments and a direction you have to keep in your head. So we didn't translate merge into one tidy word. We split it into three, because it was three things all along. The phrasebook's rule was one word everywhere; its mirror is just as true — when one word is secretly doing three jobs, name the three jobs.

And notice the anchor. Git keeps moving the camera: merge acts on the branch you're standing on, checkout moves you to a different one — the point of view flips with the verb, and you have to track where you are. We bolted the camera down. "Open" always means the copy in front of you, and every verb describes which way work moves relative to that one spot — add into open, send work here, switch & drop open. You never have to ask where you're standing. You're always standing in the same place.

The hardest word — delete

Look again at those last two verbs. Finish into here and Switch & drop open both end with a copy being removed — and that's where translation stops being a courtesy and becomes the whole game.

Switching your main branch, or removing a working copy, runs commands that erase files. An engineer understands the risk — they know a checkout can clobber uncommitted work, they know rm -rf means it. Everyone else hits it as a landmine: one ordinary-looking action, and something irreplaceable is gone. The gap isn't intelligence. It's that the danger was written in a language they were never taught, so the warning never arrived.

You cannot translate delete by softening the word. "Are you sure?" is not a translation; it's a shrug that moves the blame onto the user. The honest translation is to change what the word does.

So we built the safety folder. Nothing is ever actually deleted. A file about to be removed is quietly set aside, and it stays retrievable. "Use main's file" resyncs a copy that has drifted — but first it tucks away whatever was there. The scary operation still happens; the irreversibility doesn't. We didn't make delete sound safe. We made it be safe, and then the plain word is finally telling the truth.

That's the whole philosophy in one feature. Hiding Git tells the user don't worry about it and abandons them when worry arrives. Translating Git tells them the truth in words they own — and builds the world so the truth is one they can live with.

The power was never the problem. We just gave it back its plain name.

This is how version control works in medit — full Git underneath, none of the vocabulary in your way.