1000% Agreed!!!

When working on edits sometimes people get it right on the first try and others might take some time. I only want to pull in the approved updates and leave the rest. All you would need to do is add some sort of select/,multiselect feature on the “Review & Merge Changes” screen.

This could be very similar to how the current library updates work. The library update isn’t an “all or nothing” you can pick specifically which updates you want to pull into your file. The same should apply to this merging functionality. This missing piece of functionality is crucial.

This feature is definitely a must for working with branches.

The use cases are as follows:

Exploratory work and variants

Often in my branches there are exploratory ideas and variants that don’t make it back into the main branch (spec) in the end and therefore should not be merged. Currently there is no way to keep them in the branch and bring the branch back without these changes.

Unintended and accidental changes

Sometimes small and subtle changes happen to frames, layers or components that I recognize during the merge and that I know I don’t want to bring back to the main branch. Like a dialog or menu that has been moved one or two pixels. Undoing these changes before bringing the branch back is time-consuming and unnecessary. It would be easier to just drop them.

I strongly second this request.

Also, is there a rough estimate when something like this can be completed? will updates be released continuously or in versions?

Totally agree, will be nice to have more GIT like flow for Figma branching.

+1

It’s a little bit tedious to double check the files on the board just to omit the ones you don’t want to merge.

Typical case of building a feature without understanding the value of it.

Currently, going into a branch to review is also very confusing cause every page in the entire documents exists there and there is no way to mark changes or diff within the branch in a good way.

Ideally, the branch would also only track changes to frames that have been modified. Any parent frames that haven’t been edited in the branch would be omitted. This would allow two people to work on different parts of a frame without creating merge hell.

Example of an optimal Branch workflow would be:

1. Select one or several frames you want to iterate on, creating a branch to bring these into


2. Branch is created, with a read only version of the original linked to the branched frame. This way you could look at and compare to the reference frame at all times.


3. Make changes to the frames in question, then explore multiple versions of the original in by making duplicated frames as you wish.


4. If one of the new frames is the one you want to merge, move the link from the original to that frame

Features:

• If the changes grow, you can add more frames from the upstream master that you branched from, keeping the branch to just the frames it needs to have instead of beting a copy of your whole main document


• If you create more frames/views in the branch, that you want to keep and merge as new frames in the main view, toggle them as tracked, otherwise all new items not linked to a frame in the original document are treated as temporary and don’t get merged as default (Similar to all changes that aren’t part of a commit in git)


• If you want items deleted in the master, bring them into the branch and toggle deletion.


• If you see a change that you don’t want in the merge view you can edit it, (could be basic stuff to start with, such as not deleting a frame but adding it instead etc.)

+1

I usually prefer to check other pages in ideation branch, while doing this sometimes few elements move accidentally. I just want to merge only selected pages, not everything.

+1 I totally agree!

Does anyone know the status of this? I want to be able to use the branches as playgrounds where I work undisturbed from collaborators and stakeholders, maybe making 5 versions of a screen and then merge the one the team decides is the final approved one. Using two different files can sometimes get tricky because you might forget to copy the latest version to the “final-document” so the branching functionality would solve that, but I don’t want all my experiments to be merged, but at the same time I don’t want to delete them.

+1

It would greatly help our UX team to be able to pick and choose the elements that go into our main branch.

Ideally, this would allow us to choose which changes to merge (or not) at the frame level.

But even if it were at the page level, it’d still be a great help!

Desperately need this, a lot of work is needed to clean each branch to have safe merges… even then you end up publishing changes from main that were unessasary.

It really should be like how Git works …

You do some changes in your branch. You stage the changes you want (meaning you select the things you want to send). Then you commit your changes and then merge it to the master branch.

i want to highlight that request, as the branch/merge function is currently a nice addition but not useable for complex and big projects.

Ditto all the above comments.

Improving the branch functionality is desperately needed!

Nudging this. Does Figma product team actually monitor the community forum?

The use cases and implementation are all lovely for a single designer with workflows where they work on a single ticket at a time, but thats not how most product/design teams work in the enterprise world. My team of 3 designers need to be able to generate multiple branches from the same main file, then merge back in once work as complete. The lack of any granularity in the diff makes that impossible, as they’d just overwrite each other.

The current implementation is more of a glorified versioning system. A ‘branch’ in this system is just giving the ability to name a version from version history (the current version), and compare that version side by side. It’s version history with naming and a diff modal.

Agreed. ^ Branching needs some MAJOR improvements to be useful to larger teams.

+1. Really need this ability

+1 for this. Very much needed for large teams.

What Nils says!

Keeping this request alive, we just got access to branching and I had assumed omitting or selectively merging changes in was something you could do. Hopefully it gets an update.

Keeping this alive, we are still suffering the current branching model and would love one designed to be used by designers

Coming from game development. Branching is a fundamental part of my workflow no matter the size of the team involved. Branching allows for isolation of incremental improvement, and injection of approved improvements at the right time. The ability to inject these changes in small doses AND keep the branch alive(!) after a merge is crucial.

• Branching allows designers to work on future releases and temporary changes that does not necessarily have to be a perpetual arc in the product.


• Branching protects developers from overstimulus to design ideation. Even though Figma allows for everyone to participate in design (which is fantastic), design can be very overwhelming for non-seasoned designers or stakeholders.

The current behavior is in some ways detrimental to the agility of design ideation. This is a missed opportunity for such a great product like Figma.

• Having to kill a branch when merging, thereby not being able to merge selected items from that branch, does not allow for several preplanned versions and temporary (seasonal, thematic etc.) iterations of the design being worked simultainiously.


• Having all changes pass through the main file is, which is viewable to everyone on any branch (as far as I understand) undermines the potential to isolate and direct design, sicnce everyone will end up looking to main for updated design.


• Not being able to merge one branch into another branch, increases the amount of work involved in maintaining design itterations.

I wholeheartedly agree with the changes requested here! In the way branching is currently implemented, it is practically unusable for me and our company-wide workflow. And in my opinion it neither keeps the promise that Figma made when announcing this feature (“you know it from software development and such” blabla) nor is it worth the substantial surcharge for Figma Organization accounts.

The current implementation of branching feels nearly useless. What’s the purpose of having branches if I can’t merge them effectively? As it stands, I’m only able to choose whether to keep the artboard from Branch A or Branch B, without a proper merging process.

The result: I have to choose the artboard that requires the least rework and then redo everything manually. This completely overlooks the fact that most changes aren’t full artboard overhauls, but smaller, detailed modifications within the artboards.

I recently faced significant difficulty justifying this feature to my employers, under the assumption that it would work as intended. After they finally approved it, I discovered during our first major merge that Figma’s branching feature falls short of expectations. It feels like this feature exists mainly to sell Organization seats, because in its current state, it’s practically unusable.