这些技术你可能暂时不会用到，但是一旦软件体量变大，开发人数增加，这就带来质变，需要借助一些工具或者技术才能完成这些复杂的工程。
你可以从最简单的情况思考，你可以对任何类型的文件进行版本控制，比如一个ppt，你修改之后不满意，想回到以前某个时间点的状态。最原始的做法就是本地存储之前未修改的文件。接下来人们又遇到一个问题，如何让在不同系统上的开发者协同工作？ 于是，集中化的版本控制系统(Centralized Version Control Systems，简称 CVCS)应运而生
这种做法带来了许多好处，特别是相较于老式的本地 VCS 来说。 现在，每个人都可以在一定程度上看到项目中的其他人正在做些什么。 而管理员也可以轻松掌控每个开发者的权限，各个开发人员也能够各司其职，协同完成软件开发，并且管理一个 CVCS 要远比在各个客户端上维护本地数据库来得轻松容易。事分两面，有好有坏。 这么做最显而易见的缺点是中央服务器的单点故障。
于是分布式版本控制系统(Distributed Version Control System，简称 DVCS)面世了。 在这类系统中，像 Git、Mercurial、Bazaar 以及 Darcs 等，客户端并不只提取最新版本的文件快照，而是把代码仓库完整地镜像下来。 这么一来，任何一处协同工作用的服务器发生故障，事后都可以用任何一个镜像出来的本地仓库恢复。 因为每一次的克隆操作，实际上都是一次对代码仓库的完整备份。
Git 有三种状态，你的文件可能处于其中之一：已提交(committed)、已修改(modified)和已暂存(staged)。 已提交表示数据已经安全的保存在本地数据库中。 已修改表示修改了文件，但还没保存到数据库中。 已暂存表示对一个已修改文件的当前版本做了标记，使之包含在下次提交的快照中。
由此引入 Git 项目的三个工作区域的概念：Git 仓库、工作目录以及暂存区域。工作目录、暂存区域以及 Git 仓库如下图所示
感觉又是命令行操作，没有GUI，初期可能不方便，但是到后期会很快的。还可以学习shell语法。
-------------------------------------------9月22---------
试了一次远程退，基本命令是revert head~x， force push。之前很多次都是push reject，后来去程序仓库看，其实是没有开启覆盖权限，可能不同的仓不同，比如去掉protect权限。