Maybe on confused on how the feature works. If the team is using for ideation and keeping the master branch clean for devs and clients. When it comes time to push elements from a branch to the master file, currently it pushes the entire branch. This is pointless. We don’t want all the ideation, all the options, all the throw away work, just the version that we moved forward with.
Currently we need to make a new branch we call “to be merged” and we need to copy just the artboards that are approved into the new branch then merge from there. This feels like to many steps and is complicated on a team of 4 designers. Shouldn’t there be an option to select just the artboards, components, styles, etc that we want to bring forward and leave all the other work in the archived branch incase we need to go back and grab something from it in the future?
Pushing everything makes the feature feel useless because you’re either deleting all your ideation or creating “merge” branches to make sure you don’t lose your work.
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.
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:
Select one or several frames you want to iterate on, creating a branch to bring these into
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.
Make changes to the frames in question, then explore multiple versions of the original in by making duplicated frames as you wish.
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.
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.
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.
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.
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.