1、介绍

Microsoft Visual SourceSafe，简称vss。是一款早期微软推出的版本管理工具。跟据官方的定义，vss有两种控制模式：独占（Lock-Modify-Unlock Model）和并行（Copy-Modify-Merge Model）。独占模式相当于某个文件被锁定了，只能由指定的用户编辑和版本管理，其他用户只有只读权限。并行模式相当于，所有用户都可以改这个文件以及进行版本管理。功能上和今天的Git类似，适用于小型团队局域网开发。

2、安装与使用

2.1、安装教程

Microsoft.Visual.SourceSafe.2005

链接：https://pan.baidu.com/s/1JEAh3v2d0FkMY1sZtZNGoQ
提取码：yyds

下载解压，找到setup.exe文件，双击直接跟着安装向导走就行了。

2.2、使用教程

2.2.1、独占模式

Step1、配置vss的database

打开Microsoft Visual SourceSafe，并进行一些设置。

Step2、登录vss

在完成Step1的设置后，就可以打开vss了，默认用户名为：admin，无密码。

Step3、管理指定文件

新建一个项目

check out你要改的文件

然后你就独占了这个文件

选中文件，右键Show Difference，可以查看你在最近一版上做了哪些修改，和git一样，绿色的是新增，紫色的是修改。

如果你改好了文件，并且觉得没什么问题了，就可以Check In这个文件，把你的修改提交上去作为最新一版，相当于 git commit -m xxx。

选中指定文件，右键Show History，可以查看该文件的历史版本信息。

注：如果你用其他用户登录的话，或者你长时间没有登录的话，你要先设置一下working folder的，所谓working folder就是你版本管理的那个文件夹。

2.2.2、并行模式

创建的过程和独占模式一样，只是在选择Team Version Control Model的时候，你选择下面那个“Copy-Modify-Merge Model”就行了。

独占模式下，同一个文件只能被一个用户check out，但在并行模式下，一个文件可以被多个用户check out。

其实就是相当于New Branch from xxx分支

即创建本地分支git branch xxx分支名，在把远程上面的分支拉到本地创建的这个分支上 git checkout xxx分支名。

当然你在check in的时候，可能会产生冲突（只有并行模式会产生冲突，独占模式不会产生冲突）

2.2.3、Microsoft Visual SourceSafe Administration

这是一款vss的管理工具，主要负责创建vss用户以及分配权限。

1、创建用户

2、Visual SourceSafe 取消默认登录

3、总结

Visual SourceSafe是我目前所在的公司内网系统开发所用的版本管理工具。用来管理服务器上运行的代码。我公司的vss设置的是“独占模式”。vss的独占模式和并行模式我都有用过，总体比较而言。并行模式并不好用，如果使用vss进行版本管理的话，推荐使用独占模式。并行模式因为允许多个用户同时修改某个文件并进行该文件的版本管理（同一个文件同时允许多个用户check out）。从而导致了如果在沟通不全面的情况，可能这个用户还在改这个文件的代码，但其他用户已经对这个文件改完了。他直接check in了，就会导致一些别的开发人员尚未开发完的有问题的代码也被提交上去。当然独占模式也会有这个问题，有些用户明明没有check out这个文件，但依旧改了这个文件并保存了。但是呢，因为最终版本控制权只在那个check out的用户（同一个文件在同一时间段内只允许一个用户check out）。大不了先把修改的部分备份一下，先undo checkout撤销该文件的所有更改回到之前那个版本，再把自己备份的修改部分复制进去就行了。

Visual SourceSafe，不管是独占模式，还是并行模式，都属于分支模式中的TBD（主干开发模式）。有关分支模式的详细可以看下这篇：如何选择 Git 分支模式？ - 知乎 (zhihu.com)

vss只适用于一些小型的闭源的局域网开发的系统。好处在于只有一个主干分支，所有人都在上面开发。独占模式下，如果你要改某个文件，可能要等其他人把这个文件释放了(check in OR undo checkout)你才能改。有可能出现死锁的情况。这样只能先把所有的更改备份，然后都释放文件，让其中一个人都改完check in了，其他人再依次排队修改。

关于TBD模式，其实我最早在大学里面做一些小组作业的时候，就用到了类似的版本管理方法。只不过当时大家都不知道git。一个项目，你先写，写完你负责的部分后再打包发给下面一个人，下面一个写完他的那部分后，再打包发给另一个人。反正发来发去，就是同一个压缩包在不同的人之间传。嗯，这样一看，不就是TBD了吗！

对于Git-Flow模式，我看许多开源的并且允许大家一起维护的项目，好像基本上都是这种模式。一个分支专门用来修bug，一个分支专门用来开发新功能。你想使用这个开源项目的话，就去拉release分支。

关于GitHub-Flow和GitLab-Flow，我也和那篇知乎文章的作者一样，觉得这两种模式差不多。可能一些传统的项目用GitHub-Flow比较多一些吧。开发的话，自己单独建一个分支（通常是自己的名字+任务号+日期这样命名分支的）开发，开发好后再合到测试分支上打包发测试环境测试。没问题了，最后合到生产分支上生产打包发布。一些微服务的项目因为有分支自动打包发布功能，所以更偏向于使用GitLab-Flow，提一个合并请求，合并即发布。