Branches and commits: git for things

Software developers solved a problem long ago: how to try bold changes without fear of losing what works. They invented version control. Solid Vibes brings the same idea to physical things.

Commits: a saved moment in time

A commit is a snapshot of your whole Thing: the Recipes, Parameters, pieces and Connections. Solid Vibes records them as you work and writes a plain-language message for each, such as "Thickened the lid lip and added a snap latch". You do not have to name anything.

Commits are immutable. Once a moment is saved, it cannot be altered, only built upon. That makes the history trustworthy.

The time-travel slider lets you scrub across the whole Thing's history and see it as it was.

Branches: try an idea without risk

A branch is a separate line of history. You start one from any commit and make changes there without touching the original, which is usually called main.

Use a branch when you want to:

• try a bold change ("what if the whole thing were 20 percent lighter?"),
• explore two versions side by side,
• let the agent make a big, multi-step change before committing to it.

If the experiment fails, throw the branch away. Main never noticed.

Seeing what changed

Compare two branches (or any two commits) with a visual diff:

• geometry that was removed shows in red,
• geometry that was added shows in green,
• a parameter changelog lists the numbers that changed, such as "Weight 142 g to 118 g" or "Wall 2.4 mm to 1.8 mm".

You see what happened to the shape and to the numbers that matter.

Merging: bringing ideas home

When a branch earns its place:

• Merge brings the whole branch into another one, typically main.
• Cherry-pick takes just the features you want. Maybe you like the new lid but not the new base.

Release tags

A release tag marks a commit as final: "v1.0 sent to factory". It freezes the geometry, the drawings and the Make list together. Months later, when the factory asks "which revision was that?", you can reopen exactly what you sent. Drawing revisions are tied to tags.

Fork and remix

Public Things can be forked: copied into your own workspace with their full history, so you can see how they were made and change them. Attribution to the original is automatic.

Habits that work

1. Keep main working. Main should always be the version you would be willing to print.
2. Branch before risk. If the next change involves more than a couple of steps, branch first.
3. Name branches for the question. "lighter", "no-supports", "metal-version", not "test2".
4. Merge small and often. Long-lived branches drift apart and become painful to merge.
5. Tag when you send anything out. The three seconds it takes save hours of confusion.

Agent and history

The agent can use history on request: "branch from here and try making it lighter", "compare this with yesterday", "go back to before I changed the lid". It cannot delete history; changes are always additions or suppressions that remain visible.

Create a branch called lighter from here. Reduce the weight by at least 20 percent without changing the mounting holes or the overall size.

Trial users

On the free trial you have commits, but not branches. If you want to experiment, take a commit before a risky change so you can return to it. Upgrading to Maker adds branching.

Try it

On the L-bracket template (with a plan that includes branches):

Branch off a version called thicker. Make the vertical leg 6 mm thick. Then show me a diff against main with the weight change.

Look at the red and green overlay, read the parameter changelog, and then decide whether to merge or discard.