How to Use Branching in Figma to Explore Design Changes Safely
In a shared Figma file, every change is live. That is great for collaboration and risky for files that many people depend on, such as a design system library or the source of truth for a shipped product. A half-finished exploration in the main file can confuse engineers or publish an unreviewed component change to every team.
Figma's branching lets designers create a copy of a file, work on changes in isolation, request a review, and merge back when ready. It is available on Figma's Organization tier and above. This guide covers when to branch, how to create and review branches, and how to handle conflicts when merging.
Have a feature in mind? Describe it and Vantage drafts the PRD.
A few sentences is enough: the problem, who has it and what you want to change. Vantage turns it into a structured PRD with requirements you can edit.
How this works
- We save what you typed. No AI runs on this page.
- You create a free account.
- Vantage builds a PRD from it inside your own workspace.
Why ask for an account? We’re a small team, and a full generation runs a multi-step AI pipeline that costs us real money. So we tie it to a free account instead of running it anonymously. You also get to keep the result and edit it.
Your text is only used to create your project, and it stays private to your account. If you don’t sign up, we delete it after 7 days. Privacy policy
Step-by-step guide
Decide which files need branching
Not every file needs branches. Branching is most valuable for design system libraries, files that engineering builds from, and files where several designers work in parallel. Early exploration files can stay simple. Agree as a team which files require branching for changes.
- List files that many people depend on
- Require branching for design system libraries
- Consider branching for product files that engineering builds from
Create a branch
From the main file, use the file menu or the file name dropdown to create a branch. Give it a descriptive name that references the work, such as 'checkout-redesign' or a ticket ID. The branch starts as a copy of the main file at that moment.
- Open the main file
- Create a branch from the file menu
- Name it after the feature or ticket
Work in the branch and keep it updated
Make your changes in the branch. If the main file changes while you work, update the branch from main to bring in those changes. Updating regularly reduces conflicts at merge time, especially for long-running branches.
Request a review
When the changes are ready, request a review from the branch. Reviewers can see the changes compared with main and leave comments. For design system changes, include an engineer in the review so code implications are caught early.
- Request review from the branch
- Add designers and, where relevant, engineers as reviewers
- Describe what changed and why
- Address comments in the branch before merging
Resolve conflicts
If the same element changed in both main and the branch, Figma flags a conflict during update or merge. You choose which version to keep for each conflict. Review conflicts carefully; picking the wrong version can quietly undo someone else's work.
Merge and archive
After approval, merge the branch into main. The changes become part of the main file and version history records the merge. Archive the branch so the list of active branches stays manageable. For libraries, publish the updated components after merging so other files receive the changes.
Communicate merged changes
Post a short note in your design or engineering channel when a significant branch merges, especially for libraries. Include what changed, which components are affected, and whether engineers need to update code.
Common mistakes
Long-lived branches
Branches that stay open for weeks drift from main and accumulate conflicts. Keep branches short and update them often.
Merging without review
The point of branching is review. Merging your own branch without anyone looking defeats the purpose for shared files.
Forgetting to publish library changes
Merging into a library file does not update consumers until the library is published. Publish after merging.
Tips
Name branches after tickets so designers and engineers can find related work.
Use branches for risky component changes even in smaller files.
Archive merged and abandoned branches regularly.
Include a summary of changes in the review request so reviewers know what to look at.
How Vantage helps
Branching keeps design changes reviewable. Vantage adds the link to the spec: Figma designs can be imported as project context, so when a branch introduces a change, PMs can see how it affects the PRD and its tickets before they reach Linear or Jira.