Version control your designs with Sketch and git
Disclaimer
This is a workflow with disadvantages and on some projects it might not be suitable. It is also a workflow that considers the tools within a specific organisation: Sketch for design and no design version control tool like Abstract or Plant.
Inside Inflight IT we use Abstract, but sometimes that’s not an option, and it shouldn’t be an excuse to not use version control. That’s why I’m sharing this tutorial in the hope it will help somebody out there.
I will write a small tutorial showing one of our workflow processes at Inflight IT for working with design teams and it’s assets, from project managing to file version control.
For this tutorial I will be using Sketch + Gitlab + Github Desktop.
Build a repository for your project
Having a repository allows everybody to have access to the project by cloning it to their machines, without needing additional software to do so. It can be done using the terminal only, or for people who are afraid of it, using a GUI client like Github Desktop or Sourcetree that basically replaces terminal commands with buttons.
All the files needed for a project will sit on that repository, that can be created on version control platforms like Github or Gitlab.
Clone the repo to your machine
Now that the project and the repository are created you can clone it to your machine. You can do it with the terminal or by using a git GUI client.
After cloning it, it will sit on the directory you’ve chosen.
Initial commit
Every time you make a change to a file, git will detect that change and stage the files affected for committing to the repository. Contrary to cloud services like Drive or Dropbox, your changes won’t be noticed until you actually commit and push them. And only when the other contributors pull those changes, these will be visible to them.
Let’s add our first file to the repository (technically not the first, since when we created the repo we also created a README.md).
On the first area you will see the files that are staged for commit, ie the files you’ve actually changed on Sketch, inside the repository directory.
On the second area you have the commit message field, the description field and the “Commit to master” action. Here is where you make a description of the changes made. The commit message should be simple so the change can be understandable at a first glance for anyone in the team.
If there’s more information to be included and does not fit in the commit message, the description field can be used.
After that, let’s do our first commit and push the changes to the repository.
Manage who’s doing what and when
A critical part of keeping a project properly organised is to know at every point in time, who’s doing what.
One of the problems with working on git with sketch files in this process, is that we cannot work at the same time on the same file. If that happens, only one version will prevail over the other.
It is of extreme importance to keep a project board where everyone involved knows what there is to be done, and knows that if an issue is in progress it means that that while it’s there, it’s a responsibility of that person.
There are plenty of tools and ways to manage projects. Sometimes we use Gitlab, but anything can be used, wether it’s displayed on a Kanban-esque style or in whatever floats your boat, as long as it’s clear what is being done.
We use mainly these four columns, where we place all the issues in a backlog - Open -, pass to to do what’s been defined to enter in the next sprint, and put in progress what’s being done.
After a commit is done and pushed to the repository, the issue must be closed and removed from the in progress list.
It’s a great way to manage a team and have a broad understanding of what’s to be done at every time of the project.
Discard changes
You can easily discard changes, even after saving a file. As long as it wasn’t committed, you can discard them and the stage will be ignored. The .sketch file will look untouched.
Unlike cloud services, where if you save a file it is instantly synced and available to everyone, with this workflow you can do as many mistakes as you want.
Revert changes
Let’s say you made a change to a screen, committed and pushed that change to the repo, and it’s know done and shared with everybody. But later that change is to be removed, because it was decided to do so later on.
You can simply go to the commit of that change and choose to revert it. Note that if there are any changes made between these two points in time on that particular file, you’ll lose them.
Browse through past versions
If you want to see how a determined file was on a previous commit, you can access that by Gitlab. Just go to the file you want and enter the History tab.
There you will see the commit list for that specific file, and from there you can download the file with the sate of that specific commit.
There are many more things that were not covered here that can be done with this system. We can use a branch model for managing feature designs, we can add tags to projects, we can enable merge requests, and we can (with a plugin) append a git diff to commits by exporting .png from changed artboards.
This is not an ideal workflow, I know. But there were many times when we’ve worked inside organisations that didn’t had any kind of version control system and only relied on cloud systems. While Abstract, Figma, Sketch Cloud, etc are amazing tools, sometimes there are limitations and this was one of the solutions we found and implemented successfully, and that is currently working as the workflow for a big scale project.
Regardless of what tool and workflow you use, the most important thing is to always keep your projects organised so that everybody can consult the project status and history without losing work on the way.
