理解git结构与简单操作（一）git的本质

前言

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

重要的是，就算是知道要做什么，也没有人知道为什么要这么做。

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

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

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

个人才疏学浅，文笔粗陋，如文中有知识、文笔错误，或者有什么可以改进的地方，请评论给我，感谢感谢。

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

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

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

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

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

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

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

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

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

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

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

如图所示：

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

如图所示：