Gitに限らず、バージョン管理システムで、コンパイルされたバイナリや、自動生成されたスクリプトを含めないというのは、プログラマの間では通念になっていると思います。それでは、デザインワークは? というとあまり扱いが統一されていません。
| コンパイル後のファイル | ソースファイル | |
|---|---|---|
| ソースコード | 含めない | 含める |
| デザインワーク | ? | ? |
デザインワークもコンパイルが当たり前に
従来、手作業でアプリケーションからエクスポートして、リポジトリに入れていましたが、現在その必要はほぼなくなりました。まだこの1,2年の話ですが、デザインワークでも「ソース」になる.sketchや.psdファイルから成果物を自動生成(コンパイル)するのが一般的になりつつあります。
面倒なスライスの切り出しといった作業は、もう過去の話です。一度ツールを設定してしまえば、あとはプログラムのソースコード同様に、コンパイルのためのコマンドが自動的に成果物を出力してくれます。
Gitに含めるべきは何?
そうなってくると、リポジトリ管理の原則に当てはめると、デザインワークもソースファイルのみを含めるべきということになりそうですが、現状、必ずしもそうはなっていません。GitHubなどのリポジトリを見ていても、次の3つが入り乱れています。
生成ファイル.jpg .svg
|
元ファイル.sketch .psd
|
|
|---|---|---|
| '00年代派 | 含める | 含めない |
| 折衷派 | 含める | 含める |
| 原理主義者 | 含めない | 含める |
「プログラマ業界」であればコンパイラの多くがオープンソース化されていますが、デザインツールはAdobeを筆頭に今もほとんどがプロプライエタリなツールです。そのことが、原理原則に沿うのを難しくしています。
- 複製不可能な部分に価値を置くという文化的な面
- ツール開発にコストがかかるという金銭的な面
もあって、ツールがオープンに向かうことは当面なさそうです。Blenderという例外はありますが、GimpやInkscapeは実質プログラマだけのためのツールになっています。そういえば、Fireworksのオープンソース化嘆願はどうなったんだろう...?
ツールが有料
デザインツールはときに高額です。また、セットアップに割く時間も「見えない」コストです。残念なことにインストールも自動化されていません。caskも使えません。$ npm installでは片付かないのです。また、アップグレードの問題もあります。
- Sketch - $99
- Affinity Designer - ¥5,000
- Adobe Photoshop - ¥11,760 / 年
- Adobe Illustrator - ¥26,160 / 年
これらのツールを、ビルドのためだけにチーム全員が導入するのは、金銭的にも時間的にも、もったいない話。少なくとも、Adobe税をプログラマが払う必要はないはず。
変換ツールとコマンド
ただし、本体(デザインツール)をインストールせずに使えるツールが用意されているケースもあります。注目するポイントは、
- 本体の要/不要
- CLIがあるか
- 無料かどうか
の3点です。現状ではsketchtoolが一番使いやすいように思います。Photoshopは、アセット生成機能がCC版から入り、いくらか改善が見られますが、自動コンパイルのプロセスに組み込むには未だ不安を感じますが、どうなんでしょう...? (著者はSketchにスイッチしてしまっているので、Photoshop関連自信なし)
| ツール | 対象 | 要本体? | CLI? | 価格 | 備考 |
|---|---|---|---|---|---|
| sketchtool | Sketch | 不要 | ◯ | 無料 | 公式ツール |
| Layer Exporter | Illustrator | 要 | × | 無料 | サードパーティー |
| choppy | Photoshop | 要 | ◯ | 無料 | サードパーティー |
| generator-assets | Photoshop | 要 | × | 無料 | 公式ツール |
| Slicy | Photoshop | 不要 | × | $29 | サードパーティー |
フォントのライセンス
もう一点、注意したいのが「フォント」です。たとえ、アプリケーションがインストールされていても、フォントがなければ正しく描画されません。
- マシンごと/人ごとのフォントランセンス料が発生する
- そもそも、全員のフォント環境揃えるとかムリ (←自動化不可能案件)
現実解は「エクスポート設定した部分は、アウトライン化する」しかありません。
ファイルが巨大
動画や3Dのデータが対象になると、そもそもGitに置くのが不適切という場合もあります。動画であれば、生成ファイルがMPEG4で、辛うじてGitに置けるということはありえます (説明動画をアプリ内に含める場合など)。ただし、これは例外的なケースなので、動画に特化したリポジトリを別途立てるのが本筋でしょうか。
- Git Large File Storage (LFS) - 2015年4月にGitHubがアナウンスして早期ユーザ募集中
まとめ
ケースバイケースな感は否めないものの、基本方針として元ファイル(.psd .ai .sketch...etc)は必ずコミット。生成ファイルについては、状況に応じて...ですね。
Adobeコース
もし、Webデザインで、まだPhotoshopにしろIllustratorにしろ自動化ツールを試していないなら、導入を急ぎましょう。ただし、CLIが不十分なため、CI(継続的インテグレーション)に組み込むのは時期尚早の感あり。
- 元ファイル: 必ずコミット
- 生成ファイル: 基本コミット
Sketchコース
すでに、Sketchにスイッチしているならsketchtoolを使わない手はありません。ビルドプロセスに組み込むことができて、プログラマもデザイナもハッピーです。
- 元ファイル: 必ずコミット
- 生成ファイル: 基本コミットしない
ただし、次の指針のようにMac率が低ければ生成ファイルも要コミット。
-
全員 Mac - 全員に
sketchtoolを入れてもらいましょう。無料だし。 -
ほとんど Mac - 全員に
sketchtoolを入れてもらいましょう。ただし、Windowsユーザがビルドプロセスで止まらないよう、スキップ可能にします。 - デザイナーだけMac - 生成ファイルを含めます。Sketch関連のタスクは、デザイナだけ実行できるようにしておきます。