Figma recently released the ability to create branches in a design file to mirror how engineers branch, review and merge their code into existing environments.
A branch is an identical copy of a design file that is isolated from the main file, essentially a playground for designers to explore, ideate and test things without impacting the original work in the main design file. When changes are made in a branch and are ready to be merged back into the main file, you can merge the changes in automatically or you can submit a review request and have anyone on the team review your work and approve it before it gets merged back into the main file.
Branching can be leveraged in a variety of ways across different contexts as you work. Figma has excellent articles detailing situations where branches are helpful and situations where branches aren’t helpful that can help guide you as you determine how to leverage branching in your own work.
Effective branch names allow us to identify the purpose and contents of the branch. At this point in time, rigorous structure around branch names is not needed to support our current processes. However, if you find yourself doing work, especially Production Support, and have a JIRA Ticket associated with that work, including the ticket number in the branch name is helpful.
TDC-13505: Shipping Kit Updates
It’s appropriate to merge the changes to the files on your own at any time, however there are a few cases where a second set of eyes on your work may be helpful:
When submitting a review request, include details / context around the review request in the description text area at the top of the review request window.
If you’re making changes to a library, don’t forget to publish the changes to the rest of the team after your branch has been merged into the main file.
As branching becomes a more robust feature of Figma, this page will be updated to reflect how we leverage the feature across our work.