一个故事读懂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 命令让论文报告本和草稿本上的内容与指定的版本一致,即让暂存区和工作区与指定版本库一致。


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

                                                                  

猜你喜欢

转载自blog.csdn.net/zxm342698145/article/details/81297528
今日推荐