Figma Git Integration

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 SDLC 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.


  • 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 figma in your IDE or management application of choice) and have that reflected.
  • You push changes to your branch directly to upstream from figma (the same way you would for code with 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 (such as boards / 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 in your IDE - 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.


Isn’t this like asking to integrate Git with Google Docs?

How would Git versioning work when anyone can edit a Figma file at any time, even at the same time? I also don’t know many devs that pull code directly out of Figma, Zeplin, etc. They usually just use bits an pieces or just as a reference.


I’m sorry if I’ve done something wrong. I’m somewhat new to this and wasn’t sure how to approach it. After adding a comment to the Git Like versioning topic I realized that this idea is very different than that proposal and would be best put on it’s own. Please allow this topic to remain as it is not the same as the other one. In fact, it is actually alternative to the other one.

Should I delete my comment in the other post so this one can remain?


Jake, I think your idea is more related to the design hand-off to development and the “design to development” workflow in general. The original idea was about the designer’s workflow specifically, a more powerful version history that we already have in Figma

1 Like

How would Git versioning work when anyone can edit a Figma file at any time, even at the same time

There is a difference between " anyone can edit at any time " and " even at the same time " they are two different scenarios…

Where collaborative editing is involved it is the " even at the same time " scenario. In that case…

It doesn’t matter how you arrive at a new version / commit - whether it’s one person making changes or many - a new version is a new version just the same. It’s up to the decision maker for that team to decide how to handle that situation by implementing policy and lead the team in realizing that outcome. If your team engages in collaborative editing then the decision maker for that function within the team needs to introduce and enforce the expectations for that part of the workflow and repository management that work for that team.

When a new version is produced (no matter how you arrive at it) you make a commit.

Git also has branches remember? So if you wish each member of a collaborative editing session could actually have their own branch - they each have their own seat in Figma they could each have their own branch where just the edits that person did would be in their commits on their branch, then merge or rebase (as usual).

Where independent but concurrent editing is involved it is the " anyone can edit at any time " scenario - and that is what git is made for. In that case…

You use git in the same way you use it for anything else. Each team member working on that design has their own branch and they regularly push / pull to keep work in sync. Conflicts are resolved in the usual manner as with anything else (same git same solutions different application - now it is design which it is being used for).

I also don’t know many devs that pull code directly out of Figma, Zeplin, etc. They usually…

So you want to stick to tradition even if a (possibly) better solution presents itself? If that’s how we made decisions with everything there would be no progress at all.

They… just use bits an pieces or just as a reference.

They haven’t had a solution like this made available to them. If they want to stay in the dark ages they can, it’s “their” choice - but I don’t think that’s a very wise way to operate.

Besides, even if you don’t include code from Figma in your dev workflow, all the rest is still a viable solution. If they don’t use code from Figma now they don’t have to use it then either. No one forces you to do anything, they just provide options. Same as it is now.

1 Like

Versioning is what git does. It’s the reason git was created and it is classified as “DVCS” (Distributed Version Control System).

The difference between integrating an existing tool and creating a new one depends on whether the existing tool is already being used in other parts of the project. And in that case git (or other less popular tool) is already being used in most teams. Developers use (usually / most commonly) git - in some (less often) circumstances a different version control system. But the point is that organizations do already have a tool for that, that the rest of the team is already using.

So then the difference becomes whether you include the other parts of the team and project (ie: the design part) into the existing tool being used by the rest of the team or introduce more stuff for the same purpose - thus creating additional complexity, overhead, the possibility for errors, and driving the wedge between your team members deeper. If all the team members use the same tool it costs the organization less, reduces the amount of work required to accomplish the same goals, reduces error, and connects the team together.

Since .Figma files (what is under the hood of every Figma project) can be version controlled it can be version controlled by git already just like anything else. That makes it not just possible but a convenient solution to implement.

Keeping all your work together, using one tool for one purpose (rather than several tools for one purpose) is always smarter, faster, less error prone, and more conducive to the synergy of the team, the profit of the organization, and the benefit of the client / customer.

The original idea was about the designer’s workflow specifically,

The designer is not a lone wolf (unless he is a freelancer or something). He is a part of a larger effort that is already using an existing solution made for that purpose (version control) which is a mature, robust, and proven solution. The designer should be a part of the team, not an independent player. That is the whole point. Bringing whole team together in the most efficient and productive way possible.

1 Like

What if a whole different world exists too where designers and teams are efficient and productive without Git? :slight_smile: :grinning: I’m not against Git in any way and use it too. Just sayin’ :slight_smile:

1 Like

Then why are they asking for a solution that git provides? I’m not against choices (that’s why I love FOSS) but I do need to point out this is a response to something. A solution is being asked for before I ever came to figma. I’m just responding to that need with an alternative proposal. in a way that is advocating for choice. It presents more options.

1 Like

First, this conversation is moot because Figma announced branching today :+1:

Personally, I’ve used git for several years now. It’s great for text (code).

But branching & merging design files can be complicated and tedious. We have to match items visually that can be imperceptible and spread throughout frames & pages.

We haven’t had a strong track record for design branching yet. Abstract had terrible branching dependencies and Plant had long wait periods while transferring huge design files. Neither handled conflicts very well.

I’m hopeful Figma will have solved a lot of this with Branching.

1 Like

Did they? I’m curious if git-literate users are satisfied.

1 Like

@hans.gerwitz as mentioned before, figma has introduced branching and merging in late 2021. You can read more about on their best practices page - Branching in Figma

It’s just available in plans above the team plan (organization and enterprise as you can see here -
Pricing for Figma's Free, Professional, and Organization plans.).

Speaking as an open source project leader, and a developer (not a designer) git integration that allowed a project to save the current version of a Figma deisgn in it’s repo would allow future designers to get that version of the design and make changes from there. It would also allow the repo to recognize the designer’s contributions to the repo, along with all the other contributions.

Branching and merging would be nice, but the basic need is saving the current version of a design, and better recognizing designers contributions.


I want to add that lots of designers are making contributions to projects on git, but they are not getting recognised for it. And Figma is not getting recognized as an important component of the development stack. On github you can see that projects are using javascript or python and various other tools. But Figma doesn’t show up. If it did, I think that would be better for the Figma community and the designers who are making important contributions.

1 Like

It’s a shame that very few of you are even amusing the idea of a git integration. If we had a Figma git integration, then the code generation for the UI components released from Figma into a repo could have been automated, and latest data types, and business logic could have been fed into Figma…

Neither tool would replace the other, the point of an integration is that it allows two tools to collaborate on common goals

1 Like

If I understand it correctly that is the reason why there still is a tool like Zeplin.

DevMode is aiming to the right thing but it is still a way to go.
A file export (or archive) would be really a nice move