集中化的版本控制系统(Centralized Version Control Systems，简称 CVCS)
让在不同系统上的开发者协同工作。 CVS，Subversion 以及 Perforce 等，都有一个单一的集中管理的服务器，保存所有文件的修订版本，而协同工作的人们都通过客户端连到这台服务器，取出最新的文件或者提交更新。缺点是中央服务器的单点故障
分布式版本控制系统（ Distributed Version Control System，简称 DVCS ）
Git，Mercurial，Bazaar 以及 Darcs 等，客户端并不只提取最新版本的文件快照，而是把原始的代码仓库完整地镜像下来。更进一步，许多这类系统都可以指定和若干不同的远端代码仓库进行交互
Git基础 (http://progit.org/book/zh/ch1-3.html)
与其他版本控制的差异化（Git保存每次更新时的文件快照）
基本的 Git 工作流程如下：
1. 在工作目录中修改某些文件。 2. 对修改后的文件进行快照，然后保存到暂存区域。 3. 提交更新，将保存在暂存区域的文件快照永久转储到 Git 目录中。
安装git http://progit.org/book/zh/ch1-4.html
生成ssh公钥 http://progit.org/book/zh/ch4-3.html
$ cd ~/.ssh
取得项目的Git仓库:
在工作目录中初始化新仓库:git init
从现有仓库克隆 git clone [url]
本地仓库的操作:
工作目录下面的所有文件都不外乎这两种状态(git status)：已跟踪或未跟踪
git add 工作目录中的新文件或修改后的文件保存到暂存区域。可以指明要跟踪的文件或目录路径。如果是目录的话，就说明要递归跟踪该目录下的所有文件
已跟踪状态下分为：未暂存、已暂存
git commit 提交已暂存的文件到本地仓库。git commit -a 跳过暂存区使用，一并提交所有已跟踪过的文件（不包括未跟踪状态的文件，该功能区别于eclipse自带的git插件）
取消对文件的修改:git checkout --
取消已经暂存的文件:git reset HEAD
修改最后一次提交(不能取消)：git commit --amend
查看提交历史 git log （git log -p -2，-p展开显示每次提交的内容差异，-2仅显示最近的两次更新）
远程仓库的操作:
git remote 要查看当前配置有哪些远程仓库，至少有一个名为origin的远程库
分支（branch）：http://progit.org/book/zh/ch3-1.html
一个简单的分支与合并的例子，实际工作中大体也会用到这样的工作流程：
1. 开发某个网站。 2. 为实现某个新的需求，创建一个分支。 3. 在这个分支上开展工作。4.突然有个严重问题需要紧急修补
可以按照下面的方式处理：
1. 返回到原先已经发布到生产服务器上的分支。 2. 为这次紧急修补建立一个新分支，并在其中修复问题。 3. 通过测试后，回到生产服务器所在的分支，将修补分支合并进来，然后再推送到生产服务器上。 4. 切换到之前实现新需求的分支，继续工作。
对应命令：1.git checkout -b iss53；（创建并切换到新分支开发新功能）; 2、git checkout master；git checkout -b hotfix(回到master创建并切到BUG分支)；3、git checkout master，git merge hotfix（切回master合并BUG分支）;4、git branch -d hotfix,git checkout iss53(删除BUG分之，切回新功能分支)
开发中一般会在master分支提交
一次 Git 克隆会建立你自己的本地分支 master 和远程分支 origin/master。执行pull时，分支合并原理同于本地仓库
良好习惯：提交代码前应是先pull再commit、push；若pull时出现冲突，解决冲突，完成后git status查看确认，然后git add冲突文件到暂存区域，commit提交之。
个人认为git的亮点在于：1、本地仓库；2、分支
eclipse的git插件 egit
下载最新eclipse,旧版的不支持 http://www.eclipse.org/downloads/
Available Software Sites中添加 http://download.eclipse.org/egit/updates