搞定设计版本控制!一份超详细的 Sketch git 插件使用指南

一份超详细的 Sketch git 插件使用指南

 

袁晨皓:对每一个设计师来说,如何管理文件版本是令人很头痛的。本次教程使用Sketch的 Git 插件帮助你记录每一次的更改、处理好混乱的版本迭代,教程超详细,建议收藏!

设计师的版本控制:Sketch的 Git 插件使用案例

温馨提示:

本次案例的项目已经公开啦,http://cloud.yuanchenhao.com:30000/stevenyuan/sketch Git . Git,各位可以前往我的自建 Gitlab查看每一步的对比,不过服务器建在我香港学校的寝室里,访问速度可能较为一般,还请海涵。如果有想要实践的有问题可以加我微信804933158一起探讨~感谢!

最近自己一直在进行UI设计的学习,主要使用的软件是Sketch,很多时候在参考前辈们的意见后会进行多个版本的更改和尝试,因此不仅会出现多个版本的.sketch文件同时也会导出很多不同版本的预览图,这就导致后期整理的时候其实比较杂乱,有这么几个问题:

  1. 他人的评价很难和对应版本的文件整合起来(光塞入sketch文件里在跨版本选择的时候就需要打开每个文件比较麻烦)
  2. 同时保存多个版本的.sketch文件其实也是相对来说占空间的。

虽然Sketch其实已经有内建的不错的版本控制,但在是用上来说也只能个人独立使用,会缺乏团队协作性。

因此综上就决定开始尝试使用 Git 来进行设计文件的版本控制,因为专业的一半是写代码(c++,c#之类)所以对 Git 会比较熟悉,可以进行简单的纯命令行的进行版本控制,但可能对于很多设计师来说还是相对容易出错的,因此需要图形化的插件帮助,为此我专门去寻找了适用于sketch的 Git 插件。最终效果如下:

1464671489-8071-1zz20160302

1. 什么是it

> Git 是目前世界上最先进的分布式版本控制系统(没有之一)。

Git 是一个开源的分布式版本控制系统,用以有效、高速的处理从很小到非常大的项目版本管理。 Git 是 Linus Torvalds 为了帮助管理 Linux 内核开发而开发的一个开放源码的版本控制软件。

2. Git 托管服务的选择

Git 的版本控制可以在本地进行,但是推送到远程服务器(局域网内建也可)之后其实有更优化的版本视觉对比。现有的主要的 Git 托管库有两个一个是 Github,一个是 Gitlab,国内的 Git coffee也不错。

Github免费版本和学生版本都有一定的私人项目上限,需要付费才可以开更多的项目。同时因为服务器位于国外的原因,很有可能有链接不稳定的情况。 Git coffee用的不多。

本次范例使用的 Git 托管服务是前不久在自己寝室的服务器上建立的 Gitlab的community版本。如果是团队协作可以在内网中架设 Github服务器,既可以确保安全性也可以方便团队成员使用。(不大确定在真的商用公司是如何进行版本控制的,本文仅供各位参考,数据安全关系如需要架设自己的服务器一定要注意容灾,增加备份)

3. Sketch Git 插件的选择

>本次使用的是一款名为 Git -sketch-plugin的插件,由开发者Mathieudutour开发,是众多现有的 Git 插件中持续维护情况最好功能最完善的,项目在 Github开源,各位可以持续关注

Github链接:https:// Github.com/mathieudutour/ Git -sketch-plugin

我上传了一份0.21版本方便大家下载:http://7xr4z2.com1.z0.glb.clouddn.com/ Git -sketch-plugin-master.zip

4. 其他的技术准备

真的不要嫌麻烦哟,真的安装完之后会特别好用!

>1. Sketch >3.1 (非Mac App Store下载的版本,没有沙盒机制)

>2. 将Sketchtool安装在 /usr/local/bin/sketchtool

- Sketch官网教程: http://www.sketchapp.com/tool/

下载好最新的Sketch之后进入Finder-应用程序,找到Sketch之后右键查看包内容。

操作流程:

1464671494-1136-2zz20160302

进入Content-Resources-sketchtool,找到 install.sh

1464671492-3401-3zz20160302

启动系统自带的terminal(终端),将install.sh拖入即可执行安装程序

1464671492-5062-sketchGit24

如图所示即安装成功。

1464671492-3688-5zz20160302

>3. 安装 Git (参考 Git 的官网教程《1.4 起步 – 安装 Git 》

>4. 一个 Git 托管服务(并将本机的ssh密钥绑定方便拥有对 Gitlab服务器的访问权)本次使用 Gitlab, Github的使用可以参考这篇链接。

安装:下载 Git -sketch-plugin-master.zip

解压缩后点击 Git .sketchplugin进行安装。

1464671500-8163-4zz20160302

安装成功后的提醒:

1464671500-8597-sketchGit28

当这些都完成后可以开始啦!

5. 案例分享

1. 于 Gitlab的网页版本建立一个项目project。

1464671518-1746-7zz20160302

项目可以参照这个参数进行配置,可以设置项目为私人项目,也可以设置为public或者internal(本 Gitlab服务的用户可以访问)

1464671518-3379-9zz20160302

建立后使用 Git 命令`clone`到本地Mac中(通常我自己的路径就在自己的文件夹中)

通常直接拷贝`Create a new repository`下的几行命令进行项目文件夹的创建以及 Git 项目的初始化。

1464671518-1048-79741-db86eb352eefdf8a

在Mac系统下,可以使用系统自带的terminal进行 Git 的管理,非常方便。

1464671521-3940-10zz20160302

直接复制上方的 Git 命令拷贝入terminal

 Git  clone ssh:// Git @cloud.yuanchenhao.com:30001/>stevenyuan/sketch Git . Git 

cd sketch Git 

touch README.md

 Git  add README.md

 Git  commit -m "add README"

 Git  push -u origin master

1464671525-9209-79741-1a4037815dde8161

处理一段时间后会出现如图情况,按回车后进行本地的master(主分支)和 remote的master主分支的合并。

> Git push -u origin master

1464671526-8440-13zz20160302

执行到如图这样就代表本地文件夹和remote文件夹已经联系上了,打开文件夹可以看到一个README.md的项目描述文件,该文件是用于描述项目用,暂时可以不用管它。

1464671549-3833-14zz20160302

准备工作还差最后一步—建立你的sketch文件。这里为了方便演示,就用我之前在进行UI练习时进行到一半的稿件来演示。当然也可以直接将sketch文件复制到已经建立的 Git 文件夹或者将sketch文件复制到该文件夹。

1464671550-4071-15zz20160302

打开该sketch文件,这个时候这个文件还是属于无编制状态, Git 系统是没法管理到它的改变的,这个时候我们的主角 Git 插件就可以登场啦 —— 菜单栏-Plugins- Git -Add File to Git

1464671553-4877-16zz20160302

此时sketch下方会出现”File added to Git “就表示这个文件被追踪啦。

1464671552-8459-17zz20160302

现在我们进行第一次改动,试着改动artboard“新闻首页”的标签位置和字体:将标签移到了作者信息行末尾,将新闻标题的Lato-Light字体更改为Helvetica-Regular,不用手动按保存,sketch会自动保存。

1464671556-8552-18zz20160302

好了这是根据最新的设计潮流更改的,你决定保存一次,这个时候就要用到commit命令:Plugins- Git -Commit

1464671563-9918-19zz20160302

Sketch会弹出如图所示的对话框,commit to “master”,输入框里可以填写你对这次更改的描述,比如:客户需求1:更换字体为Helvetica,更换标签位置。一定要勾选“Generate files for pretty diffs”

这个生成diff差异文件可以说是这个插件和单纯用命令行最大的差别了:单纯的命令行操作 Git 需要你每次自己在teminal里输入比如 Git commit -m”客户需求1:更换字体为Helvetica,更换标签位置。”这样的命令,同时也需要你自己去导出示意图,非常麻烦,而这个commit命令可以很快完成这两步。

1464671584-3599-20zz20160302

commit 完成后就会出现下方这样的commit成功说明,如果有时候无法弹出就再次commit一次(一般不会出现,静候就好)。

有时候也会出现:no commit to submit意思的字样是sketch未来得及保存你的更改你就提交了commit,重新手动保存一下然后再commit就好。

1464671597-7509-21zz20160302

现在的commit完成就相当于生成了一个阶段性的存档,已经可以在本地使用 Git 回溯版本或者查看,不过为了团队协作、以及用上 Gitlab(或者 Github)系统的简洁的GUI操作界面进行对比我们需要将改动推送到远程服务器。

使用插件的push命令:Plugins- Git -Push

1464671599-4755-22zz20160302

然后sketch会卡顿一会儿,鼠标会变成风火轮旋转一会儿,具体时间视sketch文件的大小而定,文件越大持续的时间越长,此时就不要再进行其他操作了,如果sketch崩溃可能就要回到命令行去控制版本了。

不过有时候可能会跳出Failed..窗口,不用担心,其实commit已经提交到远程的master分支啦。后文会介绍解决这个问题。

接下来访问网页版 Gitlab查看现在项目的进度。

1464671605-9798-23zz20160302

在这里就可以看到现有的项目的commit了,每个artboard都有单独的跟踪,因此无论你修改了哪个arboard都可以看到版本更新,因为啥第一次commit因此没有对比照,我们再进行一次提交来使用对比功能。(步骤同上面完全相同)

1464671923-2272-24zz20160302

在本次修改中我删除了背景的遮罩、更改了标签颜色、添加了页面的分享功能,在commits界面可以看到新的一次提交:客户需求2

1464671616-7657-25zz20160302

打开本次commit之后就可以看到版本2:客户需求2 和客户需求1之前的对比了,在右上角的模式中,请选择SIDE-BY-SIDE,方便对比。

1464671622-5818-26zz20160302

在对比模式中, Gitlab同 Github一样提供了三种模式:2-up(左右对比),Swipe(从左至右拖动对比)以及Onion Skin(剥洋葱模式)

Swipe模式如图所示,便于对比版本前后的差异,如下图就可以看到现在对比线左右标签的颜色差异、缺失遮罩的画面不同,再往右拖动就可以看到分享菜单的有无对比。

1464671922-7368-27zz20160302

Onion skin模式就是从右往左的拖动,动态的进行对比,在之前的使用过程中觉得尤其对明暗的对比特别的有用。

1464671627-2442-28zz20160302

上面的范例已经简要说明了两次版本提交以及对比的使用方法,基本上覆盖了本次使用的 Git 插件的主要功能。如果个人单独使用,可以在每一步写上你从其他人(比如主管、前辈、用户)那边得到的反馈或者参考的项目链接,可以做到每一步改动都有理论的支撑而不是随意的更改。如果是团队使用那么 Git 的功能就更方便的发挥了,可以将团队中每一个人都添加到群组中,对更改发出各自的意见建议。

1464671631-2243-29zz20160302

branch功能和其他稍微高级一点的 Git 指令就暂时就不讲啦,之后有时间再更新,不过branch和master分支的切换对于团队开发或者自己进行多次不同风格的尝试的话会非常有用,可以独立进行多个分支的设计、通过自己或者团队审核通过后合并到master主分支形成最终的版本。

其他更加高阶的操作可以参照 Git 的标准操作流程来使用 附上 Gitlab flow以及 Github的flow,两者其实理念上是一样的

两者的差异可以参考阮一峰前辈的这篇对比文《 Git 工作流程》
如果有Sketch git插件的使用的问题可以加我的微信:804933158,或者给我写邮件 yuanchenhao1026@gmail.com

Sketch教程合集持续更新中:

投稿者:袁晨皓

原创文章,作者:ioued,如若转载,请注明出处:https://www.iamue.com/15191/

(0)
iouedioued
上一篇 2016-05-31 08:55
下一篇 2016-05-31 17:04

相关推荐

  • 原型尺寸规范总结

    最近公司安排我带一下新来的交互设计师,我想给他制定一份交互设计规范。这样一来,即使新来的交互设计师没什么基础,也可以根据这一份规范,做出大致标准的原型图。 因为Ui设计稿是先做iPhone6的,方便向上适配iPh…

    2016-09-05
  • U+敏捷研发体系

    “研发是一项创造性的工作,卓有成效的研发需要优秀的研发团队来完成,优越的研发流程始终能够发现最佳的机遇,推出有竞争力的产品和服务,并以最快的速度把这些研发成果投入市场。”△ △ △ U+敏捷研发体系流程 △ △ △需求分析1研发体系中的第一个环节,这一阶段要求需求分析人员针对待开发软件提供完整、清晰、具体的要求,确定软件必须实现哪些任务。其中包含的敏捷建模,要求需求分析人员对现实问题的抽象想法构画出草图,以规避需求的不合理等问题。原型设...

    2018-03-30
  • 通知邮件,潜移默化地影响着用户体验

    在打造一个产品的过程中,创业公司往往会把绝大多数的财力和精力用在开发应用或者搭建网站上,很少投入到给用户发的提醒邮件上。

    2017-05-31
  • 为了优化夜间阅读体验,ISUX总结了一套通用的夜间模式设计方法

    你有没有在夜间使用移动设备的习惯?你觉得QQ现有的夜间模式亮度在使用时是否舒适?为了能够更科学的验证我们的设计,我们通过对比度分析、尼特值测试、色彩亮度和色彩通用性等维度去设计界面,并总结出一套优化方法来分享给大家,相互启发。

    2017-05-09
  • 写给产品经理和设计师的用户体验知识4(大结局)

    从2015年起,我陆续写了《写给产品经理和设计师的用户体验知识》系列文章,当时的写作提纲如下:第一部分:先纠结两个概念「用户体验」和「设计」第二部分:设计原则概览原则1:符合用户使用需求原则2:基于用户的心理模型设计原则3:一致性原则4:及时有效的反馈和解释原则5:形式追随功能原

    微信热点 2018-02-12
  • Justinmind 和 Axure谁更适合做原型?

    Justinmind 和 Axure 都是目前很强大的原型设计工具,被业界推为原型设计神器,在很多项目中起着不可估量的作用,但这两者的之间的作用是相互竞争还是相辅相成呢,我们应该客观地进行分析,使之更好地服务于我们的…

    Axure 2015-08-25
  • 重温《别让我思考》,这本书到底告诉了我什么【UXRen译#141】

      作者:Nick Kellingley(交互设计基金会社区经理)| 译者:天蛙,审校:xing   《Don’t Make Me Think》是人机交互和易用性工程师Steve Krug写的一本书的书名(中文版本的书名是《点石成金》)。这本书教用户体验…

    交互专题 2017-08-07
  • 那些经典交互设计流程与方法,真的足够好吗?

    在传统的交互设计 流程中,比较看重从设计目标建立到最终方案推导过程的逻辑性、终端用户体验与用户心理认知模型的匹配性等,相关的 UCD 设计方法 很多,而基本框架则是大同小异。在规模较大的公司与设计团队里,作为交互设计 师的我们也习惯了运用这种按部就班、环环紧扣的推导方式,帮助自己有理有据地应对各种「为什么这么做」的挑战。

    2017-05-25
  • 美国设计师总结:2018年的用户体验设计趋势和方法

    这是由一位美国作者站在美国的视角写的文章。即便抛开个人因素不谈,国内外的发展进度并不完全同步。例如情感化反馈这一块也许国内稍稍落后一点、但是移动支付和AR却要快一些,有些方面即便步调差不多,举出的例子却不一样。不过看看别人的总结也挺有意思,至少可以了解一下国际风向。2017年即将结束,是时候向前展望,预测在接下来的十二个月里,信息体验设计会如何。我将在本文概述的,除了2017年里见证到的巨大的变化之外,还有值得关注的趋势,以确保能够赶于...

    2018-03-29
  • 移动端设计模式的误用

    如果你是一名经验丰富的设计师,你一定会认同一点,受他人启发并不是在抄袭UI设计。这是一种最佳的研究实践。它也要运用各种设计模式,也要遵循设计规范,也需要确保选择用户熟悉的模式来建立可用的界面。

    2017-06-01