我的版本控制之旅
本帖最后由 TimiZheng 于 2019-9-27 13:34 编辑关于版本控制 什么是“版本控制”？如《pro git》中所述： 版本控制是一种记录一个或若干文件内容变化，以便将来查阅特定版本修订情况的系统。 从上面的定义中不难看出：
版本控制可以只控制一个文件，也可以控制无数个文件；版本控制可以控制一类文件，也可以控制不同类型的文件；版本控制不仅关注当前文件内容，也关注历史版本的修订情况； 物理世界中的许多操作是不可逆的，信息世界则不同。正是因为信息世界的这种特性，使得在信息世界中有诸多的可能性，更容易取得令人满意的效果。但尽管如此，由于信息世界本身的复杂性，它的这种特性往往需要很大的维护成本。而引入了版本控制，则可以大大降低这种维护成本。 我的版本控制之旅 我接触版本控制，有如下几个阶段，与版本控制系统的发展阶段正好符合： 本地版本控制 本地版本控制，主要是指所有版本存在自己的电脑上。这个阶段主要发生在大学时代。比如，写的论文，当完成度很高时，为了取得更好的效果，常常把当前论文复制一份，在副本上进行编辑，于是经过多次编辑后，电脑上的论文文件很可能是这样的： XX论文-完结版.docxXX论文-完结版V1.0.docxXX论文-完结版V2.0.docxXX论文-最终版V1.0.docxXX论文-最终版V2.0.docx 虽然操作起来很简单，但当版本很多时，你并不能确定地知道每个版本之间有什么差异，也意味着你更容易犯错，对某个版本进行误操作。 集中式版本控制 为了解决上述问题，集中式的版本控制系统（Centralized Version Control Systems，简称 CVCS）出现了。这类系统，都有一个单一的集中管理的服务器，保存所有文件的修订版本，人们通过客户端连到这台服务器，取出最新的文件或者提交更新。多年以来，这已成为版本控制系统的标准做法，此类软件有VSS、CVS、Subversion等。 我在工作之后，开始接触版本控制软件，如vss、svn等。 VSS是Microsoft Visual Source Safe的简称，它是微软公司开发的版本控制软件。它主要方式是通过”锁定—修改—解锁—提交”的方式进行版本控制的。当时使用它来管理测试用例、测试分析文档、测试报告等测试文档。 后来逐渐开始使用SVN（全称SubVersion），在当时它是公司所有项目开发人员管理代码和产品经理管理需求文档的工具。 现在看来，使用SVN的年头虽长，但对其的掌握程度并不高。主要原因一是因为并没有深入了解它的原理，二是日常使用多是使用只读权限阅读需求文档，虽然也有少量的编辑需求，但基本是只编辑自己的文件，未与他人产生提交冲突。 分布式版本控制 集中式的版本控制系统的最明显缺点是中央服务器的单点故障（我在之前的公司中还真遭遇过一次中央服务器的单点故障，索性损失不太大），于是分布式版本控制系统（Distributed Version Control System，简称 DVCS）横空出世，如Git、Mercurial、Bazaar 以及 Darcs等。 在分布式版本控制系统中，我接触的是git。从接触git到现在，虽然时间不长，但也经历三个明显的阶段： 傻瓜式使用 第一次接触git，大概是2014年，和以前的同事一起写了些技术文章，放在git上管理。我当时对git毫无概念，也丝毫没有学习它的想法，每次都是按照前同事发来的命令进行操作。 非协作式使用 在上家公司的时候，测试人员编写的代码用git管理，但基本都是自己维护自己写的工具代码，从来不需要解决提交冲突，都是在master分支上直接提交。 协作式使用 现如今，无论是维护测试人员自己编写的代码，还是对研发人员写的代码进行版本控制和环境部署，对git的使用都更加频繁和深入，我也开始系统地学习它。
来源：公众号软件测试技能站；作者：signjing（网校金牌讲师）
页:
[1]
