优雅的管理你的文稿

序言

在我没做码农前，经常需要写各种论文，报表之类的文稿。有一个非常苦恼的困扰就是，写完了一个版本后，要在这版本基础上改动，就复制一份，时间长了以后电脑上各种 1.0、2.0、3.0…一团遭，为了保持整洁就删除了一些认为以后用不到的，结果后面突然要用，这种痛我想很多人都有。还有跟别人一起写文稿的时候，明明是他写的，后来甩锅给我，那种委屈简直了。

疯狂 cv

做了码农后，我发现有很多工具，即使你不写代码，熟练使用后，也会大大改善你的工作效率～，今天教大家如何优雅的管理你的文稿。

目标

如果你认真的看完了本篇文章，我希望能帮你在管理文稿的过程中达到以下几个目标：

永远告别复制粘贴产生的一堆 x.x 及备份文件。
不管你写了多少个版本，让你一秒切换到任意版本。
精确比较每一个版本间的不同。
多人合作，再也不怕别人甩锅。
（如果需要）远程备份，再也不怕电脑突然跪了。

工具

无论你是使用 windows 还是 Mac ，都需要用到这个工具 — Git。

因为本篇文章主要目的是管理文稿，所以只会介绍相关的 Git 使用，如果你对 Git 很感兴趣可以自行搜索。

Git 配置

Git 是 Linux 之父 Linus Torvalds 一怒之下撸出来的一个代码版本管理工具，Git 是基于命令行进行操作，当然也有很多的开源工具，实现了对 Git 进行图形化操作，也就是大家常见的各种软件，只需要鼠标点就好了。

但是在这里我会先教大家使用命令行，这样能比较快速的熟悉 Git 的相关命令，并且图形化一般只有一些常用命令，所以掌握一些命令是有必要的。（命令行会显得你逼格比较高～）

扯远了，先来配置好 Git～

1.Mac 先到官网下载 Git ，Windows 点我。

2.下载完成后安装～这一步应该没有什么问题，那么怎么判断你是否安装成功呢？

如果是 Mac ，在 Launchpad —> 其他 —> 终端，打开终端～你会看到下图这个窗口。（当然你的可能是白色的）

Mac 终端

然后输入下面的命令git version然后回车，查看 Git 的版本，如图：

git version

输出版本号说明安装成功

Windows 的话在菜单—>Git—>GitBash ，点开，弹出一个命令行窗口（cmd) ，类似于下图：

就说明安装成功了。

git bash

3.如何使用 Git？在 Mac 环境下打开终端就可以开始输入 Git 命令了，在 Windows 下除了点菜单，在某个文件夹下点击右键也可以找到 Git Bash，打开就可以。

到这里 Git 就配置完成了，如果你发现还是没办法正常使用 Git 的话，可以看看这个教程。

现在开始，我们从新建一篇论文开始，为了方便，就新建 txt 文件作为我们的文稿测试。

新建论文

前文我们提到了，Git 可以帮助你不被别人甩锅，所以每次的改动应该知道是谁来做的，那么我们需要先配置你的名称，打开命令行窗口，Mac 是终端，Windows 是 Git Bash ，大家记住，后面不会再提了～

输入以下命令，输完一行就回车，再输入下一行：

git config --global user.name "Your Name"
git config --global user.email "[email protected]"

这两句命令的意思就是为这个电脑的版本管理配置了修改人的姓名和邮箱，这样每次修改就明确知道是谁修改的。

废话不多说，我们先建一个文件夹：Demo，然后在这个文件夹下新建一个 txt 文件假装是我们的论文（对，假装，你非要用 word 也可以～）

新建论文文件夹

注意了，现在文件夹有了，论文也有了，怎么用 Git 来管理呢？首先要将这个文件夹变成一个 Git 仓库，说仓库可能有点难理解，但是大家想想仓库，进货出货等等都会登记对吧？咱们就要吧咱们的论文文件夹变成一个严格管理的仓库。

Mac 的同学打开终端，cd 到这个文件夹下：

cd xxx/xxx/Demo

注意，这个 xxx/xxx/Demo 是这个文件夹的路径，可以通过右键查看。cd 到这个文件夹下就相当于在命令行中进入到了这个窗口下

cd 到文件夹下

Windows 的同学可以直接在 Demo 文件夹下面右键打开 Git Bash ，就默认进入到该文件夹下啦

初始化仓库

现在已经到这个文件夹下了，我们先来看一下这个文件夹的状态：

git status

查看 Git 仓库的状态，不出意外你会发现报错了

git 仓库不存在

意思是这不是一个 Git 仓库，那么我们来把它变成一个仓库：

git init

初始化仓库

这句命令是初始化一个仓库，init 是 Initialized 的缩写，初始化后我们再来查看一下仓库的状态：

git status

初始化仓库状态

看到了么，我们的仓库已经创建成功了，并且刚刚我们创建的这个论文也出现在了命令行中，并且是红色的～，咱们先不去管是什么意思，来写我们的论文

给论文加点东西

咱们打开论文，写点东西：

第一次修改论文

好啦～简单的完成了第一次修改，我们需要保存这一次修改，还是先来查看下仓库的状态：

git status

记住这个命令，你会经常用到的～

第一次修改后的状态

发现跟刚刚初始化的时候的状态一样，好了，我们要来记录这一次修改了，首先将要修改的文件加入到本次纪录中：

git add xxx

xxx 是被修改的文件，这里就是我们的初版.txt，注意是相对路径（相对这个文件夹的）,比如说这个文件夹下面还有一个文件夹 test，test 下面有个文件 xxx，那么 xxx 就应该是 test/xxx。

add 修改文件

add 之后好像什么都没发生哈，再来查看下 status：

add 后状态

喏～变绿了有没有，而且有一行字提示你有修改等着被提交，那么我们就来提交吧：

git commit -m '这里是本次修改的描述信息'

commit 修改

ok~提示我们完成了提交，并且提交的内容是什么也显示了出来。

查看修改

我们提交了第一次修改，那么在哪里查看呢？用下面这个命令：

git log

这个命令会以流水线的形式来展示我们的每一次修改

git log

注意一下，这里f移动查看log 是 h j k l ，而不是方向键，如果要退出查看 log 按一下 q （quit）

好，我们简单的来总结下上面这几步

首先是初始化仓库，这个仓库必须是一个文件夹（只需要初始化一次）
然后修改你的论文，把本次修改 add 进这一次的提交内容中
最后确定没问题，提交这次修改纪录
查看这次修改的日志

用到的命令有

git init //初始化
git status //查看状态
git add xxx //添加某个文件
git commit -m 'xxx' // 提交这次纪录
git log // 查看日志

好了～，说到这里，是不是感觉干了好多并不明白的事情？貌似并没有什么卵用啊？？？别着急，进入下一步

修改论文

上面我们只是刚刚新建了一篇论文，简单的写了个开头而已，现在我们要真正的去写我们的出版了，打开初版，疯狂的输出～

修改正文

ok~正文写完了。。。虽然我这里写的很少，但是假装我们写的很多～我们来查看下仓库的状态

修改正文后的状态

看到没～又变红了，我们先不急着像上面一样提交修改，假如我们现在想看看我们到底修改了写什么，跟我们修改前的文件对比一下呢？

git diff

diff 是 different 的缩写

diff

－号代表了修改前的文件，＋号代表了修改后的文件～

好了我们确定了本次修改就提交吧～步骤同上，不再重复，看大家能自己学会提交么，提交完后我们看下 log 日志

注意下命令行中用到的符号都必须是英文符号噢

添加正文后的log

在不同版本间切换

前面的一切都在为后面的操作铺路～上面的功能好像除了纪录下每次的修改并没有其他的卵用啊，假设现在我们有个需求，是要看最开始创建的那个版本，也就是只写了一行字的那个，怎么办？下面教一个流弊的命令

git checkout xxx

xxx 具体是什么呢？先不提，因为 checkout 有很多种用法，还记得前面讲 git log 的那张图里面，每一个纪录都有一个独一无二的 id 么？

两次修改的日志

找到第一次提交的纪录的 id，复制下来，将 xxx 换成这个 id

chekout 第一次提交

再打开我们的初版.txt 看看

是不是又回到第一次提交时的样子啦？来看下仓库的状态：

checkout 后的状态

有没有看到一行红字，HEAD detached at 3d6fe3c，后面的那个乱码其实是这个纪录的 id 的前几位，不信你去看 log，HEAD 就像是一个指针，这个指针指到哪儿，文件就变成那个时候的样子，怎么样，是不是很流弊？这时候你再查看 log 会发现第二次的提交不见了，不要惊慌，因为在当前的这个提交上面还没有第二个提交纪录呢

那么怎么切换回第二次，也就是最新的那个版本呢？

这里就要引入一个分支的概念了

git branch

输入这个命令查看当前仓库中的分支

分支查看

绿色的，前面有＊号的，就是我们当前所在的分支，另外我们还看到还有一个 master 分支，在没有进行分支指定的情况下是默认在 master 分支上，可以把这个分支看成是主分支，而我们目前所在的这个分支只是一个临时分支，供我们切换到某个版本上面而不影响主分支上的内容，那么现在就让我们切换到主分支上：

git checkout master

然后再查看我们的 log ，发现第二次提交的纪录也回来了，打开初版可以看到恢复到最新的版本了。

这时候再来查看下分支

git branch

会发现我们已经到 master 分支上面了，并且之前的那个临时分支已经不见了～

分支开发

前面引入了一个分支的概念，现在要好好讲讲分支的作用，这是 Git 比较精华的部分。先举个在程序开发中的例子

通常在程序开发中会有三个主要的分支，分别是 master ，develop，test，从字面理解就是主分支，开发分支，和测试分支。什么意思呢？

举个例子，假设我们有个 app 在应用市场的版本是 1.0.0 ，现在我们要开发 1.1.0，怎么做呢？从 master 分支切出一个 develop 分支，在 develop 分支上面去开发 1.1.0 的功能，为什么呢？你想，如果我们直接在 1.0.0 的代码上去开发，如果线上版本有一个重大 bug ，需要紧急修复，而 1.1.0 的功能又只开发了一半，这时候就很尴尬了，可是如果我们在单独的分支上开发 1.1.0，这时候就可以很轻松的在 master 分支上修改bug 重新发一个新的 1.0.0 版本，再接着在 develop 分支上开发 1.1.0，互相不干扰～

同样，我们在写论文的时候可能也有这个需求，比如你现在已经写了一个能看的版本了（给老师，老板检查之类的），但是你又想再加一点新的东西进去，可是又不希望被老师／老板突然抽查发现你还有的没写完，这样就不完美了。

利用上面的思路，我们也可以在 master 上是你能看的版本，再切一个单独的分支来加新的东西，这样即便被突然检查也可以很轻松的切换到 master 上面给老师看一个完成版～

所以我们先要明确两个分支的任务