GitFig: Git Version Control and Bidirectional Design Token Sync in Figma

When Design Systems Meet Version Control

In modern product teams, a persistent gap exists between design and development collaboration. Designers maintain increasingly complex design systems in Figma — design tokens, variables, styles, multi-theme modes — while engineers manage code in GitHub through branches, commits, and pull requests. These two systems operate independently, with synchronization often relying on manual exports, copy-pasting, or fragile intermediary scripts.

Design tokens, as the cornerstone of design systems, are a mechanism for abstracting visual properties (such as colors, font sizes, spacing, border radii, shadows, etc.) into platform-agnostic key-value pairs. For example, a token named color.primary might map to #0066FF in light mode and #4D9AFF in dark mode. This concept was first systematized by Salesforce in their Lightning Design System, with the goal of enabling design decisions to flow consistently across design tools, Web, iOS, Android, and other platforms as structured data. Design tokens are typically organized into hierarchical layers: Global Tokens, Semantic/Alias Tokens, and Component Tokens. This layered structure makes theme switching and brand customization manageable.

GitFig (built by Dan Schmitz) aims to bridge this gap. It's a Figma plugin whose core capability is enabling bidirectional sync between Figma and GitHub, bringing version control workflows directly into the day-to-day maintenance of design systems.

What Problem Does GitFig Actually Solve?

Managing Design Assets Like Code

GitFig's core philosophy is to store key elements of a design system — design tokens, variables, styles, and every mode — in JSON format within your code repository. This means design assets are no longer siloed, hard-to-trace private data locked inside Figma, but can be version-controlled just like source code.

It's worth elaborating on Figma's variables and modes system here. The Variables feature introduced by Figma in 2023 was a major upgrade to its design system capabilities. Variables allow designers to define reusable values (colors, numbers, strings, booleans) and use the "Modes" mechanism to switch a variable's value across different contexts. For example, a surface-background variable could be white in Light mode, dark gray in Dark mode, and pure black in High Contrast mode. This mechanism is far more flexible than traditional Styles, but it also introduces data structure complexity — each Variable Collection can contain multiple modes, and the mapping relationships between modes need to be fully preserved during export. This is precisely the core data structure challenge that GitFig needs to handle.

The "Design-as-Code" philosophy isn't new, but GitFig's value lies in consolidating the entire workflow within a Figma plugin. Designers never need to leave their familiar canvas environment to perform operations that traditionally belonged to the engineering domain.

Branches, Commits, and PRs — All Inside Figma

The most imaginative aspect of GitFig is how it brings GitHub's core collaboration primitives into the design tool:

• Branches: Designers can create a new branch for a redesign, experimenting with design token adjustments without affecting the main line.
• Commits: Every design change can form a commit with a clear record, inherently traceable.
• Pull Requests: Design updates can be submitted for review via PRs, allowing engineers and design leads to review before merging.

For readers unfamiliar with engineering practices, it helps to understand the background of this Git workflow. Git is currently the most widely used distributed version control system, and its core workflow is built on several key primitives: branches allow developers to fork independent workspaces from the main codebase, making modifications without affecting others; commits are snapshots of a set of changes, accompanied by descriptive messages, forming the complete change history of a project; pull requests are a collaborative review mechanism where developers submit changes on a branch for review, and team members can comment line by line, discuss, and approve before merging into the main branch. This process has become standard practice in software engineering, ensuring that code changes are traceable, reviewable, and reversible. By bringing this decades-proven workflow into the design domain, GitFig means that design changes can receive the same level of governance.

In other words, every evolution of the design system gains a complete change history and review mechanism — something that was nearly impossible to achieve in past design workflows.

The Value and Challenges of Bidirectional Sync

Why "Bidirectional" Sync Matters

Many tools on the market can export design tokens one-way from Figma to code, but bidirectional sync is the key to truly closing the collaboration loop. When an engineer directly modifies a token value in the codebase, GitFig can sync that change back to Figma — and vice versa.

This addresses the thorniest "Source of Truth" problem in design system maintenance. "Source of Truth" is a core concept in system architecture, referring to which copy is considered authoritative and final when multiple data copies coexist. In the context of design systems, this problem is particularly acute: designers define a color system in Figma while engineers maintain corresponding CSS variables or JSON token files in code. When one side makes a modification without notifying the other, "data drift" occurs — the data on both ends gradually diverges, causing the end user's interface to not match the design specs. This drift is especially prevalent in large teams because modifications are frequent, participants are numerous, and manual synchronization is virtually impossible to do without gaps. The core value of a bidirectional sync mechanism lies in automatically detecting and eliminating this drift, keeping the design and code sides consistently aligned, reducing communication costs and visual inconsistencies.

The Potential Complexity of Bidirectional Sync

Of course, bidirectional sync also introduces higher implementation complexity. When JSON-formatted tokens travel back and forth between Figma and GitHub, how to handle conflicts and how to map Figma-specific multi-mode configurations (such as light/dark themes) to structured data are aspects that require careful design. Based on the product description, GitFig explicitly supports "every mode," indicating that it has given thought to handling themed design systems — which is precisely a weak point for many similar design token tools.

Who Is GitFig For, and Where Does It Fit?

GitFig's target users are very clear: teams maintaining design systems at scale. For small projects with just a few pages, introducing a Git workflow might be over-engineering; but for mid-to-large teams with hundreds of tokens, multiple brands, multiple themes, and tight coupling between design and front-end development, this type of tool can significantly reduce collaboration friction.

Based on Product Hunt data, GitFig is currently in its early stages, with momentum yet to take off. It's categorized across three intersecting domains: Design Tools, Developer Tools, and GitHub — a positioning that itself speaks to its ambition of standing at the intersection of design and engineering.

The design-engineering collaboration tool space that GitFig operates in has seen several players emerge in recent years. Tokens Studio (formerly Figma Tokens) is currently the most well-known Figma token management plugin, also supporting GitHub sync, though its sync model and data format differ from GitFig's. Specify positions itself as a design data platform, emphasizing automated pipelines from design tools to code repositories. Supernova offers more comprehensive design system documentation and token management capabilities. Additionally, Figma itself continues to enhance its native variable and token capabilities, including REST API support for reading and writing variables. GitFig's differentiation within this ecosystem is that it embeds the complete Git workflow (not just sync) into a Figma plugin, making branching and PR reviews part of designers' daily workflow.

Relationship to the W3C Design Tokens Standard and Toolchain

Notably, GitFig uses JSON as its storage format, which aligns with the direction of the W3C Design Tokens standard being advanced by the industry. The W3C Design Tokens Community Group (DTCG) is developing the Design Tokens Format Module, which aims to define a universal, tool-agnostic JSON format specification for design tokens. The standard defines a type system for tokens (colors, dimensions, fonts, shadows, transitions, etc.), grouping structures, alias reference mechanisms, and metadata descriptions. While the standard is still in draft stage, it has seen active participation from representatives of Figma, Adobe, Amazon, and other companies.

Within the complementary toolchain, Style Dictionary (open-sourced by Amazon) is the most mature token transformation engine, capable of converting standardized JSON token files into platform-specific formats such as CSS custom properties, SCSS variables, Swift constants for iOS, and XML resources for Android. If GitFig can achieve compatibility with the DTCG token specification, it could seamlessly integrate with these transformation tools, enabling design tokens to truly flow from the Figma canvas into production code across platforms. This will largely determine whether GitFig can integrate into existing engineering infrastructure rather than becoming yet another data silo.

Conclusion

GitFig represents a pragmatic trend: rather than requiring designers to learn complex engineering tools, it brings engineering best practices — version control, branch management, code review — to designers in a designer-friendly way. By embedding GitHub's collaboration model into a Figma plugin, it gives design systems truly "versionable" capabilities.

As an early-stage product, whether GitFig can withstand the test of conflict resolution and large-scale token synchronization in real team workflows remains to be seen. But the direction it points toward — deep integration of design and code — is undoubtedly a proposition that modern product teams should keep a close eye on.