I used to treat Git as a developer-only tool — a mystical system that designers didn’t need. That changed the first time I had to send a zip of layered PSDs and a folder of exported assets to an engineer and then spend an afternoon re-exporting, renaming, and reconciling conflicting files. Since then I’ve made Git a core part of my solo design workflow. It’s not just about version control: it’s about creating predictable handoffs, keeping assets organized, and preventing the painful “which-is-the-latest” email chain with devs.
Why a Git workflow matters for solo designers
Git does more than save file history. Here are the benefits I care about the most:
Reliable versioning for design assets so you can roll back without rummaging through old hard drives.Smoother collaboration with developers — branches, PRs, and clear commits make handoffs predictable.Fewer merge headaches when assets are structured and exported in ways that play nicely with text-based diffs.Automations and CI checks that can validate tokens, asset sizes, or run visual regressions (for advanced setups).Repository layout that scales
Start your repo with a predictable structure. I use one repo per project (not per file type) and structure it like this:
README.md — project goals and onboarding notes.gitignore — files to ignore (local exports, system files)design/ — master source files (Figma exports, .sketch, .ai or organized .psd)assets/ — production-ready exports (svg, webp, png, icons)tokens/ — design tokens in JSON or YAML (colors, spacing, typography)specs/ — handoff docs, accessibility notes, interaction specsThis layout keeps sources and created outputs separated, so engineers don’t accidentally overwrite a source file with an exported asset.
Handle large binaries: Git LFS and file locking
Design files are often large and binary. Don’t commit raw Figma .fig files or huge PSDs to regular Git — they’ll bloat the repo. Use Git Large File Storage (Git LFS) for binaries:
Install Git LFS and track file types you need: git lfs track "*.psd" or git lfs track "*.sketch".Commit the .gitattributes generated by LFS so teammates get the same tracking rules.Use file locking (supported by Git LFS and GitHub/GitLab) when you need exclusive edits on a binary to avoid conflicting versions.Alternatives: for very large or many binary assets, consider a dedicated asset server or cloud storage and keep only production-ready exports in Git.
Make diffs readable: prefer text formats where possible
Git shines on text files. When you can, export assets as text-friendly formats:
SVGs instead of flattened PNGs — they’re text and diffable. Optimize with SVGO to keep them tidy.Design tokens in JSON/YAML — developers can import them directly into the build system.Use SVG symbol sprites or icon fonts for icon sets, which makes updates incremental and mergeable.When using tools that can export structured source (e.g., Figma → SVG, Tokens Studio plugin), wire them into your repo instead of dumping binary screenshots.
Branching model for solo designers
Even solo you should use branches. I follow a lightweight model inspired by feature branching:
main (or master): always deployable — production-ready assets and tokens.dev (optional): integration branch for staging-ready stuff.feature/your-feature-name: for scoped design work (new components, page variations).Why? Working on a feature branch prevents partial exports from landing in main and keeps commits focused and revertable.
Commit messages and commit granularity
Commit often, but keep commits meaningful. My rules:
One logical change per commit (rename, export, token update).Use clear messages: “Add hero section assets + responsive SVGs” or “Update primary color token to #0f62fe”.Include links to design frames (Figma URLs) or tickets in the commit message for context.Pull requests and handoffs to developers
Pull requests aren’t just for code. Use them to hand off design changes and get feedback:
Create a PR from your feature branch into main/dev.In the PR description include rendered previews, Figma frame links, and a short checklist: assets exported, tokens updated, accessibility notes.Request a review from the engineer(s) who will implement the change.This makes your intent explicit and gives developers a single place to find the design, assets, and conversation.
Prevent merge conflicts
Conflicts happen when multiple people edit the same file. You can reduce friction significantly:
Split large binary files into smaller logical pieces (individual icons, components, tokens).Prefer text-based assets (SVGs, JSON tokens) that can be merged automatically.Use feature branches and rebase or merge frequently to keep your branch up to date.Use file locking for binaries when you need exclusive edits.When a conflict does occur on a binary, the safest approach is to coordinate: communicate with the other editor, decide which version is canonical, and consider exporting a new combined file.
Automation and checks
Set up a few automations to reduce repetitive work:
CI check that validates tokens (e.g., ensures color names follow conventions).Pre-commit hooks to run linters on SVGs or JSON tokens (husky + lint-staged works well).GitHub Actions or GitLab CI to build a preview site from the assets for visual review.Tools and UX-friendly GUIs
You don’t need to be command-line-only. I use a mix depending on the task:
Figma for design sources; use Plugins (like “Figma Tokens” or “Figma to Code” exporters) to keep tokens and SVGs exportable.GitHub/GitLab for hosting and PRs.Git clients: GitHub Desktop, Fork, or Tower for easier branching and stashing.Design-specific plugins: Abstract (for Sketch), Plant, or Kactus if you’re on Sketch and want Git-like workflows with visual diffs.A practical example workflow
Here’s a simple end-to-end flow I use:
Create a feature branch: git checkout -b feature/hero-redesign.Work in Figma. Export icons as optimized SVGs to assets/icons/. Update tokens/colors.json.Run pre-commit hook to validate JSON and SVGs. Commit often: “Add hero SVGs” → push branch.Open a Pull Request: include Figma link, screenshots, and a checklist.Engineer reviews and requests small change. I update tokens and SVGs on the branch, push, and the PR updates automatically.Once approved, merge into main and create a release if appropriate.Sample .gitattributes entries
| Pattern | Behavior |
| *.psd | filter=lfs diff=lfs merge=lfs -text |
| *.sketch | filter=lfs diff=lfs merge=lfs -text |
| *.svg | text |
| tokens/*.json | text |
These entries tell Git LFS which files to offload and ensure SVGs and tokens remain as text for diffs.
Adopting a Git workflow as a solo designer is an investment, but the payoff is real: cleaner handoffs, fewer accidental overwrites, and a clearer history of design decisions. Start small — track SVGs and tokens first, add Git LFS for big files, and introduce branches and PRs when you’re ready. The smoother your repo runs, the less time you spend rescuing files and the more time you have to design.
