Git Like versioning

Share an idea
22

Please vote, and we will beat the Dark mode request :grinning:

3 Likes
23

+1 On Git Like Versioning!

4 Likes
24

+1, really need that kind of feature for large design team

1 Like
25

For me this is one of the biggest problems in Figma and the new Abstract plugin is oriented towards communication, not versioning. Hopefully this will get some traction.

3 Likes
26

@Diego That’s a good reason to vote :slight_smile:

27

1. Describe the problem your experiencing and how your idea helps solve this

You really cant track what kind of change was made to the library file, change can be registered even from X Y position change, etc.

I would love to see some change list, as git has before and after. Specific information about what I’m about to update to the library. Selecting what changes to publish would be a good add-on also. I may have some drafts that I want to publish later time.

*3. Ask questions to bring the community into the conversation *
(e.g. Does anyone else experience this? Is anyone using a plugin or workaround to help solve this?, etc.

2 Likes
28

Hello and welcome @Erno_Tuovinen :slight_smile: You’re definitely not the only one experiencing this. Please vote :top:

1 Like
29

It would be amazing to have this for community UI kits too! Where I can fork a UI Kit and then when the creator updates their file, I can merge those updates into my copy.

30

We don’t need “git like” functionality in figma - git already does that. What we need is the ability to use git itself within figma and to integrate and connect with tools like gitlhub, gitlab, and bitbucket. Figma could use git in such a way - at a fundamental level - that you are able to use actual git from within figma (pushing, pulling, cloning, branching, merging… all of it) just like an IDE integrates with git and allows you to work with it from within the IDE. Figma doesn’t need to replace git. Git does a wonderful job of version control already; and, frankly, having figma do something like it would just add more tools that do the same thing to the workflow. In addition, your project would become split between the two tools and you would be separating parts of the team from one another as a result. By integrating git into figma you could keep all stages \ phases of your project in one place → git - and work with one tool for all of it. By keeping figma projects in a git repository you could either make a dedicated branch in git for “design” or a repository of it’s own. Either way you would also then have all the stuff that comes with the repository (issues, boards, kanban, scrum, wiki, all of it). Let git do what it does best and figma do what it does best and combine the two. That scenario increases what both tools are able to do exponentially!

PS: Then people could start making plugins for your IDE that would allow you to work with figma (if even in a limited sense) in your IDE - integrating git with figma would open up that possibility.

Examples:

  • It would open up the possibility for a plugin to bring the properties and css stuff from a figma project directly into your IDE using a plugin via the figma in your git repository.

Here’s what a workflow with figma / git integration might look like…

  • You create a repository for your entire project in github, gitlab, or bitbucket for your entire team (not just the designers but the devs and everyone else too).
  • You create a branch in that repository either directly from within figma or through your IDE, the command line, or your cloud or self hosted management application of choice (github, gitlab, or bitbucket in this example) and then pull the branch into figma - either way).
  • You work in figma on that branch being able to use full git functionality right in figma (or do manipulations on the branch outside of it in your IDE or management application of choice) and have that reflected.
  • You push changes to your branch directly to upstream the same way you would from your IDE.
  • You pull changes down from upstream to sync your branch with the rest of your team (figma still has its full team functionality which is needed - there is no cross over).
  • When you finish a project in figma you can archive it (leave it upstream and take it out of active status - out of availability) in figma.
  • If you need to work on the design aspect of that project again in the future you unarchive it or pull it back into figma (thus keeping your active projects in figma limited to just what you need).
  • All the while your entire team is able to connect all the other functionality of your repository management system with the design part of the project allowing other non-design members of your team to interact with the design (board / project management features of github, gitlab, bitbucket for the pm members of the team, wiki for documentation, issues for review and feedback, etc)
  • Then, when the design is finalized, the properties of the project get pulled into your IDE through a plugin from the figma content in the repository - right where it is needed so development can access it right in the IDE.

All because of integration with an existing, robust system that has robust features in it’s own lane.

Something like that ^

5 Likes
32

YES to Git versioning.

I’ve been working with developers over the years and Git versioning is the best system I’ve used so far, would be great to have in a full-cycle product design workflow. We really need this same versioning system for design process as we encounter so many issues with devs on designs, things get lost in translation, wrong things developed, or we spent huge amounts of time to make changelog and documentation for changes in pages…

We should collaborate and iterate seamlessly with our teams, just we do while we write code and develop the designs.

Currently in Figma, there is only version history, that has no value in product design cycle for teams. I’ve only used to restore couple of components.

Hope Figma team knows how important this is, and how much we suffer because of this.

2 Likes
33

Yes! https://help.figma.com/hc/en-us/articles/360063144053

It’s a bit disappointing that it’ll only be available on the Organization Plan… @Figma Is it correct? What about Professional Plan?

2 Likes
34

Hey @Pavels_Amosovs! You’re correct that branching & merging is currently limited to beta testing for individuals on our Organizations plan.

We don’t have any immediate plans to roll this beta out to users on our Professional plan, but we’ll pass the feedback along that this is something you’d like to see.

2 Likes
35

Also disappointed this is only for org users. This would be such a useful feature for me as a solo designer on a small team plan. I’d maybe be open to paying a little more to get access to it, but not so much to switch to an Org plan when I’m the only designer at my company.

Figma shouldn’t just be for big teams.

4 Likes
36

I created a specific request to make branching available for non-org teams.

3 Likes
37

Thanks. I think many designers here will agree that the branching feature should be available on the Professional plan when it goes out of beta. The price difference between professional and org plans is just too big but the branching would be hugely beneficial for so many designers who have subscribed to the professional plan.

4 Likes
38

I would just like some type of version control on Figma projects. For example, we had someone delete a component and had to get the original designer to place it back in. Would have been nice to just identify when it was deleted and copy and past it from that version.

39

Hi @Matthew_Beasley, there are currently two options:

  1. Version history;
  2. Branches (Beta, for Organization plan).
40

The thing is we have basic version control in the forms of History and Branching but it’s still difficult to VISUALLY identify changes or for them to be otherwise highlighted.

Clicking through the file history can show large changes but what about smaller ones? Changes across multiple pages? It’s useless for that. Branching is great when you know you’re going to do a major or discrete update but what about after the fact?

With multiple people editing everything, it would be nice to have a visual way to inspect the history. That way we could quickly demystify who did what, when; or we could watch the evolution of a single component.

For instance in a design system very much in progress, someone identified some inconsistencies in the type ramp styles. Did that arise from edits that I did? Something that I missed? Another person? When did they happen? If I could just zoom into the type ramp and poke at the objects with some history spyglass tool, I could answer all those questions in a few seconds. It’s useful to learn these things so that future problems can be prevented.

If instead I try going through the whole document History, that could take hours and I still might not see when the change occurred.

The “Branch review” screen is a great start in that direction but:

  1. I can only zoom in to 100%.
  2. No pinch zoom / pan control.
  3. Nothing can get highlighted on the previews.
  4. The change detail list is view only. No selection to highlight in the canvas. No ability to disregard individual changes.
  5. It’s only available to see changes done on a branch. No screen like this for seeing file history changes.
2 Likes
43

Love the fact that I can branch on a file. Only wish I could lock the main “prod” file (esp to a library) so that all editors must use branches – ultimately keeping autosaves of other team members from effecting other lower branches.

19 Likes
44

This is so important. Even the design leads often forget that they are on the main file instead of a branch and end up making huge changes to the entire file without realizing.

1 Like