Git在工作中的常见使用（一）
1.前言
版本控制系统对于每一个开发人员而言肯定不会陌生。其实任何人在工作中都会遇到需要合作或迭代的时候，有个工具管理劳动成果是件很有意义的事。你可以清晰地知道每次工作的内容，每个人的工作划分和进度，甚至可以判断大家工作的积极性等。代码便是开发人员的工作内容，实现的功能以及较之前的改进便是工作成果，而且它还是文件形式，所以一个能管理文件变化的系统就是所需的版本控制系统。目前主流的有SVN和Git，但两者之间的区别和优缺点不是本文的重点。下面来讲一讲如何目的清晰地使用Git的常见功能。
2.结构划分
Git包含两个区域，一个叫工作区，另一个叫版本库。前者就是开发中编写代码的区域，也是被管理的文件存放的区域；后者则是隐藏的.git目录，内部存储了工作区文件每个版本的信息，以及版本间的变化。当用git命令操作时，实际就是对版本库信息的改变，记录工作区内容的变化。
git_log.png
上图是从Android Studio中截取的，里面的每个名词都可以拿出来讲一讲。这是版本控制文集的第一篇，后续的文章将会详细讲解对应的含义及相关操作。先看那三个彩色的内容，HEAD是一个指针，指向当前工作区文件所处的版本，改变它的指向将按照版本库的记录改变工作区的文件。版本管理除了按时间先后迭代外，还可以按功能划分。develop表示本地分支（默认是master，由于是内部开发用而改名），通常按功能划分，是开发的基础，工作区中的文件同样根据当前所在分支发生改变。origin/develop则指的是远程仓库的分支在本地的位置，代码文件托管在服务器上，只有拷贝到本地才能与本地分支进行比较，从而执行更新或合并操作。
3.本地的版本控制
Git最大的特色在于拥有的.git版本库，不是每次提交都得依赖远程仓库。当仅需管理自己提交的代码时，可以在不联网的情况下一直使用。若需要与他人合作，则可以将版本库与远程仓库同步即可。
3.1.添加变化
不管是对代码的增加、删除或修改，都需要将变化添加到版本库中来完成通知，所以最基本的操作便是添加变化。具体步骤为一下四个部分：
-
git status，用来查看文件状态。未修改之前，工作区的文件与版本库记录的一致。当修改后，使用此命令可以看到差异的文件。 -
git diff，用来查看差异文件的变化内容。通过行首的---和+++符号来表示增加、删除和修改的位置。 -
git add，用来添加变化到暂存区。添加的文件变化有两种，其一是以前存在，后被修改过的；其二是以前不存在，后新加入的。 -
git commit，用来将暂存区的内容全部提交到某个分支上，并清空暂存区。需注意的是，分支是代码功能上的区分，是修改代码的基础；而版本是某分支在时间上的变化。
3.2.撤销变化
当觉得修改的文件有问题想撤销时，需根据变化传递的位置来做不同处理。通过上面的一节可以知道分为四种情况：
- 变化还在工作区，通过
git checkout，将工作区还原到版本库记录的那样。通常用.表示所有文件，若仅对某个文件，可以后加文件名，其它命令符同理。 - 变化位于暂存区，通过
git reset，移动变化回工作区。通常参数为HEAD，先把工作区的代码还原到HEAD所指向版本，即修改前的版本，再添加撤回的变化。 - 变化在本地分支，也是通过
git reset。由于HEAD表示当前版本，即分支最新版本，所以参数为HEAD^或HEAD^^表示上一个或上上一个版本，或HEAD~n(n为数字)，表示回退n个版本。同理暂存区为空，所以不会有变化移到工作区。可是，若已经提交很多次，记不住哪一次修改了什么，怎么办？git log可以按时间由近到远查看提交日志，其中一长串SHA1的字符串就是commit id，唯一标识某次提交，用它（前七位足够了）代替HEAD就可以切换到任意版本。 - 撤销版本回退，是一件麻烦的事。由于
git log不会显示HEAD之后的commit id，所以无法切换到HEAD之后的版本。这时需git reflog查询自己所有的操作以及对应版本的commit id，便又可以git reset了。
4.远程的版本控制
Git是分布式的版本控制系统，由上面可知，分布式体现在每个本地节点都可以独立完成版本控制，但总还是需要Master节点来协调的。远程仓库便是Master节点，通过同步各个本地节点的变化到仓库服务器，从而合并所有的变化，形成最新的代码。
由于这节内容较多，放到下一篇文章中具体分析说明。
5.总结
对于版本控制一定要抓住变化传递这个点。每个版本之间的区别就是彼此间的变化，版本库中存的也是变化，而不是每个版本的所有变化文件，那样太浪费磁盘空间了，尤其是项目特别大时。
