精华内容
参与话题
问答
  • 版本管理的概念

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

     

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

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

     

    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-09 18:02:36
    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-02 20:59:04
    内部的版本管理可以帮助研发、测试、产品、工程等各部门对产品执行严格的定义,避免出现因版本不一致而造成沟通问题和项目延迟。 版本管理 版本号分为四部分:主版本号.子版本号.修正版本号-SNAPSHOT 主版本号 当...

    概述

    版本号是一个产品的表示,在一个产品的生命周期中具有唯一性。内部的版本管理可以帮助研发、测试、产品、工程等各部门对产品执行严格的定义,避免出现因版本不一致而造成沟通问题和项目延迟。

    版本管理

    版本号分为四部分:主版本号.子版本号.修正版本号-SNAPSHOT

    • 主版本号
      当项目在进行了重大修改或局部修正累积较多,而导致项目整体发生全局变化时,主版本号加 1
    • 子版本号
      当项目在原有的基础上增加了部分功能时,主版本号不变,子版本号加 1,后面的版本号复位为 0,因而可以被忽略掉
    • 修正版本号
      当项目在进行了局部修改或 bug 修正时,主版本号和子版本号都不变,修正版本号加 1

    ** 当对外发布时去掉-SNAPSHOT

    当数据库发生变更时,所有相关系统都需要进行子版本号的增加操作

    所有项目的子模块采用相同的版本号

    例如:目前版本命名V1.0.0,计划发布一个测试版本,修改了部分bug,发布的测试版本则为V1.0.1.0,如果提交的版本仍然有bug需要修改,则下次提交版本V1.0.1.1,直至改测试版本提交测试通过后,发布正式版本V1.0.1,发布时去除-SNAPSHOT并保证他的所有依赖版本都是realease版。

    涉及到数据库修改的版本,在发布时需要发布相同版本号的数据库升级sql文件

    相关插件工具

    批量修改父级项目版本vv

    每次修改父级项目后 所有子模块项目的依赖父级项目版本号也要做修改,修改地方过多容易出错,所以使用插件进行处理
    在父项目中增加插件

    <build>
            <plugins>
                <plugin>
                    <groupId>org.codehaus.mojo</groupId>
                    <artifactId>versions-maven-plugin</artifactId>
                    <version>2.3</version>
                    <configuration>
                        <generateBackupPoms>false</generateBackupPoms>
                    </configuration>
                </plugin>
            </plugins>
        </build>
    

    每次修改父项目版本号之后执行下面的命令,子模块的依赖父项目版本号也会同步修改

    mvn -N versions:update-child-modules
    
    • 使用maven内置属性来处理子项目间的依赖关系
      maven有一个内置属性${project.version}表示的是项目的版本号,当一个子模块依赖其他子模块时我们可以这样写:
        <parent>
    		<groupId>parent-groupId</groupId>
    		<artifactId>parent-artifactId</artifactId>
    		<version>1.0.0</version>
    		<relativePath>..</relativePath>
    	</parent>
    	<artifactId>module-artifactId</artifactId>
    	<dependency>
    		<artifactId>other-module-artifactId</artifactId>
    		<groupId>other-module-groupId</groupId>
    		<version>${project.version}</version>
    	</dependency>
    

    发布版本

    每次发布版本都要做很多操作
    修改版本号为正式版本
    增加Git标签 tag
    打包项目
    deploy到maven
    修改版本号到最新的snapshot版本

    为了简化操作 我们使用maven-release-plugin来完成上面的操作
    maven-release-plugin完成的工作有以下几点

    • 生成release.properties文件
    • 检查本地项目代码中是否有未提交的修改
    • 检查依赖中是否有snapshot版本的依赖
    • 更新POM,将项目的version从*-SNAPSHOT改为用户输入的发布版本
    • 新建tag并提交
    • 部署项目到资源库
    • 修改pom文件到最新的snapshot版本

    首先我们要在setting.xml中 增加公司的资源库镜像和阿里云的仓库镜像

        <mirror>
            <id>alimaven</id>
    		<name>aliyun maven</name>
    		<url>http://maven.aliyun.com/nexus/content/groups/public/</url>
    		<mirrorOf>central</mirrorOf>
       	</mirror>
      
        <mirror>
            <id>vionmaven</id>
            <name>vion maven</name>
            <url>http://ip:port/nexus/content/groups/public/</url>
            <mirrorOf>central</mirrorOf>
        </mirror>
    

    从上面的功能中我们发现,他需要链接我们的git版本库,这块的操作使用scm标签进行配置

     <scm>
        <developerConnection>scm:git:http://ip/project</developerConnection>
      </scm>
    

    还需要配置maven部署仓库的地址

    <distributionManagement>
            <repository>
                <id>vionmaven</id>
                <name>vion maven</name>
                <url>http://ip:port/nexus/content/repositories/releases/</url>
            </repository>
            <snapshotRepository>
                <id>vionmaven</id>
                <name>vion maven</name>
                <url>http://ip:port/nexus/content/repositories/snapshots/</url>
            </snapshotRepository>
        </distributionManagement>
    

    maven仓库部署是需要配置用户信息的,否则用户是无权部署jar包到maven库的
    由于隐私的要求,用户名密码是无法在项目的pom中配置 只能在 maven的setting.xml中配置

        <server>
            <id>vionmaven</id>
            <username>deployment</username>
            <password>authpass</password>
        </server>
    

    最重要的是要增加release插件的配置 在项目pom中加入以下配置

        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-release-plugin</artifactId>
            <version>2.5.3</version>
            <configuration>
                <tagNameFormat>V@{project.version}</tagNameFormat>
                <autoVersionSubmodules>true</autoVersionSubmodules>
                <username>username</username>
                <password>password</password>
                <branchName>develop</branchName>
                <tagBase>http://ip/project/tags</tagBase>
            </configuration>
        </plugin>
    

    自此,所有release插件的配置均已完成,下面开始使用,主要有以下四个命令

    mvn release:clean 清理插件生成的文件等信息
    mvn release:prepare 准备命令 为生成工作进行准备
    mvn release:perform 实施命令 进行版本发布
    mvn release:rollback 回退命令  回退本次操作
    

    一般来说发布版本只需要 先运行 mvn release:prepare 成功后再运行release:perform就可以了

    展开全文
  • 版本管理规范

    2018-12-25 18:07:47
    统一的版本号表示规则,遵循 Semantic Versioning(语义化版本)规范: (中文版 http://semver.org/lang/zh-CN/)   二、 并且将下面规则的作为补充:   以一个完整的版本号为例:1.3.6-beta-11 其中,&...
  • 软件版本管理制度

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

    2018-11-15 16:44:17
    为了方便团队的何做,在项目开发的过程中,大家都应该使用快照版本,Maven能够很智能的处理这种特殊的版本,解析项目各个模块最新的“快照”。快照版本机制促进团队内部的交流。但是当项目需要对外发布时,我们显然...
  • 软件版本管理

    2018-05-03 15:32:17
    软件版本号的命名规范
  • 版本管理原则和规范

    2019-09-11 15:38:28
    1. 版本阶段说明 1.1 测试版本 广义上对测试有三个传统的称呼:Alpha、Beta、Gamma,用来标识测试的阶段和范围。 1.1.1 Base版 此版本不属于测试版本。它表示该项目仅仅是一个假页面链接,通常包括所有的功能...
  • VSS VSS 的全称为 Visual Source Safe 。作为 Microsoft Visual Studio 的一名成员,它主要任务就是负责项目文件的管理,几乎可以适用...VSS作为一款历史悠久的版本管理工具,在早期扛起了版本管理系统方面的大气
  • 1.git版本控制 1.1版本控制 版本控制的英文名称为(Version Control System),主要有以下几个作用。 记录文件的所有历史变化 错误恢复到某个历史版本 多人协作开发编辑同一个文件 1.2主流的版本控制产品 ...
  • 软件版本管理规范

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

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

    万次阅读 多人点赞 2012-05-02 14:08:11
    Git 是一个分布式版本控制工具,它的作者 Linus Torvalds 是这样给我们介绍 Git —— The stupid content tracker(傻瓜式的内容跟踪器)1、 Git 背景Git 最初由Linus Torvalds编写,用于 Linux 内核开发的版本...
  • 对于项目版本管理,你是否存在这样的痛点:项目分支多而杂不好管理,git log界面commit信息错乱复杂无规范,版本回退不知道选择什么版本合适……。项目版本管理的最佳实践系列,笔者将以两篇文章的形式展开介绍(即...
  • 配置库管理及版本管理规范

    千次阅读 2019-01-08 19:50:56
    配置库管理及版本管理规范               版本信息 A代表新增,M代表修改,D代表删除。 版本号 发布日期 提交人 A.M.D 摘要 V...
  • Git本地版本管理

    千次阅读 2018-07-05 23:58:19
    这种系统下,客户端不只是简单地拉取某个版本的文件,而是把整个记录文件版本的数据库(即整个代码仓库)都克隆到本地系统上。这样以来,任何一处协同工作用的服务器发生故障,事后都可以用任何一个镜像出来的本地...
  • Git版本管理工具使用详细介绍

    万次阅读 2019-05-16 17:17:51
    一、引言 跟你们吐槽一下,最近小编的工作制度也改成996,怎么说? 是好是坏呢? 网上很多小伙伴也在吐槽,刚开始小编也是挺反感的,毕竟之前周末一些坚持的习惯,因此都需要改变。 既然公司选择了996,我们也就...
  • 【项目管理工具】SVN 项目版本管理工具

    万次阅读 多人点赞 2018-08-02 18:05:40
    1. svn介绍 1.1 项目管理中的版本控制问题 解决代码冲突困难 容易引发bug 难于恢复至以前正确版本 无法进行权限控制 项目版本发布困难 1.2 什么是版本控制 ...SVN是版本管理工具,在当前的开源项目里(J2...
  • 使用Git连接到GitHub并进行版本管理

    千次阅读 2018-05-19 13:53:57
    Git是一个开源的分布式版本控制系统,可以有效、高速的处理从很小到非常大的项目版本管理。而GitHub则是一个面向开源及私有软件项目的托管平台,或者说它是一个在线的项目版本管理系统,它为基于git的版本控制和项目...

空空如也

1 2 3 4 5 ... 20
收藏数 1,792,401
精华内容 716,960
关键字:

版本管理