前言
抱歉当了回标题党，其实这个系列文章是关于我的设计经验谈。
首先得自我介绍一下，我目前在美国波士顿一家大数据创业公司工作，职位是设计师。我在纽约 Pratt Institute 毕业后就来到这家公司，如今也已经一年了。在这一年里，除了刚进去的一两个月因为熟悉业务的原因偶尔加班外，其余的时间都是早上 9:30 到岗，晚上 5:30 按时走人，倒不是因为闲，而是在美国这个注重效率的地方，你就会不自觉的想尽办法在最短的时间做最多最正确的事情。
我也希望通过这系列的文章，把我在设计管理上的经验分享给大家，能够帮助到一些创业团队，或者是设计师们，用最短的时间处理一些与设计无关的琐碎之事，把时间都花在真正的设计上。
下面就进入正文啦。
为什么设计师也需要版本管理
因为不是只有你一个设计师啊。
我们的设计团队有两个人，平时我负责产品，同事负责市场、销售方面的设计工作。但是有时产品迭代速率高的时候，就需要两人协作来分别完成一个项目里的多个小项目。也就是说，我们有在同一个 Sketch 里工作的需求。
之前我们是这么做的，因为我们用 Dropbox 来提交设计，所以我会现在 Dropbox 里新建一个 Sketch 文件，把所有准备工作都做好。然后同事会把这个文件拷回到本地，我们开始分别工作。完成后，同事会把文件重新命名，上传到同一个文件家，我再手动把他的部分融到我的 Sketch 文件里，检查后将这个最终的文件提交给工程师。
这个流程有很多漏洞，在实操过程中，也许同事的工作量很小，他就会偷懒直接在源文件里操作，大家知道 Sketch 目前还不支持像 Google Docs 那样的云端多人同时操作，两个终端同时操作的下场就是...
说多了都是泪。
另外的一个问题就是，同事会将文件传到相同的文件夹，往往只是在原文件名后面加个后缀，工程师就崩溃了，我该看哪个？（后来我会手动加一个 Previous 文件夹，再提交前把所有没用的文件都丢进去，但是这就加了一步，增加了我的负担）
综上，我需要的设计协作服务需要能实现以下需求
- 能方便所有设计师随时以某一设计文件为基础进行设计
- 能方便的合并相关的设计文件，把最终的文件提交给工程师
Git 不单是是程序员的好朋友
我靠，上面这两个需求好眼熟有木有？
Fork & Merge
没错，这两个 Git 最基础的功能，也可以帮助到设计师提升团队协作效率。
为了照顾一些对 Git 不太了解的朋友，这里简要介绍一下。
Git 是一个版本控制的协议，以这个协议为基础开发的服务有很多，Github 是其中最著名的一个。Git 可以做到在保证原始库安全的前提下，其他人可以安全的创造一个副本到本地，随心所欲的修改（ Github 称之为 Fork）。修改完成的文件，Git 会检测被改动的字段，方便使用者在合并两个库的时候检查究竟是哪里被修改了（称之为 Merge）。
当然我们不能直接使用 Github 来实现我们的需求，因为
- Github 目前不支持大尺寸的文件，Sketch 文件大多数都是以 M 为单位计算的，这对于大多数是几 KB 的代码文件来说实在是难以把控了。
- Github 的比对功能只支持文本文件，比对的对象也只有文本，Sketch 的矢量文件虽然本质上也是一段代码，但是把尺量文件转化成代码进行比对再复原成矢量文件进行合并操作，对现阶段的 Github 来说也是太难以把控了。
那所以我们怎么办呢？
拥抱云存储
表紧，我们可以手动 Git。
首先你需要有一个可以协作的云存储服务商，我们用的是 Dropbox，我用了好多年了，感觉最靠谱。
然后在项目的文件夹下建立三个文件夹
- branch-我
- branch-他
- master
这样任何所有人都能看到三个文件夹里的内容，也就可以随时 Fork 任意文件到自己的文件夹内随意修改。
设计完工后会进行 Design Review，负责的人会把最终稿放到 /master 文件夹里，这样工程师只需要关注 master 里的文件变化即可，他甚至可以不用同步两个 /branch 的文件夹。
可以有朋友会说，这跟之前的手动复制到本地的做法也没什么区别嘛。从本质上来讲确实区别不大，只不过复制的文件从本地到了云端。但是在实际操作中，这一点小小的改动却收到了意想不到的效果。因为团队里的所有人都有对等的 visibility，知道对方在做什么，进度如何，这点非常重要。
是时候发挥你的创造力了
我们团队内部实行这套规则已经有六个月了，设计团队内部再也没有出过问题，工程师团队更是对此感恩戴德，可以说实验成功了。
当然，作为一个设计师，任何的规章制度都不能成为限制创造的障碍。在不影响团队效率的前提下，越少的限制，才能有更多的精力去创造更有价值的设计。
后记
这只是我们这个小团队的设计经验谈，如果大家有其他有意思的方法，也希望能共享出来，不甚感激。
