本文共 2967 字,大约阅读时间需要 9 分钟。
什么是版本控制工具?为什么使用版本控制工具?
将个人代码放在代码控制工具当中,个人代码受保护(自己口袋里的钱可以自己掏),版本控制的行为受约束(银联卡里面的钱每次转账都会有转账记录,有钱款流向可以查询)。
一个大项目的开发需要各个小伙伴相互协作,每个人的代码可以通过版本控制工具相互调用。
一般过程就是通过版本控制工具的服务端将个人代码传到版本控制工具的客户端转换成版本控制工具里面的代码。
SVN客户端、服务端安装包直接下载路径:
SVN安装与配置SVN 是一种版本控制工具
官方下载链接:
(1)SVN-客户端:TortoiseSVN 下载地址:
(2)SVN-服务端:VisualSVN 下载地址:http://www.visualsvn.com/server/download
安装install
1.配置SVN服务端:
(1)仓库配置
Repositories包括n个仓库,每个工程可以独立的放在不同的仓库中:
通过地址:可以从仓库TestRep中取文件和上传文件。
(2)添加用户
安装、配置客户端
客户端的安装比较简单,直接按照安装向导安装即可,安装目录可以自己更换。安装完成之后,在任何一个文件夹下右击都可以看到要给SVN Checkout…的选项。
客户端下载服务器端仓库
弹出要给checkout的对话框后:将服务器端的仓库下载下来
如果服务器端和客户端在同一台电脑上,地址填写有两种方式:
方式一: 如:https://Computer-Terence/svn/TestRep
方式二:https:// 服务器地址:端口号/仓库包名/仓库名 如:
如果两者在不同主机上,则只能用第二种方式填写地址。
点击OK即弹出如下用户填写界面,表示要从服务端的某个用户下下载仓库
此时,即可弹出
打开这个下载的仓库之后,里面有一个svn控制控制标志性文件夹.svn,这个文件不能删除,否则会把TestRep变成一个普通的文件夹,不能和服务端的仓库发生联系。
在该文件夹下可以在客户端对服务端的代码进行增删改查。
首先新增一个java文件
刷新服务端仓库,可以看到新增了一个文件Main.java
文件删除
删除本地仓库的Main.java文件,然后在仓库文件夹内,右击点击SVN Commit…
出现如下对话框:
Status=missing 表示该文件已经在客户端被删除,但是在服务器端没有更新文件变动情况。
勾选该文件,点击OK提交即可删除服务器端的文件。
当文件内容修改之后,弹出的提交对话框中Status=modified,表示本地修改文件没有更新到服务器端,选中提交即可更新成功。
刷新服务端仓库,查看文件内容:然后右击该修改文件-》Browser,弹出如下对话框,需要输入用户名和密码,然后可以在浏览器中查看道文件内容。
当多个用户操作同一仓库的时候。
同一个主机切换另一个用户,先清空权限
清空权限之后,就不会在通过用户A保留数据了。
用户用户B通过服务端下载同样的仓库。
当用户A和B同时对相同的文件进行操作,但是两者对相同文件做了不同的改动。
然后提交改仓库,更新改动。
此时A账户再打开的文件让然是以前保留的版本,和服务端的仓库版本不一致,此时A用户需要做的是更新服务端仓库到本地,右击本地仓库,点击SVNUpdate。
所以啊:
上班前首先要执行SVNUpdate;
下班后最后要执行SVNCommit。
但是问题来了,自己修改的代码被别人删掉或者修改了,自己又把最新版本更新到本地仓库了,应该怎么找回自己以前的代码呢?
用户A右击本地仓库,选择Tortoise SVN->Show log,查看历史版本:
然后A和B经过商量,确定了A的其中一个版本合理,决定把A的那个历史版本恢复到服务端。
右击该版本Revert tothis version—>Revert,即可恢复本地仓库的到指定版本,重新执行SVN Commit,提交更新到服务端即可。
但是如果两个人都忘了这一版本的内容,无法决定应该怎么办/
所以,一般规范的提交修改的代码都要添加修改说明,方便大家查看。
此时A更新后再查看历史版本,就可以看到修改说明。
当B把文件删除了,A更新之后找不到了自己需要的文件,应该怎么找到自己需要的版本。
右击仓库—>查看历史show log-->点击自己需要的版本,例如第9个版本,然后右击下面的修改记录—>Save reversionto……可以将丢失的文件重新保存下来。
当A和B拥有了相同的版本,同时对一个文件进行了修改,然后B手快,先提交了,
结果A在提交的时候会出现提交失败的情况:
是因为A原来的版本已经不是服务端的最新版本了,没有更新过来,就提交了自己修改的文件,此时需要先更新一下A的副本文件。
直接点击原来的提交对话框,就会出现更新提示:
直接点击Update就好。
此时会出现一个Mergered状态,表示两者更新有冲突Conflict,但是将两者的更新内容合并了起来,两者内容都会显现出来,如下图所示:虚线分割线上面是A的内容,下面是B的内容。
这种情况是一种比较好的情况,是两个用户改了不同的部分,可以合并。
但是当两者修改了同样的部分的时候,就不会合并在一起了。
提示还是和上次的一样,按照提示点击更新,此时不能合并在一起,同时多了如下图所示的三个文件。
文件说明:
自己想提交的文件Main-9.java
上述数字.r13和.r14表示版本号。
三个文件版本说明如下:
此时代码可见,A和B用户可以商量一下用哪个版本,
此时可以利用上述得到的三个副本文件来做相应的文件覆盖(修改文件名,直接替换文件可就可以了)决定用谁的版本。
如果多个用户修改了代码,既有对相同部分的修改,又新增了不同的部分,这时A再提交同样合并不成,此时不要继续更新了。
可以将自己为提交的文件复制粘贴到另一处,然后将本地仓库恢复到最新版本,也就是B做了多处修改后的另一个版本。
然后再将粘贴出去的版本改名后粘贴进来,同时选中两个文件右击—》ToroiseSVN-->Diff,可以打开如下界面:
此时无颜色的部分表示是相同的部分,有颜色的部分是不同的部分,此时可以两个人根据实际情况来商量怎样改动代码,不同部分的新增内容是不是都添加进去?相同部分的修改内容应该都要还是按照某一个人的修改内容为标准,可自行商量。
然后,A用户在最新版本上修改后,提交到服务端,重要的是B也要重新更新一下A修改后的版本,然后再进行工作。
当B修改了A更新的内容提交之后,A第二天来更新了代码后,没有发觉哪里被修改了,继续自己的工作,很久之后才发现有部分自己写的东西被修改了,但是这时候版本已经太多了,比对着比较麻烦。
此时可以选择查看历史版本,showlog,选中两个版本,右击—》Compare version,逐个比对版本,根据不同颜色的修改标识来找是在哪一版本修改了,然后找到该作者,问清楚原因就好。