一个故事读懂git基本工作方式

快毕业了，张小明要完成毕业论文，限期3个月完成。负责论文的李老师会定期要学生上交论文，抽查论文完成的情况。而且还规定要保留原稿，以证明论文不是抄袭的。

由于论文篇幅很长，内容繁杂，而且那时候还没有计算机，不能写电子文档，修修改改是避免不了的，所以张小明自己想了一个法子，来对付论文。

张小明每次写一段论文时，都先在草稿本上写，哪怕修修改改写的很乱也没有关系，因为只有他一个人看得到。在草稿本上修改完成之后，就誊写到正式的论文报告本上。

如果誊写到论文报告本上发现也还有错误，需要修改，那么就得删掉有错误的那一页，在草稿本上修改之后再重新誊写到论文报告本上。

情景1

一天上午张小明在草稿本上写了一段文字并誊写到了论文报告本上，下午准备接着在草稿本上写。可是那天状态不好，写出的东西不满意，越看越乱，一怒之下，张小明把草稿本撕了。由于需要保留草稿，张小明只好新买了一个草稿本，并将论文报告本上的内容复印到新的草稿文档上。

情景2

静下心来之后终于在草稿本上写了一段论文，然后就誊写到论文报告本上了。但再读之后却发现了很多错误。此时论文报告本和草稿本上都是有错误的论文，根本不知道如何回到上次修改的地方了，只好找李老师要回了上次提交的版本，并复印到论文报告本上。注意此时草稿本上的内容并没有删掉。

一个星期后，李老师要求检查论文报告。张小明只写了一点，心想，MMP，这可怎么拿得出手哦，顺手在草稿文档上写下了‘MMP李老师’。李老师催的急，无奈张小明只好将论文报告复制一份，交给了李老师，并在日志中记录如下：第一次提交给李老师论文报告。不过草稿上的那一句MMP，李老师是看不到的，哈哈。

发泄归发泄，论文上交之后还得继续写。张小明删掉了那句MMP，此时草稿本上的论文和论文报告本上的论文完全一致了，即是干净的。

李老师收到张小明的论文报告本之后，也写下日志：张小明第一次提交的论文ver 0.1。此后每一个星期，张小明都会提交一个版本给李老师检查，李老师已经保存了5个版本。每次收到论文，李老师都会写下日志，并把最新的论文报告本放在最上面，并把它叫HEAD。

情景3

有一次李老师因论文格式问题批评了张小明，张小明恨恨的在草稿本上画了一只乌龟。碰巧那天李老师又要检查论文，张小明同学聚会喝了点酒，想也没想照着草稿把乌龟也画在论文报告本上，然后上交了。

李老师再次收到张小明的论文报告本后，继续写下日志：张小明第6次提交的论文ver 0.6，并把这个最新的版本放在最上面。当李老师打开论文报告本，看见论文最后画了一只乌龟后气坏了，立马通知张小明重新交一个版本上来。

学校系领导规定学生每次上交的论文报告版本也要存档，以便抽查。李老师也很无奈，这么不雅的论文是不能放在台面上的，只好把上次的论文报告本放在了最上面，并告知张小明，李老师要交给系领导抽查的论文报告版本为上次的ver 0.5，这次提交的版本已弃置不用。

由于张小明的论文报告本和草稿本已经画了乌龟，而且他并不知道李老师所说的ver 0.5版本是哪个样子的了，他只好找李老师复印了两份ver 0.5版本的论文，作为新的论文报告和草稿。如果此前提交第6次论文报告后，又在草稿或论文报告本上写了新的东西，那么新的内容就丢失了。

再回到我们使用git时的情景，是不是和上面的故事有点类似呢。有点git基础的同学都知道git也有  两个区，工作区，暂存区，以及主分支master和指向master的指针HEAD，正好对应故事中的草稿本，论文报告本，和老师的版本库。

我们在git版本控制下写代码时，相当于往草稿本上写代码。git add file命令就是把草稿文档誊写到正式的论文报告本上。git commit命令相当于提交给老师。

情景一，就是利用git checkout -- file命令把草稿本上新写的内容擦掉，即让工作区的代码和暂存区或最新版本库的一致。

情景二，就是利用git reset HEAD file命令把论文报告本上新写的内容擦掉，即让暂存区和最新版本库一致，此时草稿本或工作区内容不会被擦除。

情景三，就是利用git reset -- hard verid 命令让论文报告本和草稿本上的内容与指定的版本一致，即让暂存区和工作区与指定版本库一致。

---

喜欢本文的朋友们，欢迎长按下图关注订阅白话互联网技术，收看更多精彩内容