理解git结构与简单操作(一)git的本质

前言

git已经是一个非常普及且常用的代码管理工具,算是程序员标配之一。但近期面试了大约几十个3-5年前端工程师外加实习生,发现大多数的git水平都停留在add、commit、push、pull这个最简单的流程,只会用GUI,甚至一点都没接触过的也大有人在。

重要的是,基本没有人知道为什么要这么做

所以我想从git工作区划分开始,解释一下平时常用的一些git命令的真正含义,不过并不会太过深入的解释git的一些偏门内容。希望看过这篇文章的朋友能对git本身有一定的认识,知道用不同的命令时,git产生了哪些改变,做到使用命令时心里有数,更好的利用好git这个优秀的工具。

本文不是给纯萌新看的教程。阅读本文需要知道git是什么东西,以及一点简单的命令使用。萌新请看这里:廖雪峰大大的git教程

本文会把相对于git各个区域或者操作涉及到的git命令总结在段尾,可以结合段中内容回想涉及到的命令在这里完成了什么作用,最后再综合思考命令的作用。

个人才疏学浅,文笔粗陋,如文中有知识、文笔错误,或者有什么可以改进的地方,请随时提issue,或发E-mail(szp93@126.com)给我,感谢感谢。

git是用来管理修改的

当我们对一个项目进行修改后,需要对改动进行add、commit来把改动合并到本地分支,然后执行push来将这次的commit推送到分支关联的远程服务器的分支,这其实就是最简单的git工作流程,这样就可以把本地修改的代码上传到服务器了。

那么,git的作用就仅仅是将本地的代码放到服务器上吗?显然不是,要不git就仅仅是一个网盘了。

git与网盘的不同点之一在于:git管理的是文件的修改,是过程量,就像是物理中的加速度。

当你在本地修改文件之后,执行git status就会看到一片红色的文件名:

如上图,有三个文件的名字是红的,分成了两个部分:

  1. Changes not staged for commit
  2. Untracked files

第一部分,这句话的主语是Changes,也就是说,这一段是还没有被staged,以用来提交的修改。关于staged的含义,先理解成「保存」,之后会详细解释。

第二个是没有被跟踪的文件

从此我们可以看出,git对于文件是这样处理的:对于新文件,提交过一次之后,git就会跟踪这个文件。每当文件内容进行修改,git就会按行分析出这个文件修改了哪些行。对于这些修改,用git diff <filename>就可以查看到:

对于程序员来说,写代码的量上来之后,或者你修改的文件多了以后,可能就会出现忘掉修改了哪些内容之类的问题。git就会帮我们跟踪这些文件,把你的修改以简单明了的方式展现出来。对于我这么个前端来说,diff让我减少了一大堆语法错误(逃。

把git抽象成几个区域

我们已经知道git管理的是文件的修改了,那么有关于这些修改的提交都是一些什么过程呢?

git将我们的工作流程抽象成了几个区域,总结一下就是:

  • 工作区(就是你的磁盘,你的文件)
  • 暂存区(刚才提到的stage)
  • 版本库(分支)
  • 远程代码库(远程分支)

如图所示:

好,就根据此图,归结一下我们一次工作并提交代码的过程吧:

  1. 写代码(修改工作区)
  2. 把修改加入到暂存区:git add <filepath>
  3. 把暂存区的修改提交到版本库中:git commit
  4. 此时本地版本库就跟远程仓库状态不同了,把本地库推送到远程仓库保持同步:git push <origin> <branch>

如图所示:



评论

暂无评论

在这里输入