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

前言

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

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

因此我想从git工做区划分开始，解释一下平时经常使用的一些git命令的真正含义，不过并不会太过深刻的解释git的一些偏门内容。但愿看过这篇文章的朋友能对git自己有必定的认识，知道用不一样的命令时，git产生了哪些改变，作到使用命令时内心有数，更好的利用好git这个优秀的工具。

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

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

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

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>

如图所示：

文章连接

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

理解git结构与简单操做（二）工做区与暂存区

理解git结构与简单操做（三）认识版本库与分支

理解git结构与简单操做（四）合并分支的方法与策略