Review requests: pull requests for hardware
Ask a teammate to check a branch before it lands on main: they see the 3D visual diff and the numbers that changed, pin comments on the exact spot, and approve or ask for changes. Merge once it is approved.
A review request is a pull request for a physical part. You try an idea on a branch, and before it goes into main a teammate looks at it in 3D and says "approved" or "change this first".
Request a review
- Work on a branch and commit your changes (History → Try an idea).
- In History, choose Request review on the Review requests card.
- Pick the branch and where it should land (main by default), give it a title, and tick the teammates who should review it. They need the reviewer role or higher.
- Optional: Write it with AI drafts the description from the branch's commits and its changes. It costs a small number of AI credits; edit the text as you like.
Reviewers get a notification that opens the review.
What reviewers see
The review page shows:
- the visual diff: the branch next to where it left main, with removed material in red and added material in green;
- the changes in plain words and numbers, such as "Width 90 → 104 mm" or "Weight 41.4 g → 45.8 g (+11%)";
- the commits on the branch (click one to look at it alone);
- the discussion: Pin a comment on the diff to point at a spot, @mention people, reply and resolve;
- the activity: every approval, change request and note.
Approve or ask for changes
Reviewers choose Approve or Request changes, with an optional note, or just Comment.
- An approval counts for the version it was given on. If someone commits again to the branch, the review goes back to Open until it is approved again.
- A request for changes keeps the review in Changes requested until that reviewer approves.
- You cannot approve your own review.
Merge
When the review is Approved, editors see Merge into main. Merging uses the same merge as History, including the pick-a-side list when the branch and main changed the same thing. Both histories stay, joined by a merge commit, and the review becomes Merged.
Statuses
| Status | Meaning |
|---|---|
| Open | Waiting for reviewers |
| Approved | Has enough approvals on the latest version |
| Changes requested | A reviewer wants changes |
| Merged | Landed on the target branch |
| Closed | Closed without merging; it can be reopened |
Required approvals (Enterprise)
Workspace admins on Enterprise can set how many approvals a review needs (1 to 5) from any review page. The rule applies to every open review in the workspace right away.
Try it
On a branch with a change you are unsure about, choose Request review, tick a teammate and press Write it with AI for a first draft of the description. Then pin a comment on the spot you want them to look at first.
Did this help?
Keep reading
Ideas
Branches and commits: git for things
How history works in Solid Vibes: commits that write themselves, branches for ideas, visual diffs, and release tags that freeze what you sent to the factory.
Intermediate4 min readIdeas
3D comments, mentions and notifications
Pin a comment to the exact spot on the model, @mention a teammate, reply, resolve, and follow it all from the notification bell. Works in the editor, on review requests and through comment links.
Beginner4 min readAccount and billing
Plans and limits
What each plan includes: Things, private Things, storage, credits, exports and features. And what happens when you reach a limit (spoiler: nothing is deleted or locked).
Beginner4 min read