设计师如何管理自己的文档（设计师如何管理自己的文档内容）

随着项目的积累，我们的文件目录会变得十分的盘大，如果不好好管理，将会变得一团糟，有时会影响到我们工作的效率与心情，好的文档管理方式会在一定程度上让我们的工作更加有序，即时文件目录再多，按照已经制定好的规则，也能够快速的查询到目标文件。这次就我个人研究对比，做一次小的分享，希望能对大家有所帮助。

三种有效管理文档的方法：

1. 文件夹/文件规范命名
2. 文档版本控制
3. 云盘同步备份

通过以上三种方式的配合使用，能有效的帮助我们实现以下目标：

• 通过规范命名：对项目文件/个人文档进行分类，方便查找
• 文档版本控制：减少自己对文档的复制备份，自动构建关键历史版本，即使误删也能找回，按需 求还原到某一个历史节点的文档状态
• 云盘同步备份：对十分重要的文档进行同步备份，有修改则会马上实时备份

我们已经知道了这三种方法，又应该如何去落实实现呢？

方法一：文件夹/文档规范命名

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/

2. 登录Gitkraken后，点击文件夹图标，选择link关联本地项目库即可

3. 如果需要关联远程仓库，例如关联Github，则需点击remote填写远程的url即可

GitHub项目里找到如下图的ssh，复制到上面的push URL中：

使用git管理的文件在本地会有下面三个过程：

1. 已修改(modified)：就是你修改了在git管理下的文件
2. 已暂存(staged)：就是将你修改的文件放在缓存区中，等待处理
3. 已提交(committed)：就是在你的本地确定了你这次保存在缓冲区中的文件与上一次committed的文件一起，为一个版本，这里先不要考虑远程的情况，到此为止，本地能完成的事情已经完成了。

而Gitkraken的布局十分简单，很方便我们理解在它的管理下，我们文档产生数据的进程。

当我们队项目文件夹进行任何的操作：添加新文件、更改文件数据、移动文件位置在临时仓都会记录下我们的操作记录，此时你如果有想要反悔的操作通过ctrl z无法实现，可以在临时仓进行查看，进行复原；当我们的修改进行到一定阶段，你觉得有必要进行一次记录，此时点击stage all change，将此前所有的修改记录进行提交，这时你还是有时间进行检查的，看看有哪些遗漏，确定无误，进行记录的命名与描述，点击提交将会将记录提交到本地仓库;如果你关联了远程仓库GitHub，可以将此次修改push到远程仓库进行备份。

我们在使用ps的时候进行到一定阶段也会另存一个版本，你会问这样有什么意义？

意义在于ps软件的另存只是将你对ps这一个文件的操作进行了备份，要知道我们在项目中，往往变化的不只是设计，还有与设计对接的需求、文档、参考文件，这些统统在项目库中，而gitkraken可以对整个项目库进行记录，即将当前所有与项目相关的文件进行记录，这一版的修改才是完整的修改记录，而不是单个ps文件。

在提交的存档记录中，如果有一天你误删了项目中的文件，可以找到对应的记录（为什么要进行记录命名就是为了方便查找）右键reset到这个版本。

通过undo与redo来取消你的操作或重做此操作：

方法三：同步盘使用

此方式方便对经常修改的文件进行实时备份

可使用的工具如下：

• 百度云：百度云盘同步，快速简便，有100个历史版本记录，缺点就是必须是会员
• 坚果云：免费1g上传流量，3g下载流量，要想更多需收费
• 群晖私有云：通过安装Drive应用，配置同步盘，在局域网内速度很快，前提是你要购置群晖私有云

建议无需将项目所有文件进行同步，可以创建一个文档资料库，同样的按照规范文档步奏命名好文件名，将通用的一些文档资料，素材资源放置

本人使用的是群晖私有云，配置安装了Drive，界面简洁，相当于一个简洁版的百度云盘了，且有历史版本记录，可以返回历史版本。

总结

在项目中，我们总是被很多其他的小意外打乱步伐，在实践中我们要总结方法，加以利用，既能保证我们项目文档的安全性、可用性、整洁性，又能大大减少这些小意外导致的时间损耗，让我们更加专注于项目本身和设计这件事上。一个优秀的设计师，不仅仅要做好的设计，也要善于管理自己的文件。通过以上介绍的三种方法的使用，相信大家有了一个初步认识，再通过后期项目中的实践，相信会对大家在文档整理效率上有所帮助。能够帮助我们提高效率的工具有很多，在实践中运用起来才能发挥他们的真正作用。

谢谢各位的阅读，本次分享就到这里结束！

相关文档：

本文由 @时光若刻 原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自 Unsplash，基于 CC0 协议