起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識設計師如何管理自己的文檔
隨著項目的積累，我們的文件目錄會變得十分的盤大，如果不好好管理，將會變得一團糟，有時會影響到我們工作的效率與心情，好的文檔管理方式會在一定程度上讓我們的工作更加有序，即時文件目錄再多，按照已經制定好的規則，也能夠快速的查詢到目標文件。這次就我個人研究對比，做一次小的分享，希望能對大家有所幫助。
三種有效管理文檔的方法：
- 文件夾/文件規范命名
- 文檔版本控制
- 云盤同步備份
通過以上三種方式的配合使用，能有效的幫助我們實現以下目標：
- 通過規范命名：對項目文件/個人文檔進行分類，方便查找
- 文檔版本控制：減少自己對文檔的復制備份，自動構建關鍵歷史版本，即使誤刪也能找回，按需 ? ? ? ? 求還原到某一個歷史節點的文檔狀態
- 云盤同步備份：對十分重要的文檔進行同步備份，有修改則會馬上實時備份
我們已經知道了這三種方法，又應該如何去落實實現呢？
方法一：文件夾/文檔規范命名
1. 首先先制定一下我們命名的一些規則
我們常見的版本命名格式為?[name].x.y.z-[state]
- name為可選字段,一般為?v,表示 version
- x.y.z?為各版本的序號，遵循語義化版本命名規范。?實際上基于此規范,不應該在版本前出現 name ? ? ? 字段
- state?可選字段,表示版本狀態,例如?b?表示 beta 測試版,其他常見狀態,后有詳述
什么是語義化版本命名規則？
核心規則如下：
- 0.y.z?表示開發階段，一切可能隨時改變，非穩定版。
- 1.0.0?界定此版本為初始穩定版，后面的一切更新都基于此版本進行修改。
版本狀態如下：
2. 了解命名規則后，我們就可以對我們工作站常用的文件夾/文檔進行合理命名
對正在進行的項目：做好項目分類，區分文件夾，歸類不同項目文件
- 外層文件夾名：iwork或項目project
- 一級文件夾名： 日期_項目名??例：2018_0115_項目名
- 二級文件夾名：version_1.0（對重要改變進行此二級）
- 三級文件夾名：按照工作內容所需進行排布
對已經完結的項目：及時整理命名好，放入Archive存檔庫
命名：項目名（項目編號）_版本_開始結束時間
例：蝸牛APP項目_V1.0.1_2018/01/25-03/15
蝸牛APP項目_V1.0.1_2018_01250315
如下圖所示，將各個層級的文件夾命名展示出來了，對應項目是否有相應版本，有的話命名可加上對應版本號
方法二：對文檔進行版本管理
如圖所示，我們在進行版本更迭的時候，文檔的升級維護比較簡單易行，通過不同文件夾進行版本升級管理。而要想回到歷史版本則困難許多。
而現實中，設計的工作經常進行改稿，常常會出現這種情況，當你改到第7第8稿時，客戶來一句還是第3稿合適，然而我們往往對文件的命名是這樣的是不是很抓狂
如果對每一份改動，都采取另存一份的方式，我們的項目庫會變的十分的臃腫龐大，不方便我們對數據的管理。除此之外，實際中，我們常常會進行一些小修改，忘記保存一份新的備份，這時我們想要文件回到過去式，就真的不是那么容易了。
同樣的，我們在工作中有些文檔是需要多人協作的，傳統的本地文檔已經無法讓團隊高效的完成這一事務，涌現出了很多新型的文檔編輯平臺，方便團隊協作制作文檔，并且支持導出本地格式文件。如QQ的在線文檔功能、石墨文檔、印象筆記團隊版，都是可以配置相應的權限，支持多人在線對同一文件進行編輯查看。具備操作歷史查看，可以將文檔還原到具體對應的狀態。
而我們正是需要如同在線文檔一樣的方式來管理我們工作時產生的諸多設計文件，有了這樣的版本控制，我們不需要擔心正在處理的文檔會被覆蓋，我們唯一要專注的就是手頭的文件，進行保存。
如何達到這樣的目的？我們可以采取的方式有：Git和SVN
簡單介紹SVN
基本概念：SVN 的工作依賴于一個「遠程庫」或者稱呼為「數據中心」。我們可以在本地搭建這個數據中心。接著，在從數據中心 Check out 文件，我們稱呼為「本地數據」，我們把本地數據修改好了，再用「命令」commit 一下給「數據中心」。這樣，數據中心就會把我們的修改記錄在案，并把以前的舊數據做備份。總結一下，就是推陳出新，完成修改產生一個新數據，舊數據自動生成備份
簡單介紹Git
Git對待數據的方式和SVN是不同的，?SVN以文件變更列表的方式存儲信息。 將保存的信息看作是一組基本文件和每個文件隨時間逐步累積的差異。存儲每個文件與初始版本的差異，如下圖所示：
Git 不按照以上方式對待或保存數據。 反之，Git 更像是把數據看作是對小型文件系統的一組快照。 每次你提交更新，或在 Git 中保存項目狀態時，它主要對當時的全部文件制作一個快照并保存這個快照的索引。 為了高效，如果文件沒有修改，Git 不再重新存儲該文件，而是只保留一個鏈接指向之前存儲的文件。 Git 對待數據更像是一個?快照流。如下圖所示：
對比Git與SVN后，最終我選擇了Git這樣的方式來進行我項目文檔的版本控制：
團隊協作時的流程，可以構建一個本地局域網Git服務器（私密性高），或者采用網絡Git倉庫如Github創建項目倉（空間有限，私密性差）
個人使用時的流程，只需要切斷遠程服務器的連接，即可構建本地的Git項目管理，如果需要云端服務可以使用Github臨時創建項目倉庫，項目完結后可以刪除，節省空間
接下來，介紹下本人如何使用Git來進行文檔的版本管理：
- 適用范圍：個人本地項目管理、兼具網絡Git倉庫（Github.com）
- 使用工具：Gitkraken工具（支持mac/win）、github網絡倉庫（需賬戶注冊）
1. 下載安裝Gitkraken，并注冊github賬號https://github.com/
官網下載地址：https://www.gitkraken.com/
2. 登錄Gitkraken后，點擊文件夾圖標，選擇link關聯本地項目庫即可
3. 如果需要關聯遠程倉庫，例如關聯Github，則需點擊remote填寫遠程的url即可
GitHub項目里找到如下圖的ssh，復制到上面的push URL中：
使用git管理的文件在本地會有下面三個過程：
- 已修改(modified)：就是你修改了在git管理下的文件
- 已暫存(staged)：就是將你修改的文件放在緩存區中，等待處理
- 已提交(committed)：就是在你的本地確定了你這次保存在緩沖區中的文件與上一次committed的文件一起，為一個版本，這里先不要考慮遠程的情況，到此為止，本地能完成的事情已經完成了。
而Gitkraken的布局十分簡單，很方便我們理解在它的管理下，我們文檔產生數據的進程。
當我們隊項目文件夾進行任何的操作：添加新文件、更改文件數據、移動文件位置在臨時倉都會記錄下我們的操作記錄，此時你如果有想要反悔的操作通過ctrl+z無法實現，可以在臨時倉進行查看，進行復原；當我們的修改進行到一定階段，你覺得有必要進行一次記錄，此時點擊stage all change，將此前所有的修改記錄進行提交，這時你還是有時間進行檢查的，看看有哪些遺漏，確定無誤，進行記錄的命名與描述，點擊提交將會將記錄提交到本地倉庫;如果你關聯了遠程倉庫GitHub，可以將此次修改push到遠程倉庫進行備份。
我們在使用ps的時候進行到一定階段也會另存一個版本，你會問這樣有什么意義？
意義在于ps軟件的另存只是將你對ps這一個文件的操作進行了備份，要知道我們在項目中，往往變化的不只是設計，還有與設計對接的需求、文檔、參考文件，這些統統在項目庫中，而gitkraken可以對整個項目庫進行記錄，即將當前所有與項目相關的文件進行記錄，這一版的修改才是完整的修改記錄，而不是單個ps文件。
在提交的存檔記錄中，如果有一天你誤刪了項目中的文件，可以找到對應的記錄（為什么要進行記錄命名就是為了方便查找）右鍵reset到這個版本。
通過undo與redo來取消你的操作或重做此操作：
方法三：同步盤使用
此方式方便對經常修改的文件進行實時備份
可使用的工具如下：
- 百度云：百度云盤同步，快速簡便，有100個歷史版本記錄，缺點就是必須是會員
- 堅果云：免費1g上傳流量，3g下載流量，要想更多需收費
- 群暉私有云：通過安裝Drive應用，配置同步盤，在局域網內速度很快，前提是你要購置群暉私有云
建議無需將項目所有文件進行同步，可以創建一個文檔資料庫，同樣的按照規范文檔步奏命名好文件名，將通用的一些文檔資料，素材資源放置
本人使用的是群暉私有云，配置安裝了Drive，界面簡潔，相當于一個簡潔版的百度云盤了，且有歷史版本記錄，可以返回歷史版本。
總結
在項目中，我們總是被很多其他的小意外打亂步伐，在實踐中我們要總結方法，加以利用，既能保證我們項目文檔的安全性、可用性、整潔性，又能大大減少這些小意外導致的時間損耗，讓我們更加專注于項目本身和設計這件事上。一個優秀的設計師，不僅僅要做好的設計，也要善于管理自己的文件。通過以上介紹的三種方法的使用，相信大家有了一個初步認識，再通過后期項目中的實踐，相信會對大家在文檔整理效率上有所幫助。能夠幫助我們提高效率的工具有很多，在實踐中運用起來才能發揮他們的真正作用。
謝謝各位的閱讀，本次分享就到這里結束！
相關文檔：
https://support.gitkraken.com/release-notes/current Gitkraken幫助文檔
本文由 @時光若刻 原創發布于人人都是產品經理。未經許可，禁止轉載。
題圖來自 Unsplash，基于 CC0 協議
? 時光大神。
好膩害 ??