常见版本管理工具
目录
一、VSS
二、CVS
三、SVN
四、GIT
1. git命令行：
2. git设置
3. 上传文件过大的问题的解决办法：
4. 常见的.gitignore设置
5. 为git添加命令补全提示
附录一、linux下的SVN使用的简单流程
1. 第一次把服务器代码下载到本地。
2. 更新本地代码
3. 把本地新修改添加的代码更新到服务器
4. 不co直接将文件添加到svn
5. 其他操作
6. 切换用户
附录二、使用主干与分支，解决版本冲突
1. svn的主干与分支
2. 主干开发，分支发布
3. 分支开发，主干发布
4. 分支开发，主干发布--改进：拉分支发布
http://blog.csdn.net/zhourui1982/article/details/4871896
http://wenku.baidu.com/view/054ae81afad6195f312ba6c6.html
一、VSS
VSS 的全称为 Visual Source Safe 。作为 Microsoft Visual Studio 的一名成员，它主要任务就是负责项目文件的管理，几乎可以适用任何软件项目。
Windows平台下使用VSS开发的典型环境是基于C/S架构的，即开发小组的每个开发者在各自的Windows平台下利用开发工具（比如VC）开发项目中的各个模块，而配有专门的服务器集中控制开发过程中的文档和代码。服务器和开发人员的客户机分别装有VSS的服务器和客户端程序。
VSS是微软的产品，是配置管理的一种很好的入门级的工具。VSS最初的名字叫Source Safe，是一家小公司的产品，92年曾经获了最佳小型管理工具奖，然后立即被微软收购。但是微软收购的只是source safe的Windows版本，在美国还有另外两家公司分别获得了继续开发和销售source safe的Mac版本和Unix版本的许可，在MS买进vss之后，基本上没有对vss进行任何的研发，MS内部自身也不用vss。
VSS 没有采用对许可证进行收费的方式，只要安装了 VSS ，对用户的数目是没有限制的。因此使用 VSS 的费用是较低的。它属于“买大件送小件”的角色。如果你合法地得到Visual Studio，你就得到了免费的SourceSafe。
注：VSS只有Windows环境。
二、CVS
CVS是一个C/S系统，多个开发人员通过一个中心版本控制系统来记录文件版本，从而达到保证文件同步的目的。CVS版本控制系统是一种GNU软件包，主要用于在多人开发环境下的源码的维护。
2009年，绝大多数CVS服务已经改用SVN。CVS已经停止维护。
三、SVN
SVN是一个安全虚拟网络系统，它将系统整体的信息安全功能均衡合理地分布在不同的子系统中，使各子系统的功能得到最大限度的发挥，子系统之间互相补充，系统整体性能大于各子系统功能之和，用均衡互补的原则解决了"木桶原理"的问题。
SVN能在跨接Internet, Intranet, Extranet间的网络所有端点实现全面的安全，而且还能提供基于企业策略的信息管理机制以充分有效地利用有限的带宽。SVN可以满足各种企业VPN的要求，通过为公司内部网络、远程和移动用户、分支机构和合作伙伴提供基于Internet的安全连接。所以，我们可以将SVN看成是VPN、防火墙、基于企业策略的信息管理软件集成在一起的Internet安全的综合解决方案。在这样一个网络系统中，所有互联网服务器端和客户端都是安全的，并有一个信息管理机制以不断地通过这个外部网络环境动态地分析及满足客户的特定带宽需求。
注：SVN客户端有Windows环境和linux环境。
四、GIT
Git --- The stupid content tracker, 傻瓜内容跟踪器。Linux 是这样给我们介绍 Git 的。
Git 是用于 Linux 内核开发的版本控制工具。与常用的版本控制工具 CVS, Subversion 等不同，它采用了分布式版本库的方式，不必服务器端软件支持（wingeddevil注：这得分是用什么样的服务端，使用http协议或者git协议等不太一样。并且在push和pull的时候和服务器端还是有交互的。），使源代码的发布和交流极其方便。 Git 的速度很快，这对于诸如 Linux kernel 这样的大项目来说自然很重要。 Git 最为出色的是它的合并跟踪（merge tracing）能力。
1. git命令行：
usage: git [--version] [--help] [-c name=value]
[--exec-path[=]] [--html-path] [--man-path] [--info-path]
[-p|--paginate|--no-pager] [--no-replace-objects] [--bare]
[--git-dir=] [--work-tree=] [--namespace=]
[]
简单而言，用法： git [command参数]
command参数可以使用该命令查看： git help
最常用command如下:
add 不但是用来添加不在版本控制中的新文件，也用于添加已在版本控制中但是刚修改过的文件; 在这两种情况下, Git都会获得当前文件的快照并且把内容暂存(stage)到索引中，为下一次commit做好准备。
git add 增加文件/目录到当前分支；
bisect Find by binary search the change that introduced a bug
branch 显示、新建或者删除一个分支；
git branch 不加参数会得到当前仓库中存在的所有分支列表，星号(“*”)标识了你当工作在哪个分支下。
git branch 新建一个分支
checkout CheckOut一个分支并切换到该分支，从而改变了当前分支为此分支
git checkout 切换到该分支
git checkout . 放弃本地所有已经编辑，但未commit/push的更改，还原为和远端一样的版本
clone 下载一个远端仓库到本地
git clone 'http(s)://[userName@]host:port/xxx/yyy/zzz.git' [dir] 使用http(s)方式从远端仓库进行clone，默认clone到本地的zzz目录，添加dir参数后则clone到dir目录内。如果添加用户名，会提示输入密码，否则使用无验证方式进行clone
git clone 'git@gitRepository:xxx/yyy/zzz.git' [dir] 使用ssh方式从远端仓库进行clone，该方式支持大文件的push和pull，需要先配置密钥，后面进行详述。
commit 提交变更到本地仓库；
git commit -a -m '' -m参数指定注释，-a参数自动添加所有并更到本次的commit中
diff 不加参数，显示未提交的本地更改内容；
加一个分支名作为参数，则将本地分支和参数指定的分支进行diff；
加2个分支名作为参数，则对这两个分支进行diff（注：这2个分支必须已经co到本地）；
加参数--stat则只给出统计信息
fetch 从远端仓库更新当前分支
grep Print lines matching a pattern init Create an empty Git repository or reinitialize an existing one
log 倒序展示commit日志
git log [--stat] 倒序展示所有的commit日志，--stat参数会显示变更的内容统计
merge 将一个分支merge到当前分支
git merge [branchName] 将该分支合并到当前分支
mv 在当前分支中移动文件/目录
pull 从远端仓库更新当前分支并智能合并
push 提交本地的所有commit到远端仓库
rebase Forward-port local commits to the updated upstream head
revert 撤销 某次操作，此次操作之前和之后的commit和history都会保留，并且把这次撤销 作为一次最新的提交
git revert HEAD 撤销最近一次的commit
reset Reset current HEAD to the specified state
rm 在当前分支中删除文件/目录
show Show various types of objects
status 展示当前分支的状态（是否commit，是否push）
tag Create, list, delete or verify a tag object signed with GPG
remote 展示当前git目录对应的远端的情况，加-v展示详细信息，例如远端的git路径
git remote set-url origin 将git root设定为其他地址
2. git设置
1） 为git设置缩写命令
修改.gitconfig文件，linux下该文件位于~/.gitconfig，在文件的末尾添加如下代码：
[alias]
co = checkout
ci = commit
st = status
pl = pull
ps = push
dt = difftool
l = log --stat
cp = cherry-pick
ca = commit -a
b = branch
r = remote -v
2）为git设置提交时的用户名和邮件
执行以下命令：
git config --global user.name "Your Name"
git config --global user.email [email protected]
# 或者直接修改gitconfig文件里的name和email配置项
3. 上传文件过大的问题的解决办法：
错误提示：
error: RPC failed; result=22, HTTP code = 411
解决办法：
git config --global http.postBuffer 52428800 （改为最大50M）
错误提示：
error: RPC failed; result=22, HTTP code = 413
该错误是因为web server不支持这么大的文件传输，可以修改ng的配置使web server来支持。或者将http方式改用ssh方式。
改用ssh方式的具体做法如下：
1. 设置远程仓库地址
git remote set-url origin git@gitRepository:xxx/yyy/zzz.git2. 客户端产生密钥
ssh-keygen -t rsa -C "[email protected]"然后按3次回车来生成对应的邮箱的密钥
3. 登录gitlab管理界面，在用户的profile中“Add SSH Key”中添加上一步生成的公钥（上一步生成的public key位于~/.ssh/id_rsa.pub中）
# 复制公钥：cat后复制全部字符串，切记不要vim后复制
cat ~/.ssh/id_rsa.pub使用以上方法后clone，push和pull等都不再需要密码。
4. 常见的.gitignore设置
# kdiff3 ignore
*.orig
# maven ignore
target/
# eclipse ignore
.settings/
.project
.classpath
# idea ignore
.idea/
*.ipr
*.iml
*.iws
# temp ignore
*.log
*.cache
*.diff
*.patch
*.tmp
# system ignore
.DS_Store
Thumbs.db
# package ignore (optional)
# *.jar
# *.war
# *.zip
# *.tar
# *.tar.gz5. 为git添加命令补全提示
执行以下命令，将 https://github.com/git/git/blob/master/contrib/completion/git-completion.bash 下载到本地，并加入bash_profile
cd
wget 'https://raw.githubusercontent.com/git/git/master/contrib/completion/git-completion.bash'
mv git-completion.bash .git-completion.bash
chmod +x .git-completion.bash
echo 'source ~/.git-completion.bash' >> ~/.bash_profile
source ~/.bash_profile
附录一、linux下的SVN使用的简单流程
1. 第一次把服务器代码下载到本地。
svn co svn_url [path]
#path可以省略，设svn_url=https://xxx/mytool，如果省略path，则在当前目录新建mytool文件夹，并下载svn_url目录里的文件下载到其中；如果path=mytool_local，就在当前目录新建mytool_local，并将svn_url目录里的文件下载到其中。
2. 更新本地代码
svn up
3. 把本地新修改添加的代码更新到服务器
a) svn st #显示状态
b) 对于显示的列表里，前面带有？的表示还没有添加到待同步列表里，使用如下命令加入到待同步列表：
svn add {文件名或目录名} #当添加一个目录，svn add缺省的行为方式是递归。path参数可以使用类似/home/root/svnroot/*/*形式
svn add * --force #命令svn add *会忽略所有已经在版本控制之下的目录，可以使用参数--force递归到版本化的目录下
c) 对于显示的列表里，前面带有！的表示本地已经删除，使用如下命令从待同步列表删除（需要先svn up将其副本更新到本地，再执行如下命令）：
svn delete {文件名或目录名}
d) svn ci -m "comment" #提交，不带comment会出错
4. 不co直接将文件添加到svn
svn import -m 'comment' [path] svn_url
#path如果省略，则使用当前目录.作为参数
#如果path为目录，则将path下的内容ci到svn_url的目录下，而不会新建path目录，故一般需要在svn_url中添加目录名。例如：svn import -m 'this is for try' tools http://xxx/bak/tools
svn co --force svn_url
#因为import后本地目录并没有被添加到svn控制之下，所以，使用co命令下载到本地，并且要加--force参数来强制执行（因本地已经存在同名目录）
5. 其他操作
svn info 需要在已经svn的目录下使用。显示当前目录的svn信息，如url地址，和用户名等。
svn rename wc(本地原来目录名/文件名) wc（重命名后的目录名/文件名）
svn move SRC DST 移动目录或文件夹命令
6. 切换用户
1). 临时切换
在所有命令下强制加上--username 和--password选项。
例如：svn up --username zhangsan --password 123456
2).永久切换
删除目 ~/.subversion/auth/ 下的所有文件。下一次操作svn时会提示你重新输入用户名和密码的。换成你想用的就可以了。然后系统默认会记录下来的。
附录二、使用主干与分支，解决版本冲突
1. svn的主干与分支
trunk--主干，是开发的主线。
branches--分支，是从主线上分出来独立于主线的另一条线。
tags--标记，主要用于项目开发中的里程碑。它往往代表一个可以固定的完整的版本。SVN不推荐在创建的tag基础上Revision这种情况应用branches，因为tag一般保持不变不作任何修改。
总之，主干和分支都是用来进行开发，而标记是用来进行阶段发布的。branches以及tags在TortoiseSVN中创建方法是一致的：它们都是通过存储类似Linux中的硬连接一样，只是创建了指向某个版本的链接，而不会真正将此版本的内容复制到分支或者标记中，这样既可以节省空间，也可以很快速的创建，被称为“廉价的拷贝”。
2. 主干开发，分支发布
典型操作步骤如下：
1) 开发者提交所有的新特性到主干。 每日的修改提交到/trunk，包括新特性bug修正和其他。
2) 这个主干被拷贝到“待发布”分支。 当小组认为软件已经做好发布的准备如版本1.0然后/trunk会被拷贝到/branches/1.0。
3) 项目组继续并行工作测试小组开始对分支进行严酷的测试同时开发小组在/trunk继续新的工作，如准备2.0。如果一个bug在任何一个位置被发现，错误修正需要来回运送。
4) 分支已经作了标记并且发布。当测试结束，/branches/1.0作为引用快照已经拷贝到/tags/1.0.0，这个标记被打包发布给客户。
5) 分支多次维护。当继续在/trunk上为版本2.0工作，bug修正继续从/trunk运送到/branches/1.0（分支也在“更新”，但只进行bug修复）。如果积累了足够的bug修正，管理部门决定发布1.0.1版本，拷贝/branches/1.0到/tags/1.0.1，标记被打包发布。
优点：
这种管理方法对已发布产品的维护工作和下一代产品的开发工作进行了隔离。对于已经发布的产品只有维护的补丁发布。而新发行的产品不仅包括了所有的bug修改，还包括了新功能。所以，非常适用于产品线的发布管理。
缺点：
1). 必须对主干上的新功能增加进行控制，只能增加下一个发布里面计划集成进去的新特性。
2). 已经在主干上集成的新特性中的任何一个，如果达不到里程碑的要求，稳定分支就不能创建，就会影响下一个发布的计划。
3). bug修改必须在各个分支之间合并。
3. 分支开发，主干发布
策略介绍：
与上一种分支策略（它的主干上永远是最新特性的不稳定版本）正好相反，此策略的主干上永远是稳定版本，可以随时发布。
bug的修改和新功能的增加，全部在分支上进行。而且每个bug和新功能都有不同的开发分支，完全分离。分支上的开发和测试完毕以后才合并到主干。
而对主干上的每一次发布都做一个标记而不是分支。
优点：
1). 每次发布的内容调整起来比较容易。如果某个新功能或者bug在下一次发布之前无法完成，就不可能合并到主干，也就不会影响其他变更的发布。
2). 每个分支的生命期比较短，唯一长期存在的就是主干，这样每次合并的风险很小。
缺点：
1). 分支开发周期不能过长，如果分支长期没有合并到主干上，很可能在最后合并的时候出现严重冲突。
2). 测试分支就是各个开发分支，而主干上的程序是没有经过测试的。（从这个发布模式上看，最后一个合并入主干的开发分支应该和主干下一次的发布内容相同，但是这个分支的测试却只是本分支的修改内容点，而非产品级别的功能回归，故称：主干上的程序是没有经过测试的）
4. 分支开发，主干发布--改进：拉分支发布
就是在发布时不是打tag进行发布，而是拉一个分支出来，测试后进行发布。
特点：
当前发布需要回滚时，可以直接将上一个发布分支覆盖到主干。并且，拉分支发布时可以测试主干上的程序，进行成品级别功能回归。