集中式版本控制系统
版本库集中存放在中央服务器,而工作时都是用自己的电脑，所以要先从中央服务器取得最新的版本，然后工作完后再将自己的代码推送给中央服务器。集中式版本控制系统最大的问题就是必须联网才能工作，受网络状况、带宽影响。
CVS
SVN：开源免费。修正了CVS的一些稳定性问题，是目前用得最多的集中式版本库控制系统
ClearCase：收费、安装比Windows还大、运行比蜗牛还慢。IBM 收购了原本制作的Rational公司
VSS：集成在Visual Studio中
分布式版本控制系统
分布式版本控制系统可以有也可以没有中央服务器，其允许开发人员组实现他们选择的几乎任何工作流，每个人的电脑上都是一个完整的版本库，所以不需要联网。将修改进行推送完成多人协作.
Git、BitKeeper(促使Git诞生)、Mercurial和Bazaar等
Git:Quick Start
对于一个已经存在的项目提交到github:
cd /path/of/project
git init
git add *
git commit -m "first commit"
git remote add origin https://github.com/xx/DDxx.git
git push -u origin master
cd 到项目目录;初始化本地Git仓库;把要提交的所有修改放到暂存区,可以添加多个文件;git commit一次性把暂存区的所有修改提交到本地仓库;关联本地仓库和远程仓库;将本地仓库的提交推送至远程仓库;
常用命令:
git status 命令返回仓库当前的状态.
Changes not staged for commit(已经修改尚未添加)/Changes to be committed(已经添加等待提交)/nothing to commit, working tree clean(继上一次提交后,没有需要提交的修改)
git diff readme.txt 返回上次对文件readme.txt的具体修改内容
git log 命令显示从最近到最远的commit提交日志
git reflog 记录每一次git执行命令,类似history
git log --pretty=oneline 显示从最近到最远的commit提交日志,按一行显示
当前版本回退:
在Git中，用HEAD表示当前版本,上一个版本就是HEAD^，上上一个版本就是HEAD^^，当然往上100个版本写100个^比较容易数不过来，所以写成HEAD~100。
git reset --hard HEAD^ 回退到上一个版本
git reset --hard commitID 回退到某一个版本,可根据git log 看版本ID
git reset HEAD readme.txt 把当前暂存区对readme.txt的修改撤销掉.(add了错误的文件时)
把暂存区的修改撤销掉（unstage），重新放回工作区
对于工作区删除的文件:
1.确定删除,并从版本库中删除文件,并提交.
git rm test.txt
git commit -m "remove test.txt"
2.误删,从版本库中还原
git checkout -- readme.txt
命令把readme.txt文件在工作区的修改全部撤销.(对于工作区误删的文件文件可以用其还原) 用版本库里的版本替换工作区的版本,无论工作区是修改还是删除，都可以“一键还原”。 让这个文件回到最近一次git commit或git add时的状态。(文件名前注意添加符号:--)
没有--符号 git checkout master 表示切换至master分支
本地仓库
1.
通过git init命令把当前目录变成Git可以管理的仓库
git init
2.
使用git add把文件添加到仓库
git add filename
3.
把添加的文件提交到仓库,-m后输入本次提交的说明,最好能够表达本次提交特征
git commit -m "wrote a readme"
同步到远程仓库
创建了本地仓库后,在GitHub上创建远程仓库使两个仓库进行远程同步.这样，GitHub上的仓库既可以作为备份，又可以让其他人通过该仓库来协作. 1.
在github上新建Repository (可以从这个仓库clone到本地仓库,也可以把已有的本地仓库与其关联)
2.
将本地仓库与远程仓库关联(远程仓库的名字为:origin)
git remote add origin https://github.com/xx/DDxx.git
3.
将本地库的所有内容推送到远程仓库.
git push -u origin master
由于远程库是空的，我们第一次推送master分支时，加上了-u参数，Git不但会把本地的master分支内容推送的远程新的master分支，还会把本地的master分支和远程的master分支关联起来，在以后的推送或者拉取时就可以简化命令。
第一次推送master分支的所有内容,使用命令git push -u origin master 之后,只要本地作了提交，就可以通过以下命令把本地master分支的最新修改推送至GitHub:
git push origin master
分支操作
git checkout -b dev
git checkout命令加上-b参数表示创建并切换，相当于以下两条命令：
git branch dev
git checkout dev
git branch命令会列出所有分支，当前分支前面会标一个*`号。
切换到dev分支下后,可以进行修改add和提交commit,提交完成后切换至master:
git checkout master
然后将dev分支合并到master:
git merge dev
git branch
git merge命令用于合并指定分支到当前分支,合并完成后可以删除dev分支:
git branch -d dev
Fast forward模式的合并直接把master指向dev的当前提交，合并速度非常快,但是Fast forward`模式删除分支后会丢掉分支信息.
禁用Fast forward模式,Git就会在merge时生成一个新的commit，这样，从分支历史上就可以看出分支信息。
git merge --no-ff -m "merge with no-ff" dev
合并分支时，加上--no-ff参数就可以用普通模式合并，合并后的历史有分支，能看出来曾经做过合并，而fast forward合并就看不出来曾经做过合并。
协作
推送分支:把该分支的所有本地提交推送到远程库对应的远程分支上
将本地的master分支推送到远程库
git push origin master
将本地的dev分支推送到远程库
git push origin dev
-
master分支是主分支，因此要时刻与远程同步； -
dev分支是开发分支，团队所有成员都需要在上面工作，所以也需要与远程同步； -
bug分支只用于在本地修复bug，就没必要推到远程了，除非老板要看看你每周到底修复了几个bug； -
feature分支是否推到远程，取决于你是否和你的小伙伴合作在上面开发。
抓取分支:
向远程仓库推送修改,过程如下:
1.
从远程仓库clone
git remote add origin https://github.com/xx/DDxx.git
此时git branch 查看分支,只能看到本地的master分支
2.
要在dev分支上开发，就必须创建远程origin的dev分支到本地
git checkout -b dev origin/dev
3.
然后在分支dev上进行修改提交等一系列操作,并时不时把dev分支push到远程
git add env.txt
git commit -m "add env"
git push origin dev
协作模式推送失败:
当你的小伙伴已经向origin/dev分支推送了他的提交，而碰巧你也对同样的文件作了修改，并试图推送会导致推送失败.这因为远程分支比你的本地更新，需要先用git pull试图合并
1.
先用git pull把最新的提交从origin/dev抓下来，然后，在本地合并，解决冲突，再推送
git pull
如果git pull失败,并提示no tracking information，原因是没有指定本地dev分支与远程origin/dev分支的链接，命令git branch --set-upstream-to <branch-name> origin/<branch-name>。
git branch --set-upstream-to=origin/dev dev
再pull：
git pull
git pull成功，但是合并有冲突，需要手动解决
2.
如果合并有冲突，则解决冲突，并在本地提交；
git commit -m "fix env conflict"
git push origin dev
BUG修复
在dev分支工作任务进行到一半,需要在master上修复bug.
操作如下:
git stash 首先把当前工作现场“储藏”起来
git checkout master 切换至master分支
git checkout -b issue_1 创建并切换至issue_1分支
git add xx / git commit xx 修复bug
git checkout master 修复完成后切换至master
git merge --no-ff -m "merge with no-ff" issue_1 合并分支至master
git branch -d issue_1 删除分支
git checkout dev 切换至未完成的工作任务dev分支
git status / git stash list 查看工作区/查看工作现场 此时工作区为空,需要从工作现场恢复
git stash apply 使用该命令恢复后,stash内容不删除,使用git stash drop 删除
git stash pop 恢复同时删除
每添加一个新功能，最好新建一个feature分支，在上面开发，完成后，合并，最后，删除该feature分支。
删除分支
git branch -d feature-vulcan
强制删除,若分支还没有被合并，如果删除，将丢失掉修改，如果要强行删除，需要使用大写的-D参数
git branch -D feature-vulcan
打标签
默认标签是打在最新提交的commit上的。
1.
切换到需要打标签的分支
git branch
git checkout master
2.
打标签以及查看所有标签
git tag v1.0
git tag
带说明的标签,用-a指定标签名，-m指定说明文字
git tag -a v0.1 -m "version 0.1 released" commit_ID
3.
对某一次提交打标签:
通过日志找到commit_ID;
对该Commit_ID打标签;
查看标签信息;
git log --pretty=oneline --abbrev-commit
git tag v0.1 commitid
git show v0.1
4.
删除标签
git tag -d v0.1
如果标签已经推送到远程，要删除远程标签.先从本地删除,然后，从远程删除
git tag -d v0.9
git push origin :refs/tags/v0.9
5.
推送某个标签到远程
git push origin v1.0
一次性推送全部尚未推送到远程的本地标签
git push origin --tags
参考链接: