版本管理_版本管理工具 - CSDN
精华内容
参与话题
  • 版本管理的概念

    千次阅读 2019-04-03 18:02:36
    版本管理的概念 项目在开发的过程中, 经常会出现多人分工协作进行项目分发并开发整合的过程, 所以项目在刚开始流行的时候经常会出现一些协作开发的同步的问题, 同时存在项目整体进度的控制和管理的问题,所以在...

    版本管理的概念
    项目在开发的过程中, 经常会出现多人分工协作进行项目分发并开发整合的过程, 所以项目在刚开始流行的时候经常会出现一些协作开发的同步的问题, 同时存在项目整体进度的控制和管理的问题,所以在程序开发行业衍生出来了版本管理工具
    版本管理工具, 首先是一个内容管理工具, 可以将项目的内容信息存放在版本管理服务器上方便项目组人员进行访问和查询修改。
    在这里插入图片描述

    版本管理具有里程碑意义的主要有三个阶段

    CVS 阶段----->SVN 阶段---->Git 阶段
    CVS 阶段
    项目搭建开发过程中, 每次提交项目都会将整个项目提交到服务器进行保存,服务器存储着项目的 N 个备份, 开发过程中的协作效率较低,同时也出现了各种传输的问题,所以慢慢淡出了行业。
    SVN 阶段
    考虑到 CVS 的缺陷,开发人员根据项目的实际情况,研发出专门针对项目版本控
    制的软件 Subversion(简称 SVN) ,SVN 同样也是搭建服务器,让项目组成员将数据存储在服务器上, 但是每次改动并提交的时候, SVN 服务器并不重新保存整个
    项目的完整信息,而是和原来的项目进行对比,只保存改动的信息。这样就在很大
    的程度上对于项目版本服务器、项目协作效率有了显著的提升。所以至今为止,有很多公司依然选用 SVN 作为公司内部项目协作的版本控制软件。
    Git 阶段
    Git是什么?
    Git是目前世界上最先进的分布式版本控制系统(没有之一)

    前面的 CVS 和SVN 都是基于一个服务器的,如果脱离服务器,项目的版本保存就没有了任何意义,Git 恰恰处理了这样的问题,Git 是一个分布式的版本控制系统,在 Git 中即使用户离线,也能进行项目的提交和更新操作,等到下次连线服务器时进行整体的同步操作。
    SVN的使用

    冲突:合并冲突(自己解决)(merged),没有冲突的三个文件;

    冲突:生成三个文件的冲突

    回滚:log信息回滚 , 版本回滚

    git和SVN的区别

    1.GIT是分布式的,SVN不是

    2.GIT把内容按元数据方式存储,而SVN是按文件

    3.GIT分支和SVN的分支不同

    4.GIT没有一个全局的版本号,而SVN有

    5.GIT的内容完整性要优于SVN

    展开全文
  • 软件研发管理之版本管理

    千次阅读 2014-01-21 19:11:58
    版本管理是软件研发管理中比较容易忽视的一环,这当然是比较好理解的,因为版本管理毕竟和具体业务关系不大。其实,版本管理是很多更高级管理制度的基础,如果版本管理做得糟糕,类似代码审查一类的工作就很难高效...

     

             版本管理是软件研发管理中比较容易忽视的一环,这当然是比较好理解的,因为版本管理毕竟和具体业务关系不大。其实,版本管理是很多更高级管理制度的基础,如果版本管理做得糟糕,类似代码审查一类的工作就很难高效方便的执行。

             下面介绍目前我们研发团队建议实行的版本管理制度,仅供参考。

     

    1 工具软件:SVN 和 Beyondcompare

             SVN是代码备份软件,Beyond compare 是代码对比软件

     

    2 版本日志

             我们要求,每个项目都应当有自己独立的版本日志文件,小的项目或者模块版本日志可以 TXT格式,大的可以用 excel 来保存。

             版本日志顾名思义,就是记录项目版本演进的历史。它应当包含的内容有:序号、版本号、提交时间、作者、新增功能、修复bug列表和依赖模块信息。

             版本日志存放的目录一般是项目根目录的 ./doc 子目录,直接存放到项目根目录也很好。

             序号:每提交一次,序号加一。

             版本号:要求每次提交都采用唯一的版本号标示。版本号一般由数字加字母组成,如 V 1.05a 这个版本号,“1.05 ”描述的是软件功能集合,也就是说,V 1.05b、V 1.05c 的功能和 V 1.05a 完全一致,a、b、c 代表软件修复的bug 在减少。

             提交时间:版本提交SVN的日期。

             作者:提交人。

             新增功能:软件新增加的功能列表,只要软件功能增加,则版本号的数字也应当增加,若某版本没有新增功能,则版本号数字不应当变更。新增功能的描述详尽程度以产品经理或者测试功能师能理解为准,太详细了也没必要,过于简单或者有歧义也不行。

             修复bug列表:如果修复的bug 是测试部门报告的bug,则用 bug编号记录。如果是研发自己发现的 bug,则应当简要描述bug 现象,方便测试工程师验证。

             依赖模块信息:稍微大一点的项目,必然会依赖于大量的独立模块,这些模块可能是第三方开源模块,也可能是公司其他部门或者团队提供的模块,当然,也可以是自己研发的通用功能模块。这些模块名字、版本号必须在版本日志中描述,尤其是这些模块的变更信息,应当明确的进行描述。

             版本日志的注意事项:我们明确的规定,如果既没有新增功能,也没有修复bug,则不允许进行代码提交。在很多团队的研发实践中,常常把 SVN 当做日常研发的代码备份工具,代码稍微写了一点,就马上进行提交,比如在开发某一个功能时需要3天时间,有些工程师会有每天下班提交成果到 SVN 的习惯,这种习惯不能说不好,但是我个人感觉不是最好,我相信过多的冗余信息会把真正有用的信息掩盖,所以,我建议的原则是只把真正有用的信息保存下来,同时要求,所有有用的信息都必须保存下来!对一个软件的开发工作而言,新增功能和修复bug 是我们编写代码的全部目的,因此,我们就只关注这两点,而过程则不在项目SVN中记录。

     

    3 提交内容

             提交内容应当包括:版本日志、相关代码和资源文件等。

             提交的内容应当是完整的、可编译的。这句话的意思是,其他同事在一个新的机器(开发编译环境自己可以安装)上把代码从SVN上Check Out 下来后,可以顺利完成项目的编译。某些项目编译环境有一些特殊的需求,比如要打一些特殊的定制补丁等,对这样的项目,开发人员有义务在 SVN 的 ./doc 目录下进行详尽说明,并完整上传定制补丁在 ./patch 目录下。

             在公司有配置管理员的情况下,建议项目编译生成的 bin 文件(即项目成果,如 exe、DLL 或者 *.so 等)由配置管理员编译生成并提交。在没有配置管理员的情况,对重大项目,我们建议采取交叉编译提交的方式,即开发人员只负责提交自己的代码,然后相互编译其他同事的代码和上传别人的 bin文件。这种管理方式有时候可以提前避免很多非技术性纠纷。

             开发人员在提交代码前,必须对完成的功能和修复的bug 自己做一次冒烟测试,即冒烟测试原则上应当研发人员自己完成。

             对于代码编译过程中产生的一些中间文件,典型的如 *.obj、*.o、*.s 等文件,严禁提交到 SVN。很多工程师提交这些文件的原因主要是对 SVN 不熟。

             另外,需要着重指出的是,提交的代码,应当是和版本日志中描述的新增功能和修复bug 相关的。在实践中,有工程师在编程时会发现以前某些代码文件的版式不漂亮、代码注释太多等等,然后就随手做了一些修改;另外就是在提交代码时,某些正在进行中的功能开发代码也顺便做了提交。就我个人的建议,这不是好的做法,我们应当尽力避免。因为版本日志是版本管理的总纲,版本日志的核心又是新增功能和修复bug两项,这意味着我们提交的代码是围绕着这两个核心进行的。在SVN的提交日志上可以清楚看到每次提交的代码文件名,如果按照规定做的话,这些文件名应当是完整说明了版本日志中对应的功能和修复bug所需要新增或者修改的代码文件,在这里,我不希望出现冗余信息,理由前面说过。

     

    4 提交时间

             我们建议采取以功能点和修复的bug为线索的提交方式,即完成一个功能或者修复一个bug 后就立即提交。

             先把提交版本和发布版本的概念做一个清晰定义。提交版本意即开发工程师完成若干功能或者修复若干bug 后,把代码上传到SVN服务器,而发布版本意即由配置管理员从SVN更新到最新代码,并进行编译和bin提交,然后把bin发布给测试部门。

             我们建议采取的是多次提交对应一次发布的原则,而很多研发团队事实上采取的是一次提交对应一次发布的原则,即在版本发布的截止时间点做一次匆忙的提交活动,这种方式是可能存在一些隐患的。

     

    5 优势

             采用这样的版本管理方法,研发团队是可以获取很多好处,也可以在流程上预先排除一些隐患。当然,自卖自夸不是好习惯,所以这部分我只是简单的说几点,真正的益处,是要大家在实践中去体会的,当然,可能也还有缺点也不完善,这也需要大家在实践中去发现。

             有些工程师出于各种原因,可能没有完整提交代码,对这种现象,我们采取了增加配置管理员编制的方法来解决。

             有些团队一方面提交的代码和最终生成的bin 不一致,另一方面,SVN服务器上的bin 和测试的bin 又可能不一致,对这种现象,配置管理员的设置解决了前者,而通过开放SVN上 ./bin 和 ./doc 两个目录权限给测试部门可以解决后者。

             测试工程师对于发布的版本可以采取增量测试的方法进行测试,减少测试工程师系统测试的次数,这样可以极大的提高测试工程师的工作效率。所谓增量测试,指的是只测试和验证发布版本的新增功能和修复的bug。

             刚发布的版本很快就被测试打回,这个现象的原因很复杂,但是,通过研发人员自己完成冒烟测试可以极大缓解该现象。

             有利于培养研发工程师对待代码的严肃性,为代码规范等一系列规定创造一个比较好的环境。

             现在回归测试更方便和有效了。研发工程师通过回归测试的方式可以更容易的排查bug了。

             有些团队测试平时很空闲,一发布版本就很忙,甚至有可能要搞通宵。现在我们通过多次提交对应一次发布的方法来解决这个问题。测试平时就可以随着研发的进行先把提交的版本测试起来,极大的提高的测试的工作效率,使得测试工程师的工作量安排分布更加均匀。

             最大的好处是,使得团队内部互相 code review 成为可能。Code review 是在研发阶段消灭软件质量最好的方法,也是促进新手程序员成长的最高效方式。在严格的版本管理制度下,每个功能、每个bug 对应修改的代码在SVN上可以简明的看到,这极大的方便了资深工程师对新手代码的审查,同时,也极大的方便了新手程序员向资深工程师的学习。我一向的观点是,软件工程师把一个功能完成算不得什么,如果百分制的话,完成功能最多得30分,我们除了功能,还应当考虑稳定性、可靠性、可扩展性,还有注重代码的可读性和可维护性等等,这些东西新手程序员是很难全面兼顾的,这就需要资深工程师进行现场指导,结合新手工程师自己写的代码进行讲解,这是最快速的优秀程序员培养模式。

    展开全文
  • 软件版本管理

    千次阅读 2019-01-12 16:08:03
    1.PC端产品内部版本管理说明 为了规范产品管理,提高产品质量,特制定产品版本规则。产品从版本上分为主版本和分支版本,从稳定程度上分为每日构建、内部测试版(alpha测试)、Beta测试版、稳定版。 所有的版本...

    修订说明

    1.PC端产品内部版本号管理说明

    为了规范产品管理,提高产品质量,特制定产品版本规则。产品从版本上分为主版本和分支版本,从稳定程度上分为每日构建、内部测试版(alpha测试)、Beta测试版、稳定版。

    所有的版本命名均遵循以下规则,产品名称_分支名称_SVN对应版本号_build年月时分_测试类型[alpha,beta,stable]。如果是主版本可以省略分支名称。如果是每日构建,则不需要后缀测试类型。

    每日构建是为了提高开发测试效率而采取的一种管理手段,开发人员每日定时提交所有修改完成的代码,发布一个仅供内部测试的非里程碑版本。每日构建版本号命名规则:产品名称_分支名称_SVN对应版本号_ build年月日时分。例如gagamatch_403_build201306271602。又如,gagamatch_spring_502_build201306271602。

    内部测试版是指开发提交给测试人员用于内部测试的里程碑版本。该版本仅用于内部测试,不能用于发布。内部测试版版本号规则:产品名称_分支名称_SVN对应版本号_ build年月日时分_alpha。例如gagamatch_403_build201306271602_alpha。又如,gagamatch_spring_502_build201306271602_alpha。

    Beta测试版是指,经过测试人员充分测试,但是可能存在功能不完善或者缺陷的里程碑版本。该版本可对特定用户开放。Beta测试版版本号规则:产品名称_分支名称_SVN对应版本号_ build年月日时分_beta。例如gagamatch_403_build201306271602_beta。又如,gagamatch_spring_502_build201306271602_beta。

    稳定版是指,经过测试人员和用户充分测,用于对所有用户开放的正式发布的里程碑版本。稳定版版本号规则:产品名称_分支名称_SVN对应版本号_ build年月日时分_stable。例如gagamatch_403_build201306271602_stable。又如,gagamatch_ spring_502_build201306271602_stable。

    2. 移动终端产品版本号管理说明

    移动终端产品版本号命名规范为:产品代号_v[大版本号].[小版本号].[里程碑版本号].[编译版本号]。其中,产品代号是指产品的内部代号,正式发布时需要去除此代号。大版本是指全新重构,或者改动巨大的版本,初始值为0,以后每次累加1;小版本是指在一个大版本内,功能发生较大改变或者新增较多功能的版本,初始值为0,以后每次累加1;里程碑版本是指小版本内的持续迭代版本,初始值为0,以后每次累加1;只有测试版本才需要编译版本号,编译版本号的规则为yyddhh;测试结束后需要发布正式版时里程碑版本号需要累加一位。例如,最终的测试版本为rainy_v2.0.1.111909,则发布时的版本应为v2.0.2

    3. PC端产品发布管理

    为了提高产品质量,提高用户体验,提升公司竞争力和形象。技术部所有发布的产品必须全部达到以下标准:

    1. 必须至少提供产品更新文档、产品部署文档、产品审计文档、应急处理方案、测试计划、测试用例、测试报告等。
    2. 申请发布的产品版本必须经过严格的测试且达到了相关的质量标准。
    3. 必须同时通过技术总监、测试经理、QA的审核才能发布。
    4. 运维工程师有权拒绝未经审核或者未完全通过审核的发布申请。 

     

    展开全文
  • 软件版本管理制度

    千次阅读 2019-03-29 11:37:18
    版本管理是软件研发管理中比较容易忽视的一环,这当然是比较好理解的,因为版本管理毕竟和具体业务关系不大。其实,版本管理是很多更高级管理制度的基础,如果版本管理做得糟糕,类似代码审查一类的工作就很难高效...

     版本管理是软件研发管理中比较容易忽视的一环,这当然是比较好理解的,因为版本管理毕竟和具体业务关系不大。其实,版本管理是很多更高级管理制度的基础,如果版本管理做得糟糕,类似代码审查一类的工作就很难高效方便的执行。

     

    1 工具软件:SVN 和 Beyondcompare

             SVN是代码备份软件,Beyond compare 是代码对比软件

     

    2 版本日志

             我们要求,每个项目都应当有自己独立的版本日志文件,小的项目或者模块版本日志可以 TXT格式,大的可以用 excel 来保存。

             版本日志顾名思义,就是记录项目版本演进的历史。它应当包含的内容有:序号、版本号、提交时间、作者、新增功能、修复bug列表和依赖模块信息。

             版本日志存放的目录一般是项目根目录的 ./doc 子目录,直接存放到项目根目录也很好。

             序号:每提交一次,序号加一。

             版本号:要求每次提交都采用唯一的版本号标示。版本号一般由数字加字母组成,如 V 1.05a 这个版本号,“1.05 ”描述的是软件功能集合,也就是说,V 1.05b、V 1.05c 的功能和 V 1.05a 完全一致,a、b、c 代表软件修复的bug 在减少。

             提交时间:版本提交SVN的日期。

             作者:提交人。

             新增功能:软件新增加的功能列表,只要软件功能增加,则版本号的数字也应当增加,若某版本没有新增功能,则版本号数字不应当变更。新增功能的描述详尽程度以产品经理或者测试功能师能理解为准,太详细了也没必要,过于简单或者有歧义也不行。

             修复bug列表:如果修复的bug 是测试部门报告的bug,则用 bug编号记录。如果是研发自己发现的 bug,则应当简要描述bug 现象,方便测试工程师验证。

             依赖模块信息:稍微大一点的项目,必然会依赖于大量的独立模块,这些模块可能是第三方开源模块,也可能是公司其他部门或者团队提供的模块,当然,也可以是自己研发的通用功能模块。这些模块名字、版本号必须在版本日志中描述,尤其是这些模块的变更信息,应当明确的进行描述。

             版本日志的注意事项:我们明确的规定,如果既没有新增功能,也没有修复bug,则不允许进行代码提交。在很多团队的研发实践中,常常把 SVN 当做日常研发的代码备份工具,代码稍微写了一点,就马上进行提交,比如在开发某一个功能时需要3天时间,有些工程师会有每天下班提交成果到 SVN 的习惯,这种习惯不能说不好,但是我个人感觉不是最好,我相信过多的冗余信息会把真正有用的信息掩盖,所以,我建议的原则是只把真正有用的信息保存下来,同时要求,所有有用的信息都必须保存下来!对一个软件的开发工作而言,新增功能和修复bug 是我们编写代码的全部目的,因此,我们就只关注这两点,而过程则不在项目SVN中记录。

     

    3 提交内容

             提交内容应当包括:版本日志、相关代码和资源文件等。

             提交的内容应当是完整的、可编译的。这句话的意思是,其他同事在一个新的机器(开发编译环境自己可以安装)上把代码从SVN上Check Out 下来后,可以顺利完成项目的编译。某些项目编译环境有一些特殊的需求,比如要打一些特殊的定制补丁等,对这样的项目,开发人员有义务在 SVN 的 ./doc 目录下进行详尽说明,并完整上传定制补丁在 ./patch 目录下。

             在公司有配置管理员的情况下,建议项目编译生成的 bin 文件(即项目成果,如 exe、DLL 或者 *.so 等)由配置管理员编译生成并提交。在没有配置管理员的情况,对重大项目,我们建议采取交叉编译提交的方式,即开发人员只负责提交自己的代码,然后相互编译其他同事的代码和上传别人的 bin文件。这种管理方式有时候可以提前避免很多非技术性纠纷。

             开发人员在提交代码前,必须对完成的功能和修复的bug 自己做一次冒烟测试,即冒烟测试原则上应当研发人员自己完成。

             对于代码编译过程中产生的一些中间文件,典型的如 *.obj、*.o、*.s 等文件,严禁提交到 SVN。很多工程师提交这些文件的原因主要是对 SVN 不熟。

             另外,需要着重指出的是,提交的代码,应当是和版本日志中描述的新增功能和修复bug 相关的。在实践中,有工程师在编程时会发现以前某些代码文件的版式不漂亮、代码注释太多等等,然后就随手做了一些修改;另外就是在提交代码时,某些正在进行中的功能开发代码也顺便做了提交。就我个人的建议,这不是好的做法,我们应当尽力避免。因为版本日志是版本管理的总纲,版本日志的核心又是新增功能和修复bug两项,这意味着我们提交的代码是围绕着这两个核心进行的。在SVN的提交日志上可以清楚看到每次提交的代码文件名,如果按照规定做的话,这些文件名应当是完整说明了版本日志中对应的功能和修复bug所需要新增或者修改的代码文件,在这里,我不希望出现冗余信息,理由前面说过。

     

    4 提交时间

             我们建议采取以功能点和修复的bug为线索的提交方式,即完成一个功能或者修复一个bug 后就立即提交。

             先把提交版本和发布版本的概念做一个清晰定义。提交版本意即开发工程师完成若干功能或者修复若干bug 后,把代码上传到SVN服务器,而发布版本意即由配置管理员从SVN更新到最新代码,并进行编译和bin提交,然后把bin发布给测试部门。

             我们建议采取的是多次提交对应一次发布的原则,而很多研发团队事实上采取的是一次提交对应一次发布的原则,即在版本发布的截止时间点做一次匆忙的提交活动,这种方式是可能存在一些隐患的。

     

    5 优势

             采用这样的版本管理方法,研发团队是可以获取很多好处,也可以在流程上预先排除一些隐患。当然,自卖自夸不是好习惯,所以这部分我只是简单的说几点,真正的益处,是要大家在实践中去体会的,当然,可能也还有缺点也不完善,这也需要大家在实践中去发现。

             有些工程师出于各种原因,可能没有完整提交代码,对这种现象,我们采取了增加配置管理员编制的方法来解决。

             有些团队一方面提交的代码和最终生成的bin 不一致,另一方面,SVN服务器上的bin 和测试的bin 又可能不一致,对这种现象,配置管理员的设置解决了前者,而通过开放SVN上 ./bin 和 ./doc 两个目录权限给测试部门可以解决后者。

             测试工程师对于发布的版本可以采取增量测试的方法进行测试,减少测试工程师系统测试的次数,这样可以极大的提高测试工程师的工作效率。所谓增量测试,指的是只测试和验证发布版本的新增功能和修复的bug。

             刚发布的版本很快就被测试打回,这个现象的原因很复杂,但是,通过研发人员自己完成冒烟测试可以极大缓解该现象。

             有利于培养研发工程师对待代码的严肃性,为代码规范等一系列规定创造一个比较好的环境。

             现在回归测试更方便和有效了。研发工程师通过回归测试的方式可以更容易的排查bug了。

             有些团队测试平时很空闲,一发布版本就很忙,甚至有可能要搞通宵。现在我们通过多次提交对应一次发布的方法来解决这个问题。测试平时就可以随着研发的进行先把提交的版本测试起来,极大的提高的测试的工作效率,使得测试工程师的工作量安排分布更加均匀。

             最大的好处是,使得团队内部互相 code review 成为可能。Code review 是在研发阶段消灭软件质量最好的方法,也是促进新手程序员成长的最高效方式。在严格的版本管理制度下,每个功能、每个bug 对应修改的代码在SVN上可以简明的看到,这极大的方便了资深工程师对新手代码的审查,同时,也极大的方便了新手程序员向资深工程师的学习。我一向的观点是,软件工程师把一个功能完成算不得什么,如果百分制的话,完成功能最多得30分,我们除了功能,还应当考虑稳定性、可靠性、可扩展性,还有注重代码的可读性和可维护性等等,这些东西新手程序员是很难全面兼顾的,这就需要资深工程师进行现场指导,结合新手工程师自己写的代码进行讲解,这是最快速的优秀程序员培养模式。

    展开全文
  • 项目版本管理

    千次阅读 2019-03-02 21:00:32
    内部的版本管理可以帮助研发、测试、产品、工程等各部门对产品执行严格的定义,避免出现因版本不一致而造成沟通问题和项目延迟。 版本管理 版本号分为四部分:主版本号.子版本号.修正版本号-SNAPSHOT 主版本号 当...
  • 版本管理

    2018-11-15 17:28:33
    为了方便团队的何做,在项目开发的过程中,大家都应该使用快照版本,Maven能够很智能的处理这种特殊的版本,解析项目各个模块最新的“快照”。快照版本机制促进团队内部的交流。但是当项目需要对外发布时,我们显然...
  • VSS VSS 的全称为 Visual Source Safe 。作为 Microsoft Visual Studio 的一名成员,它主要任务就是负责项目文件的管理,几乎可以适用...VSS作为一款历史悠久的版本管理工具,在早期扛起了版本管理系统方面的大气
  • 1.git版本控制 1.1版本控制 版本控制的英文名称为(Version Control System),主要有以下几个作用。 记录文件的所有历史变化 错误恢复到某个历史版本 多人协作开发编辑同一个文件 1.2主流的版本控制产品 ...
  • 软件版本管理规范

    万次阅读 2016-11-10 15:08:46
    软件版本管理规范版本:1.0 第一章 目的 本规范详细规定软件项目版本管理的对象、存储目录、分支、权限、维护等内容,使软件项目版本管理流程化并规范化,确保在系统开发和实施过程中项目的完整性和一致性。 第二...
  • 软件版本管理规定

    万次阅读 2018-05-30 16:48:31
    3. 职责版本管理员负责统计研发软件的版本信息,管理软件版本号,向软件工程师传达工程及销售人员反馈的软件问题并进行汇总,并在软件升级结束后向生产部集成工程师提供新版本的软件系统。项目负责人及软件工程师...
  • 使用git进行项目版本管理

    万次阅读 2018-01-15 10:47:59
    为了更好地管理目前公司内的源码版本,让大家更好的协同工作,前阵子看了不少关于git版本管理的文章,总结除了一个相对简单的管理规范,并在实践一段时间后,进行了调整。最终版如下: 为规范源代码版本管理,现将...
  • 3、开发者工具-版本管理 4、设置连接信息(有多种连接) 方法一、小程序账号就是对应的tgit账号 一、设置远程连接(设置-远程) 注:名称随便填,url去tgit直接复制(连接有两种格式一种http一种ss...
  • win10(玩FTP时候)想要添加本地用户和组时候碰到的问题: 解决如下: 具体步骤:(1、按住shift键,然后点击开始开始菜单 -- ... ... 3、重启后选择安全模式(4或F4)进入安全模式;...4、进入安全模式后以管理员身...
  • svn分支管理的使用与经验

    万次阅读 2016-07-01 09:50:32
    最近项目用上了svn分支管理,因为项目太过庞杂,版本迭代也过于频繁,致使多个版本的代码交杂在一起,难以维护,无法保证其中某个版本的稳定性。当然,我们也用过很土的办法,代码复制一份出来,但是,这个副本也...
  • 在一个项目上一般会有多个版本,如:1.0、1.1、2.0、3.0。 jira中的系统问题涉及到两个版本字段: 发现版本:如一个bug可能影响1.0和1.1 修复版本:如一个bug影响1.0和1.1,可能在2.0版本...在版本管理界面,图标表示
  • phpstudy多版本php共存,phpstudy无法多版本共存的方案,用了phpstudy很多年,最近测试需要用到多版本共存,默认phpstudy并不支持,只能切换版本,不能多个版本同时运行, 弄了好久都搞不定,在网站参照其他配置也...
  • 常见的版本控制管理工具

    万次阅读 2016-05-23 17:19:20
    常见的版本控制管理工具 出处:http://blog.sina.com.cn/s/blog_5f0e9ca50102v63c.html 配置管理工具是配置管理相关理论的实践载体,工具的功能范围在某种程度上可以直接影响一个组织中配置管理水平的高低...
  • PHPWAMP集成环境Zend组件的相关介绍,站点管理默认已经全部安装Zend解密
  • 应学生要求,我最近更新了PHPWAMP,新版PHPWAMP_IN2添加了强大的Nginx站点管理 纯绿色解压即可使用,默认集成多个mysql和php版本,Apache支持所有运行模式,集成vc运行库,Nginx具有独立服务,可以完美运行,无论...
  • 更广泛的版本管理

    万次阅读 2006-09-11 14:49:00
    原文:MoreVersionControl 写作 2004年12月6日 Bliki 索引译注:“Version Control”一般称为“版本控制”或“版本管理”,这里统一称“版本管理”。作为版本管理工具的重度用户,我觉得它们在计算机中可以用得更...
1 2 3 4 5 ... 20
收藏数 1,757,005
精华内容 702,802
关键字:

版本管理