Before Abstract, designers used to work with Dropbox, Google Cloud or any other cloud service. Files would get overwritten or lost.
When I started to learn how to code, I learned GIT. It was incredible to see how developers organise their code and keep a good track over what happens.
Luckily, the design tools are progressing at such rate that we too can start organising our sketch files using GIT techniques with branches, commits and more.
I cannot tell you how many hours we saved at our NFQ design team just by taking the best practices from the development world.
Today we will share what works for us so you could start doing it too.
Note: This is not a paid ad. This a tool that provided us a lot of value.
⚡️ Brief introduction to GIT
If you are well versed with GIT, you can close this article right now. I am not going to tell you anything new. However, if you are new to version control, this article will give some helpful tips and tricks to start.
Why version control is useful and why should you care?
- If you accidentally delete your design. Git can help you get them back.
- If you break something, GIT can help you revert to the previous iteration.
- Hundreds of people can work on the same design file without any conflict. GIT tracks all of the changes.
3 terms you need to learn first
Before we begin into the juicy stuff, there’s some basic GIT terminology we have to understand first.
Branch — Imagine a drawer where your designs are kept. The drawer is organised into layers of smaller drawers. One is style guide drawer. Other is an illustration drawer. This basically a branch. A project can have unlimited branches or drawers where you place specific files. It’s a way to organise your stuff into separate sections. Why is it called a branch then you ask? Well, the idea is that you can’t create new branches from existing ones. Thus branching out deeper like a tree. However, it’s not recommended to go more than 2 levels deep. It can get really confusing afterwards.
A commit — To take the drawer analogy. You open the drawer. Work on the project. Now you want to put it back so you yourself or other people could find it. An action where you upload your newest design to GIT is called a commit. You commit that design.
GIT conflict — GIT allows multiple people to work with the same design from the same drawer or branch. It’s a smart system that tracks every change that happens and then merges all of them into one file without anything being lost. Image 5 people work on the same drawing. Then, just by putting them together it magically merges into one paper design with all of your work put together. Amazing! Click here if you want to read more about branches.
HOLD UP! Sometimes the magic trick doesn’t work. And there is a conflict in the file. Git shows two conflicting versions and asks which one should I save to the cloud? You have to make a decision which part of the design to keep and which to discard. This doesn’t happen often, though.
How we name our branches
Naming branches is very important, because that will tell other team members in what drawer which things are.
Our naming tree is inspired by Git Flow and looks like this:
Feature branch — If you are working on something new. You create a branch with a feature prefix. For example feature/profile-page or feature/about-page and so on. Feature branches tell other team members who are working on which part.
Hotfix branch — If you need to make a quick fix. You create a hotfix branch from Master.
Export branch — Any tasks dedicated to exporting assets should be created with an export prefix. For example: export/about-page.
How do 2 people work on the same branch?
We try to create our own separate feature branches for the things we are working on. However, there are times where we have to jump into someone’s project and export something. Or quickly patch something up. The abstract does not allow to work on the same branch. You have to create a new one.
Therefore, we allow creating either a hotfix or export branch from the existing branch itself. Check the photo above for reference. We never go more than 2 levels deep with branches.
When I finish working on either the feature, hotfix or any other branch. I merge it to master and archive it. In our design team, there’s always a dedicated person who looks after that projects do not get congested with unarchived branches.
Design or software projects are usually collaborative. They take months sometimes years to fully design and develop. They are also touched by several people along the way. Therefore, good communication/documentation is key.
Commit messages is one of the ways to create good documentation without much overhead. If they are written well.
When we write commit messages, we tend to fall into this trap that we are the only ones who will be looking at this project. No one will read these commit messages. WRONG. Imagine a scenario where someone opens your project 2 years down the line and wants to understand why you made that design decision and add that specific solution. How will the person do that?
A good commit message should have 2 things:
- In the title write what you worked on.
- In the description explain why. Why did you make this design decision? The specific the better.
Bad commit message:
What icon? Where? Why did you even fix that icon? See how many question this commit message raises?
Good commit message:
From the get go I can see that someone has made illustration for a blog post. I then see that they were made to explain how GIT works. Much better.
I absolutely love Abstract and how it introduces GIT to the design community. No more lost files. No more overwritten files. No more head scratching on why things were made that way.
Most of the techniques I laid out are not new. Developers have been using them for years. At NFQ Design team, we bridged that gap with design version control and took over the best practices.
I will leave you with this: