关于VCS版本控制（Version Control Systems）
什么是“版本控制”？我为什么要关心它呢？ 版本控制是一种记录一个或若干文件内容变化，以便将来查阅特定版本修订情况的系统。 在本书所展示的例子中，我们对保存着软件源代码的文件作版本控制，但实际上，你可以对任何类型的文件进行版本控制。
如果你是位图形或网页设计师，可能会需要保存某一幅图片或页面布局文件的所有修订版本（这或许是你非常渴望拥有的功能），采用版本控制系统（VCS）是个明智的选择。 有了它你就可以将某个文件回溯到之前的状态，甚至将整个项目都回退到过去某个时间点的状态，你可以比较文件的变化细节，查出最后是谁修改了哪个地方，从而找出导致怪异问题出现的原因，又是谁在何时报告了某个功能缺陷等等。 使用版本控制系统通常还意味着，就算你乱来一气把整个项目中的文件改的改删的删，你也照样可以轻松恢复到原先的样子。 但额外增加的工作量却微乎其微。
1. 本地版本控制系统
许多人习惯用复制整个项目目录的方式来保存不同的版本，或许还会改名加上备份时间以示区别。 这么做唯一的好处就是简单，但是特别容易犯错。 有时候会混淆所在的工作目录，一不小心会写错文件或者覆盖意想外的文件。
为了解决这个问题，人们很久以前就开发了许多种本地版本控制系统，大多都是采用某种简单的数据库来记录文件的历次更新差异。
其中最流行的一种叫做 RCS，现今许多计算机系统上都还看得到它的踪影。 甚至在流行的 Mac OS X 系统上安装了开发者工具包之后，也可以使用 rcs 命令。 它的工作原理是在硬盘上保存补丁集（补丁是指文件修订前后的变化）；通过应用所有的补丁，可以重新计算出各个版本的文件内容。
接下来人们又遇到一个问题，如何让在不同系统上的开发者协同工作？ 于是，集中化的版本控制系统（Centralized Version Control Systems，简称 CVCS）应运而生。 这类系统，诸如 CVS、Subversion 以及 Perforce 等，都有一个单一的集中管理的服务器，保存所有文件的修订版本，而协同工作的人们都通过客户端连到这台服务器，取出最新的文件或者提交更新。 多年以来，这已成为版本控制系统的标准做法。
这种做法带来了许多好处，特别是相较于老式的本地 VCS 来说。 现在，每个人都可以在一定程度上看到项目中的其他人正在做些什么。 而管理员也可以轻松掌控每个开发者的权限，并且管理一个 CVCS 要远比在各个客户端上维护本地数据库来得轻松容易。
事分两面，有好有坏。 这么做最显而易见的缺点是中央服务器的单点故障。 如果宕机一小时，那么在这一小时内，谁都无法提交更新，也就无法协同工作。 如果中心数据库所在的磁盘发生损坏，又没有做恰当备份，毫无疑问你将丢失所有数据——包括项目的整个变更历史，只剩下人们在各自机器上保留的单独快照。 本地版本控制系统也存在类似问题，只要整个项目的历史记录被保存在单一位置，就有丢失所有历史更新记录的风险。
3. 分布式版本控制系统
于是分布式版本控制系统（Distributed Version Control System，简称 DVCS）面世了。 在这类系统中，像 Git、Mercurial、Bazaar 以及 Darcs 等，客户端并不只提取最新版本的文件快照，而是把代码仓库完整地镜像下来。 这么一来，任何一处协同工作用的服务器发生故障，事后都可以用任何一个镜像出来的本地仓库恢复。 因为每一次的克隆操作，实际上都是一次对代码仓库的完整备份。
更进一步，许多这类系统都可以指定和若干不同的远端代码仓库进行交互。籍此，你就可以在同一个项目中，分别和不同工作小组的人相互协作。 你可以根据需要设定不同的协作流程，比如层次模型式的工作流，而这在以前的集中式系统中是无法实现的。
提交+Push
如果本地开发代码有改动了或者你觉得某功能做完了，你打算把改动代码提交到远程仓库，这个时候很简单，
还是在工具栏找到VSC箭头朝上的按钮。
这时首先会弹出commit changes对话框,然后再下面的蓝色Commit按钮点右边下拉三角形，选中Commit and push
本地commit成功之后就会弹出push commit对话框，点push就推送到远程仓库了。
更新+Pull
我们直接在远程仓库更改代码来模拟别人的代码提交：
这时我们在工具栏VSC按下向下的按钮，弹出下面这个对话框:
这个如果不知道怎么选可以点Help按钮，将会打开链接告诉你这几个有什么作用。
失败了，没有跟踪的分支...
按照以往的知识还是先pull吧：
没有可选的分支,,,?
按照以往的知识还是先fetch
OK，fetch还是很容易成功的哈。
然后呢，merge changes:
这个框和pull框有点像，不过这里merge分支可以选择了。
merge成功了。
这个时候点向下的VSC按钮就可以成功了：
OK啦，以后就可以直接点击工具栏的VSC两个按钮了。
再试一下，在远程仓库再改一次文件，然后pull。
这时候也成功了。
查看状态
在Android Studio的项目当中，在项目结构面板可以看到各种文件，其中
黑色的文件：代表已经和远程目录同步了的。如果这时去改动文件内容将会变成紫色的。
红色的文件或目录：代表是不受版本控制的文件或目录。当然可以把它添加到控制，通过git/add就可以添加到版本控制了，添加成功后就会变成绿色。
绿色的文件：代表本地提交了，但没有push到远程仓库。你在绿色的文件怎么修改都还是绿色在你没push到远端之前。
紫色的文件：代表和远端仓库同步了的文件，并且在本地有了改动。
首先我添加一个新文件，这是Android Studio就很智能的提示我，要不要加入git版本控制。
你点是就会看到项目文件里的MyClass由红色变成绿色
上图所示MainActivity是更改过的，MyClass新加入的
这个时候提交：
Commit Message右上角就会显示New 1 Modyfied 1表示一个新文件，一个文件修改过。
这个时候按提交，蹦出一个Code Analysis对话框，说有些文件有问题。
这说明AndroidStudio的特性，是一个代码重构，代码分析的神器啊。
当然这个时候可以回去Review也可以直接提交。
如果我想把项目已存在的文件提交到git怎么办呢：git/add后就回变绿色，然后按commit就会出现以下窗口：
上图 .gradle目录都是红的，说明这个目录的文件都不受版本控制。