How does it work?

That's a good question. Instead of tracking the actual sketch files (or binaries) in git, Kactus transforms your sketch file into groups of individual text files – one for each layer/page – that are much more suited for git to work with.

Workflow

The basic workflow looks very similar to how many developers use git:

1. Clone your repo locally
2. Make your changes in Sketch
3. Commit your changes
4. Push your changes

However, when working with multiple designers, the git-flow methodology works very well:

1. Clone your repo (if you're just getting started)
2. Checkout a feature branch (e.g. feat/background-color)
3. Make your changes in Sketch
4. Commit your changes
5. Either:
   • Push your changes to your git server for others to review/merge
   • Merge your changes into another branch (master) yourself

Committing Changes

When Kactus is running (with your repository open), it watches your sketch files and re-parses them when a change is detected. This parsed (or exploded) view of your sketch file is what git tracks.

Merging two parallel branches

1. Checkout the branch you want to merge into
2. Select "Merge into Current Branch" from the "Branch" menu
3. Select the branch that you want to merge from

Sharing text styles across multiple sketch files

Existing Repos

If your sketch files are already tracked in a git repository, there are few things you need to do to get the most out of Kactus.

1. Open your repo in Kactus to generate the JSON representation of your sketch files
2. Commit the generated JSON directories
3. Untrack sketch files. In most cases, this can be done with git by running: git rm --cached *.sketch
4. Tell git to ignore sketch files by adding *.sketch to your repo's .gitignore file (create it if it doesn't exist)

Note: When you create a new repository with Kactus, it is automatically configured to ignore sketch files.