.sketchファイルからJSONファイルに展開⇔展開ファイルから.sketchファイルに戻す

Sketch 43 からファイルフォーマットが変わり、構造などのドキュメントデータはJSONファイルで管理されるようになりました。
👉  [New file format in Sketch 43](http://sketchplugins.com/d/87-new-file-format-in-sketch-43)

以前同僚のエンジニアと「[デザインのバージョン管理をする世界](https://medium.com/@SKAhack/%E3%83%87%E3%82%B6%E3%82%A4%E3%83%B3%E3%81%AE%E3%83%90%E3%83%BC%E3%82%B8%E3%83%A7%E3%83%B3%E7%AE%A1%E7%90%86%E3%82%92%E3%81%99%E3%82%8B%E4%B8%96%E7%95%8C-dc948e6b9ae5)」 な話をしていたので、ついにGitで差分管理をする時代がくるのかなと期待をしています。

今までもとりあえずsketchファイルをGitで…と試みたのですが`.sketch`のファイルをそのままGitで共有してもただのバイナリファイルのため変更差分が取得できないため全く意味がないし、まるっとファイルをアップしなければならないため非常に重いです。
今回JSON化されたことで変更差分のテキストデータなどのみアップすればいいし、文字変更や角丸の数値など細かい内容をdiffで見ることができるようになります。

Sketch 43以降のファイルでは、`ファイル名.sketch` -> `ファイル名.zip` にリネームし展開するだけでSketchデータのファイル構造やビットマップデータを見ることができるので中の追加・変更されたファイルだけcommitすればOKということになりますね。

逆に JSONファイルからSketchファイルに戻そうと `ファイル名.zip` -> `ファイル名.sketch` を行いました。
するとどうでしょう…`ファイル名.sketch`を開こうとするとエラーが表示され開くことができNeee…
不可逆なものなのかなと諦めていたのですが、どうやら圧縮の方法が間違っていたようです。

👉 [SketchファイルをZIPとして展開した後にSketchファイルに戻す方法](http://qiita.com/littlebusters/items/e6798c54fbc257547315)

上記の方法でJSONファイル（展開データ）からSketchファイルにすることができました。
しばらくは展開データのみGitで共有し、ローカル上でSketchファイルを生成しなおして運用ということを試してみたいと思います。（できるかどうかは不明）

あ、そうそう。展開したままのデータだとJSONが1行にMinifyされているので、整形し直す必要があります。
これを毎回やるのが面倒なのでシェルスクリプトでサクッとできるようにしました。

# Sketchファイルからディレクトリに展開する

```shell:sketch-to-json.sh
#!/bin/sh

if [ $# != 1 ]; then
  echo "Specify the sketch file and then execute."
  exit 1
fi

fileName=$1
fileData="${fileName}.sketch"

if [ -f ${fileData} ]; then
  unzip ${fileData} -d ${fileName}
  find . -name '*.json' -exec sh -c 'cat {} | jq -rS . > {}.1 && mv {}.1 {}' \;
  rm -rf ${fileName}/__MACOSX ${fileName}/.DS_Store
fi
```
※jqコマンドを使用します。
`$ brew install jq`

test.sketch を変換するのであれば `sketch-to-json.sh` を同じディレクトリに設置し以下のように実行します。
`$ bash sketch-to-json.sh test`

`test`というディレクトリが作成され、中のJSONファイルは整形されています。


# 展開されたディレクトリをSketchファイルにする

```shell:json-to-sketch.sh
#!/bin/sh

if [ $# != 1 ]; then
  echo "Specify the directory and then execute."
  exit 1
fi

directoryName=$1

if [ -d ${directoryName} ]; then
  cd ${directoryName} && zip -o ../${directoryName}.sketch -r *
fi
```

testディレクトリを変換するのであれば以下のようにします。
`$ bash json-to-sketch.sh test`

Sketchファイルが作成されます。

というわけで、うまくできるか分からないけど SketchデータのGitライフを試していきたいと思います。

---
以下 2017年05月12日追記。

# SketchのPluginを作って頂きました

<blockquote class="twitter-tweet" data-lang="ja"><p lang="ja" dir="ltr">ぽよし氏の Shell、プラグインにできそうな気がする…</p>&mdash; くっきーさん💎 (@littlebusters) <a href="https://twitter.com/littlebusters/status/861594802294464512">2017年5月8日</a></blockquote>

くっきーさん💎 ([@littlebusters](https://twitter.com/littlebusters)) ありがとうございます。

## Sketch Exchanger - Sketch Plugin
![](https://cloud.githubusercontent.com/assets/1303440/25953688/1062395e-369f-11e7-83d5-1d71e73468c9.png)

👉  [Download](https://github.com/littlebusters/Sketch-Exchanger) on GitHub

### SketchからJSONとリソースファイルへの変換

1. プラグインを実行します。
2. 変換するSketchファイルを選択します。
3. 選択したSketchファイルと同名のディレクトリを生成し、その中にJSONとリソースを格納します（実質はSkechファイルをunzipしたものです）。JSONファイルはjqで整形します。

### JSONとリソースファイルからSketchへの変換

1. プラグインを実行します。
2. 変換するディレクトリ選択します。
3. 選択したディレクトリと同ディレクトリへSketchファイルを生成し、ファイルを開きます。

# 試しにSketchファイルをGitで管理してみた

100MBを超えるデータだったけど問題なく共有できました。

1. Sketchファイルを編集する。
2. Sketchファイルを展開し、JSONファイルを内包したディレクトリ化する。
3. 展開したディレクトリと内包されているファイルのみをcommit&pushする。
4. 他の人がpullする。
5. 展開されたディレクトリをSketchファイル化する。
6. 差分が取り込まれちゃんと変更されてる 🙌

## pros
- 最新のデザインを管理できる。
- こまめにcommitすれば作業ログが残る。
- push&pullが圧倒的に速い。
    - 100MBのSketchファイルを編集してもpushするのは数KB〜数MBぐらいで済む。
- rollbackして昔のデータに戻れる。
    - パターンとかたくさん作って、「あ、念のため残したいな」と思って別ページに置いとくとかしなくてもおｋ。
    - 「昔のあのデザイン必要だわ」にも対応できる。
- 作業ごとにbranch切って作業してmergeすることができる（できるけどめっちゃconflictする）。

## cons
- commit毎にSketch→JSONに変換するのが面倒。（逆も面倒）
- 特に変更差分をテキストで可視化し見る必要がなかった（普通に画像A→画像A'になったというほうがわかりやすい）
- 他の人が編集した際に記録されるレイヤーの開閉情報とかも記録されてしまう
    - 全てのページでレイヤーの開閉をすると当然全てのJSONファイルに差分が発生する‥（結果100MB近くpushすることに‥）
- 作業ごとにbranch切って作業してmergeすることができる
    - mergeするときに↑のようなレイヤーの開閉とか編集者が触ったかなりローカルな情報でconflictがめっちゃ発生する。
    - このconflictの解消がくっそ面倒。
- 関係者に運用ルールを強いらないといけない。

## 結論

展開したSketchファイルをGit管理して一番良かったのは、push&pullが圧倒的に速いくなる。ということだけでした。
作業ログが残ったり、最新のデザインデータ管理しやすくなる点もおすすめポイントだ（他の方法でもそれは可能だけど）
consに挙げた内容が辛すぎて、すぐ取り入れるべきかと言われると「NO」だと思います。

ただ、実際に運用してみて、もっと手軽にできるのであればデザインデータもバージョン管理できるような世界はアリだと確信しました。
変更差分のみ取得できるようになったり、各アートボードごとの画像を書き出してどのような変更があったか見られるようにするなどの改良ができれば結構使われるんじゃないかなと思いました。

ファイルサイズが小さいうちは[Abstract](https://www.abstractapp.com/)を使うのが一番いいかなぁといった感想。