A、 从VSS到SVN再到Git 记Git的基本操作。
原文地址：https://blog.csdn.net/u012104256/article/details/53497097
Source code control 一直是软件开发过程中重要的环节，从最初的纯文件备份，到使用工具进行管理。Source code control 工具的作用也不仅仅只是单纯的对同一个版本进行管理了。从目前主流的source code control工具当中不难发现里面的Branch, tag等功能的应用场景越来越多，特别是现在多数企业使用的敏捷编程，结合branch和tag等功能真的能够很好的做到多版本开发，快速迭代。
思考： 没有source code control我们如何快速的基于一份代码同时进行多个功能的并行开发。
回过头来说下本人在行业当中所用到的几款source code control工具。
VSS
VSS(Visual Source Salf)，是一款微软提供的代码管理工具，作为Visual Studio的一员，在早期的开发过程当中确实能够确保代码不被开发人员错误的修改，也解决了异地开发协作的代码共享管理的难点。但是依旧有一些不足，比如：
- 文件基本以独占的形势进行锁定。如果A在修改的时候B没有办法进行修改。
- VSS只支持Windows版本，支持的开发工具仅支持微软系。
- 基于文件存储，服务器必须共享文件夹。安全性值得考虑。以前一般用于内网开发环境。
- 收费
SVN
SVN(Subversion)，一个开源的source code control system。除开最基本的如VSS提供的代码管理功能外，最大的亮点是提供了分支，且提交内容的级别基于代码行了。也就是说，不用再有独占文件开发的问题了。比如，一个实现接口的代码文件可以由多个开发人员同时修改。谁先做完谁可以先进行提交，不会等到必须所有的人做完后再进行合并。对于不能使用VSS的工程师来说，SVN的出现完全是一个福音，直接从CVS跳到了这么强大的工具上。
总结一下，SVN的优劣如下：
- 优势：
- 代码一致性高。
- 支持提交事物性操作。
- Diff 功能。
- Branch,Tag的引用，方便版本管理。
- 轻松上手。
- 劣势
- 必须是联网状态下才可以进行一些数据的读取。
- 不是分布式的代码库。
- SVN服务器崩溃的灾难是巨大的。
Git
随着开源运动的流行（Liunx开发人员的功劳），Git也就这么流行起来的。说是在随着开源运动的流行而流行起Git的呢？这归功于Git的分布式这一特性。试想，如果全世界所有的Liunx爱好者都在几台机器上进行开发和提交，这酸爽不敢想象。抑或是主服务器崩溃了，那么其他的开发人员也只有泪奔。
Git的牛逼之处在于以下：
- 每一次Clone就是从服务器上pull到了所有的内容，包括版本信息。
- 在本地可以根据不同的需要，本地新建自己的分支。
- 分支之间的任意切换。
- 单机上就可以进行分支合并。
- 牛人＋插件加持。 Git flow, 按Vincent Driessen 分支模型提供的一个插件.
A successful Git branching model
如何使用Git
- 安装
-
$ Brew install git
-
创建仓库
- $ git init
-
文件操作
有了仓库后就可以对文件进行 add , commit, push 和pull等操作了。
| Tables | Are |
|---|---|
| git add | 添加至暂存区 |
| git add–interactive | 交互式添加 |
| git apply | 应用补丁 |
| git am | 应用邮件格式补丁 |
| git annotate同义词，等同于 git blame | |
| git archive | 文件归档打包 |
| git bisect | 二分查找 |
| git blame | 文件逐行追溯 |
| git branch | 分支管理 |
| git cat-file | 版本库对象研究工具 |
| git checkout | 检出到工作区、切换或创建分支 |
| git cherry-pick | 提交拣选 |
| git citool | 图形化提交，相当于 git gui 命令 |
| git clean | 清除工作区未跟踪文件 |
| git clone | 克隆版本库 |
| git commit | 提交 |
| git config | 查询和修改配置 |
| git describe | 通过里程碑直观地显示提交ID |
| git diff | 差异比较 |
| git difftool | 调用图形化差异比较工具 |
| git fetch | 获取远程版本库的提交 |
| git format-patch | 创建邮件格式的补丁文件。参见 git am 命令 |
| git grep | 文件内容搜索定位工具 |
| git gui | 基于Tcl/Tk的图形化工具，侧重提交等操作 |
| git help | 帮助 |
| git init | 版本库初始化 |
| git init-db* | 同义词，等同于 git init |
| git log | 显示提交日志 |
| git merge | 分支合并 |
| git mergetool | 图形化冲突解决 |
| git mv | 重命名 |
| git pull | 拉回远程版本库的提交 |
| git push | 推送至远程版本库 |
| git rebase | 分支变基 |
| git rebase–interactive | 交互式分支变基 |
| git reflog | 分支等引用变更记录管理 |
| git remote | 远程版本库管理 |
| git repo-config* | 同义词，等同于 git config |
| git reset | 重置改变分支“游标”指向 |
| git rev-parse | 将各种引用表示法转换为哈希值等 |
| git revert | 反转提交 |
| git rm | 删除文件 |
| git show | 显示各种类型的对象 |
| git stage* | 同义词，等同于 git add |
| git stash | 保存和恢复进度 |
| git status | 显示工作区文件状态 |
| git tag | 里程碑管理 |
.
.
Best practice
建议使用github进行上手实验。使用邮箱注册一次Git hub后即可在Github上创建自己的Repository.
创建完成后，我们会得到一个Repository的地址。有了这个地址我们就可以进行Git的练习了。
-
使用 git clone 将远程仓库clone到本地。
git clone
- 添加一些文件
echo "Hello Scott" -> "Hello" //写了一个文件到Hello
git add Hello // 将Hello文件添加到暂存区。(Index) git commit -m "this is my first file" // 提交到本地仓库 git push //推送本地仓库到远程仓库
以上，文件就被推送到了远程仓库。其他工程师如果执行Pull操作的话即可把变动的文件拉到本地。
- 如果有其他工程师修改了文件，需要远程获取下。
git pull //拉取远端文件 git log //可以查看变更历史
- 冲突的解决
冲突往往是因为版本不一致而产生。如工程师A修改了Hello文件并提交到远端仓库，而B在本地修改了Hello，也想提交。由于A和B的Hello文件并不一致，所以冲突产生了。
只需要git pull一次即可。 （注：git pull 会自动merge，但是通常情况下自动merge效果不会太好。比如A和B 都在修改function A (){} ）
冲突长这模样。
一般手动解决冲突后，重新添加，提交，push即可。
如上描述，手动合并冲突比较麻烦。建议使用工具进行git 的操作，现在一般的工具都提供了分支管理，合并等功能。
推荐 SourceTree
分支的管理
在很多时候会遇到同时需要开发多个功能，开发任务将会交给多个工程师进行开发，这个时候在Git上的实践为－－>创建多个分支。 N个工程师从Master或Dev分支进行分支创建。
git checkout -b NewFeature // 分支建好后，会直接切换到该分支。
git push --set-upstream origin NewFeature //与远程分支关联完成开发后，需要合并到Master 或Dev 分支。
git merge origin/NewFeature // 将远程分支NewFeature与当前分支合并。
| 项目 |
VSS |
SVN |
备注 |
| 原子性提交 Atomic commit |
不支持 |
支持 |
SVN无论批量提交包含多少文件修改，只有当全部文件修改都成功入库，该提交才变得有效，才对其他用户可见；否则，无论任何原因造成中断，SVN都会自动“回滚”(rollback)操作。换一个说法，SVN保证所有的修改要么全部入库生效，要么个也不入库，即对版本库不作任何修改。 |
| 重命名 |
不支持 |
支持 |
这对Java和C#开发很重要，为了得到更好的代码，开发中需要经常进行重构，重构就经常涉及到文件的重构名，有时会对文件重命名再提交。 |
| 最小提交块 |
文件 smallest commit block is a file |
行 a line is the smallest commit block |
最小提交块是文件，这样通过看历史很难找出某次checkin到底checkin了什么东西 |
| 安全性 |
基于文件系统共享实现对服务器的访问，需要共享存储目录 |
SVN服务器有自己专用的数据库，文件存储不采用“共享目录”方式，所以不受限于局域网。客户端可以是不同的平台，都是通过tcp/ip和特定端口来访问SVN服务器，有不同安全等级的访问协议可供选择 |
是不是每次使用VSS的时候得登记一次服务器？麻烦了吧 |
| 离线开发操作 |
需要执行几个步骤也可以安全入库，但麻烦 |
不需要另外操作 |
|
| 模式 |
主要采用独占模式（checkout,modify,checkin）也可以使用（multi_checkout,modify,checkin,merge）模式。 |
使用update,modify,commit方式。每个人可以修改自己可以访问的任意代码，代码不会被一个人单独占用。可以多人修改同一份代码，并且每个人的修改结果都不会丢失。如果提交时SVN没有发现冲突，则代码可以直接入库。否则SVN会让你手工合并 |
|
| Internet网络和远程协作 |
VSS8.0支持 |
更适合基于互联网协作开发，速度快 |
|
| 支持平台 |
Windows |
Windows,Linux,Unix works on windows, linux, unix, and even macs and also java which makes it ultimaly portable |
|
| 支持开发工具 |
VS6, VS.NET2005, VS.NET2008(不过有个bug) VSS Plugin for Eclipse |
SVN for VS.net 2005 Plugin-AnkhSVN, 也支持vs.net2008, SVN for Eclipse |
|
| 客户端 |
VSS client |
Windows下：TortoiseSVN，Linux下：RapidSVN |
|
| 自动合并 |
据说VS2005中也支持了？ |
提供，如果不能自动合并，可以手工修改冲突 |
|
| 多版本分支的合并 |
|||
| 版本分支 |
有 但在操作中VSS首先要做项目共享,引入要分支的项目或文件然后做分支操作 |
有 自动建立分支 |
|
| 异地开发 |
支持 |
支持 |
|
| 操作的便利性 |
安装、配置、使用均简单，很容易上手使用 |
安装、配置较复杂，但使用简单，只需对配置管理做简单培训即可 |
|
| 版本管理 |
手工 通过label来自定义一个版本号，可以解决部分项目管理的问题，但这是远远不够的，当一个产品根据用户需求产生一系列不同的项目版本时使用VSS将难以管理 |
提交时记录版本号，自动分支管理 |
VSS版本发行时只能手工挑选对应的版本文件进行发布。 |
| 与外围工具集成 |
各种各样的外围工具（主要是服务器端），满足多种需要。如果有需要也可以自己写插件或管理脚本，开放的架构，允许我们这样做。 |
||
| 费用 |
商业 proprietry |
开源免费 open source (Apache/BSD-style license.) |
微软自己不用VSS，它用啥？SouceDepot！
不同意很多人说的“工具够用就行”，就算是两件工具可以完成完全一样的功能，其设计哲学和使用方式上肯定也会有区别。如果是每天必用的工具，不够便利的，或者蹩脚的使用方式会持续的影响你工作时的心情，而谁又愿意每天工作时都被工具逼得心情不好？
http://www.javaeye.com/post/583660?page=1
使用VSS，如果我周末回家办公，怎办？把代码全部checkout，再通过vpn连加VSS。
反对：如果我是甲方，要审查你的代码，svn可以直接通过http浏览代码，非常轻松，而VSS，还得装VSS客户端（license谁给？），还要用VPN连到乙方的局域网里（人家也得要有VPN啊，许多小公司网络是租用的没有vpn）
Subversion比VSS强的一个地方是如果文件改名了，以前的历史记录不会被丢失。呵呵，打个比方，Subversion就像一个聪明的警察，尽管罪犯虽然改名或整容了，但是他的前科还是被这个聪明警察给顺藤摸瓜给记录下来了。而VSS就像一个有点健忘的警察，罪犯名字一改，VSS就完全忘记了他的前科。
VSS 和 SVN/CVS 在锁定和非锁定上的处理源自应用环境的不同.
VSS 产生于微软这样的 close source 的企业, 而在这样的企业里, 开发软件时, 团队成员间通常就在一个办公室里, 文件的锁定/解锁的协调相对容易, 任务也许可以真的分配到一个人就在一个文件上工作; 但, 在开源世界里, 开发人员来自世界各地, 在世界的每个角落/不同时间里参与着项目的开发, 如果你今天在北京把一个文件锁住, 晚上没做完, 没提交, 然后睡觉去, 我们美国的同志们若也参与这个功能的开发, 那么在北京时间凌晨 2:00 的时候, 你尚在美梦中, 而那边已是早上 9:00 的工作点, 这样就没法对这个文件进行修改, 只能等到你呼呼睡醒, 北京时间 9:00 上班, 而美国那边已经是 16:00, 浪费大半天, 该下班了...
那么我们在公司里, 是不是其实应该很适合用 VSS 呢? 举个简单的例子就知道不行了 - g20 项目中我们有个 g20.js 的文件, 所有 ajax 相关的功能都在这个将近 6K 行代码的文件里完成, 我们的同学们经常需要同时并行着做两个以上的功能, 这使得我们不可能采用锁定的模式. 而 SVN 的拷贝-修改-合并模式并没有在现实中带来想像中的那么多"冲突" - 只要功能拆解得当, 不会出现两个人同时修改同一个文件同一行的情况, 最常见的情况就是你在 200 行后加了个 function, 我在 300 行后编辑了一些条件判断.
C、project从VSS迁移到SVN，保留日志。原文地址：https://blog.csdn.net/gege_zhailot/article/details/52488247
得空研究了一下如何将项目从VSS迁移到SVN,上网查了很多资料,发现没有几篇相关的文章,而且照着别人的方法试也没有成功,最后我自己摸索了一番,成功将project迁移,现在分享一下,希望能帮助需要帮助的人.
我在自己电脑上模拟迁移过程,
工具:vss 2005, virtualSVN, TortoiseSVN
IDE: visual stdio 2010
1.安装vss,创建database: repo1;
2.将vss与visual stdio绑定,步骤自行百度,(安装vss,和vs的project存到vss的仓库里的步骤我是按照网上的视频做的,网址找不到了,谁实在找不到的话给我留言)
3.在vs中创建项目,会自动让你选择vss登录用户,要存入的database
4.下载vss2svn工具,解压到c:\vss2svn,将里面的dll文件放入c:\window\System32目录下
5.cmd进入dos窗口,然后输入cd c:\vss2svn
6.输入vss2svn.exe --encoding=gbk --vssdir repo1 //vss database的名字
7.这样在c:\vss2svn目录下就生成了一个dumpfile.dat文件
8,打开visualSVN server Manager,右击repositories,选择importing existing repository,然后选择第二项,load repository from a dump file,找到之前生成的dumpfile.dat文件,就可将project导入到SVN中,VSS中的日志也会保存