Branches, for people who never wanted them

Ask a designer whether they want branches and most will say no, because the word carries everything they dislike about version control: commands, conflicts, a diagram nobody can read. Ask them whether they would like to try something without risking the real file, and the answer is always yes. Those are the same feature. We built the second one.

A copy with a request attached

A branch on the canvas is a copy of the file, with a review request already open on it. You work on the copy exactly as you work on the file. When it is ready, the request shows the people you name what changed — layers, components, styles, variables, prototype links — and the merge waits for one of them to approve it. The base file is not touched until then.

Conflicts are shown, not solved

If a variable or a style changed on both the branch and the base while you worked, we do not pick a winner. The conflict is shown to you, side by side, and you choose. It would have been easy to resolve these automatically and it would have been wrong: a design decision made silently by a merge is exactly the kind of drift the whole product exists to remove.

• Work on a copy; the real file is untouched until the merge
• Every branch carries a review request
• Conflicts in values and styles are yours to decide
• The merge is one step, and the history names it

The same safety net engineering has always had — without asking anyone to learn the vocabulary.

Branches come with the Business plan.