對每一個設計師來說，如何管理文件版本是令人很頭痛的。本次教程使用Sketch的git插件幫助你記錄每一次的更改、處理好混亂的版本迭代
設計師的版本控制-Sketch的git插件使用案例
最近自己一直在進行UI設計的學習，主要使用的軟件是Sketch，很多時候在參考前輩們的意見后會進行多個版本的更改和嘗試，因此不僅會出現多個版本的.sketch文件同時也會導出很多不同版本的預覽圖，這就導致后期整理的時候其實比較雜亂，有這么幾個問題
-
他人的評價很難和對應版本的文件整合起來（光塞入sketch文件里在跨版本選擇的時候就需要打開每個文件比較麻煩）
-
同時保存多個版本的.sketch文件其實也是相對來說占空間的。
雖然Sketch其實已經有內建的不錯的版本控制，但在是用上來說也只能個人獨立使用，會缺乏團隊協作性。
因此綜上就決定開始嘗試使用Git來進行設計文件的版本控制，因為專業的一半是寫代碼（c++，c#之類）所以對git會比較熟悉，可以進行簡單的純命令行的進行版本控制，但可能對于很多設計師來說還是相對容易出錯的，因此需要圖形化的插件幫助，為此我專門去尋找了適用于sketch的git插件。最終效果如下
1.什么是git
Git是目前世界上最先進的分布式版本控制系統（沒有之一）。
Git是一個開源的分布式版本控制系統，用以有效、高速的處理從很小到非常大的項目版本管理。Git 是 Linus Torvalds 為了幫助管理 Linux 內核開發而開發的一個開放源碼的版本控制軟件。
2.git托管服務的選擇
git的版本控制可以在本地進行，但是推送到遠程服務器（局域網內建也可）之后其實有更優化的版本視覺對比。現有的主要的git托管庫有兩個一個是github，一個是gitlab，國內的gitcoffee也不錯。
github免費版本和學生版本都有一定的私人項目上限，需要付費才可以開更多的項目。同時因為服務器位于國外的原因，很有可能有鏈接不穩定的情況。gitcoffee用的不多。
本次范例使用的git托管服務是前不久在自己寢室的服務器上建立的gitlab的community版本。如果是團隊協作可以在內網中架設github服務器，既可以確保安全性也可以方便團隊成員使用。（不大確定在真的商用公司是如何進行版本控制的，本文僅供各位參考，數據安全關系如需要架設自己的服務器一定要注意容災，增加備份）
3.Sketch git插件的選擇
本次使用的是一款名為git-sketch-plugin的插件，由開發者mathieudutour開發，是眾多現有的git插件中持續維護情況最好功能最完善的，項目在github開源，各位可以持續關注
4.其他的技術準備
真的不要嫌麻煩喲，真的安裝完之后會特別好用！
1.Sketch >3.1 (非Mac App Store下載的版本，沒有沙盒機制）
2.將Sketchtool安裝在 /usr/local/bin/sketchtool
下載好最新的Sketch之后進入Finder-應用程序，找到Sketch之后右鍵查看包內容
進入Content-Resources-sketchtool，找到install.sh
啟動系統自帶的terminal（終端），將install.sh拖入即可執行安裝程序
如圖所示即安裝成功
3.安裝git（參考git的官網教程《1.4 起步 - 安裝 Git》 ）
4.一個git托管服務（并將本機的ssh密鑰綁定方便擁有對gitlab服務器的訪問權）本次使用gitlab，github的使用可以參考這篇鏈接。
安裝：下載git-sketch-plugin-master.zip
解壓縮后點擊Git.sketchplugin進行安裝
安裝成功后的提醒
當這些都完成后可以開始啦！
5.案例分享
-
于gitlab的網頁版本建立一個項目project
項目可以參照這個參數進行配置，可以設置項目為私人項目，也可以設置為public或者internal（本gitlab服務的用戶可以訪問）
建立后使用git命令`clone`到本地Mac中（通常我自己的路徑就在自己的文件夾中）
通常直接拷貝`Create a new repository`下的幾行命令進行項目文件夾的創建以及git項目的初始化
在Mac系統下，可以使用系統自帶的terminal進行git的管理，非常方便。
直接復制上方的git命令拷貝入terminal
git clone ssh://git@cloud.yuanchenhao.com:30001/>stevenyuan/sketchGit.gitcd sketchGittouch README.mdgit add README.mdgit commit -m "add README"git push -u origin master
處理一段時間后會出現如圖情況，按回車后進行本地的master（主分支）和 remote的master主分支的合并
git push -u origin master
執行到如圖這樣就代表本地文件夾和remote文件夾已經聯系上了，打開文件夾可以看到一個README.md的項目描述文件，該文件是用于描述項目用，暫時可以不用管它。
準備工作還差最后一步---建立你的sketch文件。這里為了方便演示，就用我之前在進行UI練習時進行到一半的稿件來演示。當然也可以直接將sketch文件復制到已經建立的git文件夾或者將sketch文件復制到該文件夾
打開該sketch文件，這個時候這個文件還是屬于無編制狀態，git系統是沒法管理到它的改變的，這個時候我們的主角Git插件就可以登場啦，菜單欄-Plugins-Git-Add File to git
此時sketch下方會出現"File added to git"就表示這個文件被追蹤啦。
現在我們進行第一次改動，試著改動artboard“新聞首頁”的標簽位置和字體:將標簽移到了作者信息行末尾，將新聞標題的Lato-Light字體更改為Helvetica-Regular，不用手動按保存，sketch會自動保存。
好了這是根據最新的設計潮流更改的，你決定保存一次，這個時候就要用到commit命令：Plugins-Git-Commit
Sketch會彈出如圖所示的對話框，commit to “master”，輸入框里可以填寫你對這次更改的描述，比如：客戶需求1：更換字體為Helvetica，更換標簽位置。一定要勾選“Generate files for pretty diffs”
這個生成diff差異文件可以說是這個插件和單純用命令行最大的差別了：單純的命令行操作git需要你每次自己在teminal里輸入比如 git commit -m"客戶需求1：更換字體為Helvetica，更換標簽位置。"這樣的命令，同時也需要你自己去導出示意圖，非常麻煩，而這個commit命令可以很快完成這兩步。
commit 完成后就會出現下方這樣的commit成功說明，如果有時候無法彈出就再次commit一次（一般不會出現，靜候就好）。
有時候也會出現：no commit to submit意思的字樣是sketch未來得及保存你的更改你就提交了commit，重新手動保存一下然后再commit就好。
現在的commit完成就相當于生成了一個階段性的存檔，已經可以在本地使用git回溯版本或者查看,不過為了團隊協作、以及用上gitlab（或者github）系統的簡潔的GUI操作界面進行對比我們需要將改動推送到遠程服務器。
使用插件的push命令Plugins-Git-Push
然后sketch會卡頓一會兒，鼠標會變成風火輪旋轉一會兒，具體時間視sketch文件的大小而定，文件越大持續的時間越長，此時就不要再進行其他操作了，如果sketch崩潰可能就要回到命令行去控制版本了。
不過有時候可能會跳出Failed..窗口，不用擔心，其實commit已經提交到遠程的master分支啦。后文會介紹解決這個問題。
接下來訪問網頁版gitlab查看現在項目的進度。
在這里就可以看到現有的項目的commit了，每個artboard都有單獨的跟蹤，因此無論你修改了哪個arboard都可以看到版本更新，因為啥第一次commit因此沒有對比照，我們再進行一次提交來使用對比功能。（步驟同上面完全相同）
在本次修改中我刪除了背景的遮罩、更改了標簽顏色、添加了頁面的分享功能，在commits界面可以看到新的一次提交：客戶需求2
打開本次commit之后就可以看到版本2：客戶需求2 和客戶需求1之前的對比了，在右上角的模式中，請選擇SIDE-BY-SIDE，方便對比。
在對比模式中，gitlab同github一樣提供了三種模式：2-up（左右對比），Swipe（從左至右拖動對比）以及onion Skin（剝洋蔥模式）
Swipe模式如圖所示，便于對比版本前后的差異，如下圖就可以看到現在對比線左右標簽的顏色差異、缺失遮罩的畫面不同，再往右拖動就可以看到分享菜單的有無對比。
onion skin模式就是從右往左的拖動，動態的進行對比，在之前的使用過程中覺得尤其對明暗的對比特別的有用。
上面的范例已經簡要說明了兩次版本提交以及對比的使用方法，基本上覆蓋了本次使用的git插件的主要功能。如果個人單獨使用，可以在每一步寫上你從其他人（比如主管、前輩、用戶）那邊得到的反饋或者參考的項目鏈接，可以做到每一步改動都有理論的支撐而不是隨意的更改。如果是團隊使用那么git的功能就更方便的發揮了，可以將團隊中每一個人都添加到群組中，對更改發出各自的意見建議。
6.其他
branch功能和其他稍微高級一點的git指令就暫時就不講啦，之后有時間再更新，不過branch和master分支的切換對于團隊開發或者自己進行多次不同風格的嘗試的話會非常有用，可以獨立進行多個分支的設計、通過自己或者團隊審核通過后合并到master主分支形成最終的版本。
其他更加高階的操作可以參照git的標準操作流程來使用 ，兩者其實理念上是一樣的
兩者的差異可以參考 阮一峰前輩的這篇對比文《 Git 工作流程》
