精华内容
下载资源
问答
  • 项目版本管理的最佳实践:gitflow基础篇

    千次阅读 多人点赞 2020-10-13 22:53:56
    对于项目版本管理,你是否存在这样的痛点:项目分支多而杂不好管理,git log界面commit信息错乱复杂无规范,版本回退不知道选择什么版本合适……。项目版本管理的最佳实践系列,笔者将以两篇文章的形式展开介绍(即...

    对于项目版本管理,你是否存在这样的痛点:项目分支多而杂不好管理,git log界面commit信息错乱复杂无规范,版本回退不知道选择什么版本合适……。

    项目版本管理的最佳实践系列,笔者将以两篇文章的形式展开介绍(即基础篇与进阶篇)。本文为gitflow版本管理的最佳实践-基础篇。基础篇主要介绍git应用于生产的基本流程与怎么使用gitflow管理你的项目版本线(适用于敏捷迭代的项目管理场景下)。进阶篇 将着重介绍gitflow+jenkins+docker+DevOps+敏捷Scrum 完成项目持续构建与持续交付(CI/CD)。阅读本文需要有一定git基础,基础知识则不在本文展开,善用网上冲浪工具便可学习到许多Git的基础知识。实际上,本文介绍的并不是纯粹的gitflow,而是结合实际生产对gitflow的改造与最佳实践。

    导航

    项目版本管理的最佳实践:飞流Flow(阿里AoneFlow)篇

    项目版本管理的最佳实践:gitflow基础篇​​​​​​​

    目录

     一、分支规约

     二、版本号规约 

     三、Gitflow的最佳实践 (基础篇)

    3.1 总体流程图

    3.2 弓行同学与阿康同学的最佳实践

    3.2.1 远程主干分支创建

    3.2.2 本地分支创建

    3.2.3 创建PR

    3.2.4 合并冲突提交版本

    3.2.5 测试环境版本发布

    3.2.6 版本标记

    3.2.7 热修复

    3.2.8 生产发布

    四、 双周迭代制与gitflow

    4.1 敏捷的双周迭代制

    4.2 双周迭代结合gitflow的最佳实践

    五、FAQ


    Git的基本术语与简写

     
    术语解释
    PR即pull request,拉取请求。请求git代码管理员将你的代码合并到仓库的分支中。一般的PR由标题部分,描述部分与代码部分组成。
    code review在PR过程中代码管理员对你提交的代码进行代码审查,即你的代码是否符合规范、是否存在风格问题、安全问题等,对你代码进行cr的同学并不一定是代码管理员,成熟的敏捷团队,每一个成员都是code owner,都可以对pr进行审阅。
    squashPR过程中,会将你的所有commit合并(榨取)成一个commit并提交到目标分支中,目的是减少冗余提交、规范主分支提交信息(实际上是rebase的一种操作)。
    LGTMlook good to me(看起来很吊),一般存在于PR评论中,即对pr的内容没有问题,同意合并到版本库。

    一、分支规约

    在我们的最佳实践中,远程版本库永远只存在三条长期且相互独立的分支,他们分别为developreleasemaster,三条分支对应三个环境,分别为开发环境(集成开发环境)、测试环境(预发环境)与生产环境,三个分支分别都上权限,不可直接对其进行pushcommit操作,即所有的修改均通过PR进行,以保证分支对应环境的安全与稳定。本地环境对应的远程分支均会在PR通过之后,自动进行删除,以保证版本线的简单。

    环境分支名
    开发环境origin/develop
    测试环境(预发环境)origin/release
    生产环境origin/master
    本地环境功能分支develop_xxx (xxx为具体的开发成员或具体的功能描述, origin/develop_xxx,即feature分支下沉到本地,生命周期短,只存在于pr过程)。

     二、版本号规约 

    在正式介绍gitflow之前,我们需要对版本号进行规范,方便接下来的行文展开。

    在生产中,我们常用的版本号为三位数版本号(偶尔带四位热修复号),其构成如下:

    V主版本号.次版本号.功能号(.${热修复版本号}).环境
    

    eg:V1.0.0.1.RELEASE、V1.1.0.DEVELOP、V1.0.0。(版本号并不以十进制,而是按照迭代规划推送)

    2.1 主版本号(首位版本号)

    主版本号,也叫首位版本号、顶位版本号,即V后第一个版本号。主版本号一般代表项目的期数与产品方向。除非项目合同改变、大规模api不兼容、产品方向改变、底层架构升级等情况外不轻易更新。

    另外,项目未正式发布、未正式孵化、未正式上线,则首位版本号为0,一期发布,则为V1。

    2.2 次版本号(迭代号)

    次版本号,也叫迭代号,一般代表某个迭代发布的功能集合(一个迭代发布会包含若干个功能更新)。

    如V1.1.0:第一期项目第一迭代发布版本、V1.2.0:第一期第二迭代发布版本。

    2.3 功能号(PR号)

    一般来说,提交到项目分支内的代码均需要经过PR,而为了保证单个PR的简洁性与纯粹性,建议一个PR描述一个功能。因此第三位数的版本号也叫做PR号或功能号,用来描述单个提交到主分支内的功能或代码修改。

    如V0.0.1:第一迭代的第一个提交、V0.0.98:第一迭代的第98个PR。

    2.4 热修复号

    四位数版本号是可选版本号,为热修复版本号(也叫老爷保号hh),常规迭代与develop分支下并不会出现,而常出现在测试环境对应的release分支与生产环境对应的master分支(develop分支对应的开发环境出现bug直接提交pr修复并在原来的版本号上+1便可)。这个版本号常用于线上热修复,测试环境(预发环境)的热修复。

    值得注意的是,四位数版本号经过线上热修复之后,要同步到本地develop环境的情况下,应当在develop分支下的三位数版本号上加一。

    如:master的热修复号为V1.0.0.4,develop分支当前版本为V1.1.8.DEVELOP,那么这个修复要同步回develop分支保证bug不重现,那么在develop上面的版本则为V1.1.9.DEVELOP

    2.5 环境号

    因为在git中的tag名称是唯一的,那么在develop分支下出现了V1.0.0的tag,那么在release和master下便不可以再打一个tag叫V1.0.0。因此出现环境号来对分支版本进行区分(生产环境不加环境号)。

    环境环境名版本号(示例)
    开发环境DEVELOPV1.0.0.DEVELOP
    测试环境(预发环境)RELEASEV1.0.0.RELEASE
    生产环境MASTERV1.0.0

    三、Gitflow的最佳实践 (基础篇)

    3.1 总体流程图

    3.2 弓行同学与阿康同学的最佳实践

    这里要搬出两位同学进行接下来的讲解,他们是【弓行】同学与【阿康】同学。

    3.2.1 远程主干分支创建

    版本的最开始(指V0.0.0),代码管理员会初始化远程仓库,并基于master的初始版本创建三条分支,他们是

    origin/master(对应生产),origin/release(对应测试环境),origin/develop(对应开发环境) 并为这三条分支设置保护策略,三条分支均不允许直接的commit与push修改。

    代码管理员将三个初始版本打上相应的TAG:(V0.0.0.DEVELOP、V0.0.0.RELEASE与V0.0.0)

    3.2.2 本地分支创建

    完成迭代计划会议(迭代版本号为V0.1.0)之后,弓行与阿康他们分别认领了两个任务:【开发功能】弓行,【开发功能2】阿康。

    此时,弓行与阿康会将远程仓库克隆下来,并基于origin/develop 创建本地develop_gx分支与develop_kang分支。

     

    3.2.3 创建PR

    两人认领任务后进行同步开发,一段时间后,弓行率先完成【开发功能1】的工作,因此他需要将当前开发版本提交到开发环境中进行自测与前后端联调。但此时【origin/develop】是被保护的状态无法被直接提交。因此,弓行需要对当前的开发的版本进行PR申请,即创建拉取请求,请求代码管理员对代码进行code review,通过后进行合并。

    此处涉及的步骤大致如下:

    1、push当前本地分支到origin,得到origin/develop_gx。

    2、创建PR:即:origin/develop_gx 合并到 origin/develop 的拉取请求

    3、等待代码管理员(或小组内同学)进行code review,若需要修改,则直接在pr中提出注释,作者修改后直接push到远程分支中,继续等待代码管理员进行code review。

    4、通过后,将当前commit list以squash的形式合并到origin/develop中,得到V0.0.1.DEVELOP 的commit

    5、最后选择删除origin/develop_gx的远程分支

    此时,弓行同学完成了第一个功能的开发,并在【origin/develop】分支上对自己的pr commit 进行tag操作:将此commit记录为【V0.0.1.DEVELOP】

    3.2.4 合并冲突提交版本

    不久后,阿康同学也完成了【开发功能2】的开发,他也需要将代码提交到origin/develop分支进行测试与联调。但此时,origin/develop已经与他的基版本不一样了(基版本为V0.0.0.DEVELOP,远程版本为V0.0.1.DEVELOP,领先一个版本)如果直接创建PR,可能因为代码冲突的问题无法完成版本合并,如下图。

    此时阿康需要将origin/develop版本拉取到本地,并执行以下操作(推荐直接使用ide自带的git工具,会方便不少)

    //检查远程仓库是否有新版本
    git fetch origin
    
    //发现新版本,需要拉取到本地解决冲突后进行代码合并
    //暂存本地修改
    git stash save “stash changes”
    
    //拉取远程版本
    git pull origin/develop
    
    //取出本地修改
    git stash apply
    
    //手工解决冲突(推荐直接使用idea)
    
    //提交修改
    git commit -m'1、解决冲突合并版本'

    使用ide自带的冲突解决工具则如下图

    提交修改后(注意一定要和冲突代码的作者商量代码的变更),便可以创建PR,等待团队内同学进行code review。团队成员通过之后,阿康的修改便可以成功被合并到origin/develop中进行联调与测试了。阿康此时需要将改commit打上tag【V0.0.2.DEVELOP】,如下图。

    至此,V0.1.0所规划的开发工作全部完成。

    3.2.5 测试环境版本发布

    完成V0.1.0版本开发工作后,弓行同学认领了一个新任务:【V0.1.0版本提测】。正在其他进行其他功能开发工作的弓行同学此时需要将本地代码stash起来,并将origin/develop分支的代码与本地代码进行合并(即git pull origin develop操作),并进行代码冲突的解决工作。

    因为要将代码发布到origin/release分支进行版本提测,所以弓行同学需要同时将origin/release上的代码与本地代码进行合并操作(即git pull origin release操作) 并进行代码冲突的解决工作。

    完成git pull origin develop 与git pull origin release 之后,本地会形成一个新的commit版本。弓行同学需要将此commit版本通过pr的方式合并到 origin/release 上,方可完成release分支的测试版本发布工作。因此弓行同学需要重复 3.2.3 步骤的PR创建过程,并通过release分支的分支管理员审批后,方可将版本发布到测试环境。

    3.2.6 版本标记

    将commit通过pr的形式提交到release后,接下来就是对版本进行标记的过程,因为此release已经完成了版本的开发工作,因此,当前版本在release分支上会被标记为【V0.1.0.RELEASE】。又因为在develop分支上,V0.0.2.DEVELOP版本对应着release的V0.1.0.RELEASE版本,针对origin/develop的分支上的该commit,会被打上第二个tag:【V0.1.0.DEVELOP】。

    而后,对于develop分支的tag处理,将会直接从V0.1.0.DEVELOP继续往下走(如V0.1.1.DEVELOP等)

    3.2.7 热修复

    origin/release分支对应着测试环境,对于某些情况而言,测试环境相当于项目的beta版本,有可能直接面对客户。

    那么版本提测之后,测试同学针对该【V0.1.0.RELEASE】版本进行各种测试后发现当前版本存在BUG,那么开发的同学就要针对改bug进行热修复。

    假设现在在测试环境出现一个BUG,该BUG的修复工作依旧由弓行同学认领解决,那么此时弓行同学就需要将手头上的开发工作暂停(git stash),然后拉取最新版本的origin/release分支到本地,然后进行bug修复工作。完成修复后,提交本地代码到 origin/release_hotfix_gx 分支,对该分支进行PR操作,由release管理员进行code review并合并到release中,并将该修复版本记录为【V.0.1.0.1.RELEASE】。

    当然了,因为分支commit存在映射关系,出现在V0.1.0.RELEASE上的BUG,也一定会出现在V0.1.0.DEVELOP。那么此时修复了测试环境的版本仍不够,弓行需要将该修复合并到origin/develop上。因此弓行同学需要将新发的版本【V0.1.0.1.RELEASE】拉取到本地,然后对origin/develop进行版本提交工作,形成【V.0.1.1.DEVELOP】

    至此完成热修复的过程(master的热修复也是同理,不过是将修复版本根据实际情况合并到release和develop上的不同罢了)。

    3.2.8 生产发布

    完成release版本的提测工作、BUG修复工作后,弓行同学需要将release分支的版本发布到master上,完成生产环境版本的发布,实际上这个过程也与 3.2.5 并无太大差异。同学们可以结合自己实际情况,在这一步增加团队code review、checklist检查,发布风险控制等操作,对生产发布进行安全保障。

    在完成origin/master的发布工作后,将master的tag更新到 V0.1.0 便完成了整个迭代的发布工作。


    细心的同学读到这里可能已经发现了,origin/develop、origin/release、origin/master 这三条分支在整个过程中都互相独立,互不影响,因此本工作流程属于三独立分支模式的gitflow,同学们若为减少流程,release分支可优化掉,直接在develop分支上进行测试,(也符合测试驱动开发)

    四、 双周迭代制与gitflow

    4.1 敏捷的双周迭代制

    试想一个场景:产品没多少时间规划特性;项目草草规划冲刺backlog;开发在迭代最后一天完成开发工作,测试只有最后2小时进行测试;上线后一堆BUG便令人十分抓狂,因此双周迭代制应运而生。

    以下图为例,一个敏捷团队中有三种垂直的职能角色(暂不考虑产品):开发、测试、与项目(Scrum master),我们假定当前迭代为N,下个迭代为N+1,上个迭代为N-1

    双周迭代制,即一个冲刺迭代设置为两周(或若干周),在这两周中的第一周,这几位垂直职能角色可以如下分工:

    • 开发:进行N迭代 (当前迭代) 的开发与N-1版本 (上个版本) 的hotfix工作,并在每周五进行统一提测;
    • 测试:进行N迭代 (当前迭代) 的develop环境测试与N-1迭代 (上个迭代) 的 release 环境测试,在每周五前完成N-1版本的测试工作;
    • 项目:进行N+1 (下个迭代) 的迭代规划工作与上两个迭代(N-2)的迭代发布工作

    如此一来,N-1版本,N版本,N+1版本便可实现交错进行,有条不紊(需求源源不断地来hhh)当然了,迭代开发时间与测试时间可以适当变动(如 开发:测试 = 6:4 或7:3)。

    采用双周迭代的好处在于:

    • 开发同学有充足和弹性的时间进行迭代的开发工作与bug修复工作与需求理解
    • 测试同学有充足的时间进行测试工作以保证项目质量 (在develop环境上一个功能测一个功能,并在release环境可以完成充分的功能测试)
    • 项目有更多时间去规划项目的迭代与分解具体需求做更完善的设计(疯狂规划迭代)。

    4.2 双周迭代结合gitflow的最佳实践

    基于双周迭代制的gitflow版本管理,即在迭代中:

    • 开发在origin/develop上进行开发,进行 3.2.4步骤的开发工作,与上个release版本的hotfix工作;
    • 测试紧跟开发进行develop分支的测试与上个release版本的测试;
    • 第一周结束,统一发版本到origin/release,测试在第二周开始当前版本release环境的功能测试;
    • 第三周的周一,项目进行版本发版工作(即发布到origin/master)

    五、FAQ

    Q1 : 微服务架构下,每个项目独立一个版本库怎么做到版本号统一,是每个微服务单独编制版本号还是全局统一版本号?

    A1 : 对于微服务架构下(或者分布式架构项目)的每个微服务独立版本库的情况,建议全局编制版本号,即同一个发布窗口,对所有的目标发布分支与的二位数版本号进行编制(即全局统一迭代号或者产品号)。对于没有更新的微服务,可直接在原release的commit上进行Tag发布。

    Q2 : 三分支版本线相对独立,对于版本合并比较痛苦。

    A2 : 这个问题是切实存在的,建议固定发布人,在本地分支保留release分支、master分支与develop分支的合并记录,防止冲突过多。

    Q3 : 对于目标发布的功能,若功能在发布前存在风险,则无法下有风险的分支。

    A3 :  问题切实存在,可以配合开关配置与双周迭代做发布。

    Q4 : 项目处于快速开发阶段,大家一直往develop分支上面提PR,但是没有人做code review。

    A4 : 可以尝试PR标题带上tag信息作为commit title,即:V0.0.1 xxx功能开发 V0.0.2 XXX功能开发,这样一来,就相当于做了资源锁,大家都想往develop上面提pr,但是上一个人把三位数版本号占用了,那么就需要有人把这个pr处理掉,自己才能使用下一个版本号,直到团队code review习惯成熟,如下图(develop的版本线是不是很清晰)。

    Q5 : 允许origin/develop、origin/release与origin/master三条分支之间互相合并吗?

    A5 : 不允许,只能通过PR形式进行分支版本合并

    Q6 : 使用此种gitflow后,三个分支的版本线会是什么样子的?

    A6 : 如下图,无论是develop分支还是release分支与master分支,分支永远只有一条直线,不会有分支之间进行合并的情况,所以显得版本线十分干净整洁。

    Q7 : 好像整个过程都没有看到feature分支 

    A7 : 是的,在此种版本管理中,feature分支其实已经下沉到了每个人的本地版本库中,不直接在origin库中体现。

    Q8 : 远程feature分支可以不删除吗?

    A8 : 为了保证git log干净,建议个人分支合并到develop分支后便执行删除,但不删除远程个人分支也是可以的,可以尝试完成develop的pr后使用同一个个人分支合并到release_${version}中,然后执行release_${version}->release的PR完成release的发布。

     

    以上便是项目版本管理的最佳实践:gitflow基础篇的所有内容,欢迎在评论区讨论与提出改进意见!

    展开全文
  • 配置库管理及版本管理规范

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

     

     

     

     

     

     

     

    配置库管理及版本管理规范

     

     

     

     

     

     

     

    版本信息                                       A代表新增,M代表修改,D代表删除。

    版本号

    发布日期

    提交人

    A.M.D

    摘要

    V1.0

    2019/1/8

    杨彬彬

    A

    初稿

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

    配置库管理及版本管理规范 1

    1. 前言 4

    1.1. 目的 4

    1.2. 配置库代码管理工具 4

    1.3. 角色和职责 6

    2. 配置仓库管理 7

    2.1. 配置仓库说明 7

    2.2. 配置仓库管理规范 8

    2.3. 配置仓库权限管理 9

    2.4. 灾备策略 12

    2.5. 灾备还原 12

    3. 分支管理规范 12

    3.1. 分支工作流程图 13

    3.2. 分支职责 13

    3.3. 创建分支规范 14

    3.4. 分支命名规范 15

    4. 代码管理规范 15

    4.1. 提交代码规范 15

    5. 版本管理规范 17

    5.1. 目的 17

    5.2. 项目版本管理 18

    5.3. 软件产品包版本管理 18

    5.4. 出包步骤 19

     

    1. 前言 
      1. 目的
    1. 规范项目代码管理流程,明确开发人员和项目管理者的职责。
    2. 规范代码库分支管理和版本管理,使代码分支及版本结构清晰,方便维护。
      1. 配置库代码管理工具 
        1. Git介绍

    使用GitLab作为代码管理工具,GitLab 是一个用于仓库管理系统的开源项目,使用Git作为代码管理工具,并在此基础上搭建起来的web服务。

    Git是一个开源的分布式版本控制系统,用以有效、高速的处理从很小到非常大的项目版本管理。可以实现数据备份、记录历史、回到过去、多端共享、分工合作。

        1. Git分层结构

     

    git的工作总共分四层,其中三层是在本地,包括了工作目录,暂存区和本地仓库。

    工作目录

    执行命令git init时所在的地方,也是执行一切文件操作的地方。

    暂存区:

     在.git文件夹目录中,在工作区和版本库中间起缓存作用的一个区域。它通过git add命令添加进暂存区。存储了一些即将被commit的文件。

    本地仓库

    在.git文件夹目录中,使用了git commit命令之后添加进的真正的“仓库”。里面存储了每次commit的记录,每次commit一次会让HEAD指针指向新的目录树,而旧的目录就存在版本库中,可以使用命令来提出之前的目录树。

    git所存储的都是一系列的文件快照,然后git来跟踪这些文件快照,发现哪个文件快照有变化它就会提示你需要添加到暂存区或是提交到本地仓库来保证你的工作目录是干净的。

    进入工作区.git文件夹,如下.git目录或文件结构说明:

    目录或文件

    说明

    config文件

    项目的配置文件,里面有中心服务器的信息和分支信息。

    HEAD文件

    指向当前的分支。

    index文件

    暂存区的相关信息。

    logs目录

    相关操作产生的日志。

    objects目录

    存储的就是所有的数据,也就是快照。 存放的是实际上的文件资源,每次当使用了git add命令之后,就已经把文件存到了objects目录里面。objects目录中的object对象都有一个通过哈希算法计算出来的40位16进制的id,前两位是目录名,后38位是文件名。因为哈希算法可以只比较哈希值,就能知道这两个对象是不是一样的,这样可以提高效率。    

    refs目录

    存储指向数据提交对象的指针。

        1. 工作流程

      1. 角色和职责

    角色名称

    职责

     配置管理员

    1. 管理配置服务器,维护代码仓库、安全设置,定期备份代码仓库。
    2. 负责为项目提供全面的配置管理基础设施和环境。包括代码仓库建立、人员添加等工作。
    3. 编写和维护配置管理的相关文档,包括服务器配置管理方法、配置工具使用方法等。
    4. 编写培训材料,制定培训计划,对开发人员和项目管理人员进行配置管理工具使用培训。
    5. 负责构建release发布版本。并解决或指导开发人员解决合并冲突。
    6. 负责解决在使用配置管理工具过程中遇到的问题。

      开发负责人

    1. 管理源代码,构建代码框架,导入配置服务器。
    2. 在配置管理员协助下对源代码进行管理。
    3. 负责同意master分支的合并请求。
    4. 根据项目进展制定开发基线,管理版本编号以及分支版本,必要的时候,负责版本的合并。

      开发人员

    1. 从服务器克隆项目,按照分配的任务,进行分工协同开发。
    2. 从服务器获取代码库最新变更,在自己负责的模块中加入、修改或删除文件。
    3. 及时提交代码到开发分支并附加变更说明。
    4. 负责构建SIT环境版本。

    测试负责人

    1. 制定测试计划
    2. 确认条件不允许时的例外放行。
    3. 跟踪并报告测试工作的进展,发布后撰写测试总结报告,对测试遗漏的问题进行分析。

    测试人员

    1. 编写测试计划、规划详细的测试方案、编写测试用例
    2. 根据测试计划搭建和维护测试环境
    3. 执行测试工作,提交测试报告。包括编写用于测试的自动测试脚本,完整地记录测试结果,编写完整的测试报告等相关的技术文档。
    4. 对测试中发现的问题进行详细分析和准确定位,与开发人员讨论缺陷解决方案。
    5. 提出对产品的进一步改进的建议,并评估改进方案是否合理;对测试结果进行总结与统计分析,对测试进行跟踪,并提出反馈意见。

     

     

    1. 配置仓库管理
      1. 配置仓库说明

         配置管理员负责建立配置仓库,以便管理源代码、相关文件及资料。每个开发人员在本地都有自己的版本库,在服务器上有一个公共的版本库。

      1. 配置仓库管理规范

    根据配置管理的不同角色所分配的不同职责范围,对本地库和版本库进行管理和操作。

        1. 远程仓库管理
    1. 配置管理员:创建远程仓库、人员添加、权限分配、打标签、构建版本等工作。
    2. 开发负责人:导入该项目到远程仓库并完成分支的创建和设置。
        1. 本地仓库管理

    本地库由开发人员和开发负责人负责日常的更新和开发工作。

    1.  克隆远程仓库,搭建开发环境

    开发人员根据配置管理提供的git访问地址,将远程仓库克隆到本地,使工作区可以正常运行起来,并根据分支策略在开发分支上创建分支进行开发工作。

    1.  代码提交

    开发人员修改完成后提交代码到暂存区,在暂存区域生成文件快照并提交到本地和远程开发分支,由开发负责人来进行代码的审核和合并。建议开发人员及时同步代码,以避免冲突和丢失修改。同时,开发人员必须保证上传的代码是通过编译的。

    在开发过程中,很多时候需要对一个项目进行分支操作,在开发分支上对项目进行开发。这由开发人员负责执行。

      1. 配置仓库权限管理
        1. 添加用户

    新员工入职后,如需配置库权限,可走OA或邮件(抄送部门领导)发送给配置管理员申请权限,待领导同意或OA审批通过后,配置管理员为其创建用户并分配对应权限。用户名生成规则为邮箱前缀。

        1. 创建

    默认只有配置管理员有权限进行群组的创建与编辑(可建子群组),如有需要可提OA或邮件(抄送部门领导)发送给配置管理员申请权限,待领导同意或OA审批通过后,配置管理员为其创建群组或调整相应权限。邮件或OA里面需要注明具体信息,如:创建群组的名称,或调整群组的具体权限信息等。

        1. 用户权限

    如需配置库权限,可走OA或邮件(抄送部门领导)发送给配置管理员申请权限,待领导同意或OA审批通过后,配置管理员为其创建用户并分配对应权限。邮件或OA里面需要注明申请的具体信息,如:

    姓名:xxx

    群组名与角色:atp-bos  master

    项目名与角色:ATP/Common  develop

    权限截止日期:2019-07-08(永久权限不写此项)

    不同角色拥有不同权限,下面列出Gitlab各角色常用权限

    1. 工程权限

    行为

    Guest

    Reporter

    Developer

    Master

    Owner

    创建issue

    留言评论

    更新代码

     

    下载工程

     

    创建代码片段

     

    创建合并请求

     

     

    创建新分支

     

     

    提交代码到非保护分支

     

     

    强制提交到非保护分支

     

     

    移除非保护分支

     

     

    添加tag

     

     

    创建wiki

     

     

    创建里程碑

     

     

     

    添加项目成员

     

     

     

    推送保护分支

     

     

     

    是否保护分支

     

     

     

    修改/移除tag

     

     

     

    编辑工程

     

     

     

    添加deploy keys

     

     

     

    配置hooks

     

     

     

    切换visibility level

     

     

     

     

    切换工程namespace

     

     

     

     

    移除工程

     

     

     

     

    移除保护分支

     

     

     

     

     

    1. 群组权限

    行为

    Guest

    Reporter

    Developer

    Master

    Owner

    浏览组

    编辑组

     

     

     

     

    创建项目

     

     

     

    管理组成员

     

     

     

     

    移除组

     

     

     

     

        1. 保护分支

    默认保护master分支,可使用正则表达式保护分支。保护的分支不能进行push -f操作。

        1. 项目的可见性

    项目的可见性不能超出群组的可见性范围,项目或群组有三种可见性:

    Private:私有,必须配置权限才可进行访问。

    Internal:内部,必须进行帐号密码登录后才可进行访问。

    Public:公开,所有人都可进行访问。

        1. 移除用户

    定期清理已离职或调出项目的成员权限

      1. 灾备策略

    <暂无>

      1. 灾备还原

    <暂无>

    1. 分支管理规范

    本公司采用git flow工作流模式进行分支管理。

      1. 分支工作流程图

    图 3-1 git flow工作流程图

      1. 分支职责
    1. 主分支master

    代码库应该有一个、且仅有一个主分支。它是自动建立的,一般默认此分支是被保护的,版本库初始化以后,就是在主分支在进行开发。此分支除第一次进行原子提交推送外,只能接收其它分支合并,任何人不能直接在master分支上进行修改和提交。

    1. 开发分支develop

    用于日常开发,存放最新的开发版的一个主要分支。不管是要做新的feature还是需要做bug fix,都是从这个分支分出来做。在这个分支下主要负责记录开发状态下相对稳定的版本,即完成了某个feature或者修复了某个bug后的开发稳定版本,开发完成需要提交测试的功能都必须要合并到该分支。

    1. 辅助分支

    feature: 开发新功能的分支, 基于 develop, 完成后 merge 回 develop。

    release: 准备要发布版本的分支, 用来修复 bug. 基于 develop, 完成后 merge 回 develop 和 master;

    hotfix: 修复 master 上的问题, 等不及 release 版本就必须马上上线. 基于 master, 完成后 merge 回 master 和 develop。

      1. 创建分支规范

    1.配置管理员在建立仓库时创建一个master分支和develop分支。

    2.开发人员根据开发的功能点从develop分支创建一个feature分支,当功能点开发测试完毕之后,就会合并到develop分支去,可以将feature分支删除。

    3.当需要发布一个版本来测试时,开发人员从develop分支创建一个release分支来测试。

    4.正式发布后,过程中出现bug,从master分支创建一个hotfix分支,修补结束以后,再合并进master和develop分支。

      1. 分支命名规范
    1. 主干分支:master
    2. 开发分支:develop
    1. 创建特性分支,名称要以f-开头,加上特性名
    2. 创建发布分支,名称要以r-开头,加上预发布版本号
    3. 创建Bug修复分支,名称要以b-开头,加上Bug号
    1. 创建标签:
    1. 当软件包发布到UAT环境时要在release分支上打标签,名称要以发布版本号加上RC1,RC2等结尾。
    2. 当软件包发布到正式环境后要在master分支上创建标签,名称要以发布版本号加上REALESE结尾。
    1. 代码管理规范
      1. 提交代码规范
        1. 目的

    为了规范代码库分支管理和版本管理,使代码分支及版本结构清晰,方便维护,并避免由于维护造成的错误的版本发布等问题。

        1. 代码提交说明

    由对应分支修复的实际开发人员提交或合并到开发分支,开发负责人需要进行判断是否需要合并,并协助解决冲突代码。提交的信息必须按照代码提交模板规定来书写。

        1. 代码提交模板

    Commit message格式:

    type(scope): subject

    BugID:如果是修复Bug,请加上Bug号

     

    type: 用于说明 commit 的类别,暂时只使用下面标识(后续可完善增加)。

    feat:

    新功能(feature)

    fix:

    修补bug

    docs:

    文档(documentation)

    style:

    格式(不影响代码运行的变动)

    refactor:

    重构(即不是新增功能,也不是修改bug的代码变动)

    chore:

    构建过程或辅助工具的变动

    test:

    测试用例的修改

    ci:

    自动化流程配置修改

    revert:

    回滚到上一个版本

    Other:

    其它

     

    scope:【可选】用于说明commit的影响范围

    subject

    subject是 commit 目的的简短描述,不超过50个字符。

    例如:

    feat(ssr): 增加可视化功能

    BugID:8023

        1. 代码提交步骤

    1. 同步远程仓库代码,和远程仓库进行代码合并。

    2. 将分支工作区修改的代码和提交描述等提交到开发分支。

    3. 开发负责人对提交的分支代码进行审核和合并,并解决冲突。

    4. 同步到主分支上。

        1. 解决冲突

    pull同步工作区,找到冲突文件,解决冲突重新提交。

    1. 版本管理规范 
      1. 目的

    标识、控制和追踪软件开发和实施过程中产生的各种软件产品版本。

      1. 项目版本管理
        1. 版本号约定

    <主版本>.<次版本>.<增量版本>-<SNAPSHOT>

    主版本:标示项目的重大架构变更。

    次版本:表示重大Bug的修复,较大范围的功能增加和变化。

    增量版本:一般标示一些小的bug fix,不会有重大的功能变化。

    SNAPSHOT:快照版本,只能用于开发阶段对内发布,对外发布时不允许出现SNAPSHOT版本。

    eg:1.3.4-SNAPSHOT

    【1】代表该版本是第一个重大版本;

    【3】表示这是基于重大版本的第三个次要版本;

    【4】表示该次要版本的第四个增量版本;

    【SNAPSHOT】表示此版本为快照版本;

     

    版本号的修改由开发人员根据以上规则进行更改。

      1. 软件产品包版本管理

    预发布环境:V主版本号.子版本号.增量版本号_日期版本号(yyMMdd)_阶段版本号

    如:V2.15.0_190108_RC1

    正式环境:V主版本号.子版本号.增量版本号_日期版本号(yyMMdd)_RELEASE

    如:V2.15.0_190108_RELEASE

     

    主版本号:当功能模块有较大的变动,比如增加多个模块或者整体架构发生变化。此版本号由项目决定是否修改。

    子版本号:当功能有一定的增加或变化,比如增加了对权限控制、增加自定义视图等功能。此版本号由项目决定是否修改。

    增量版本号:一般是 Bug 修复或是一些小的变动,要经常发布修订版,时间间隔不限,修复一个严重的bug即可发布一个修订版。此版本号由项目经理决定是否修改。

    日期版本号:用于记录修改项目的当前日期,每天对项目的修改都需要更改日期版本号。此版本号由开发人员决定是否修改。

    阶段版本号:此版本号用于标注当前版本的软件处于哪个开发阶段,当软件进入到另一个阶段时需要修改此版本号。此版本号由项目决定是否修改。

     

    当软件包正式发布客户后需要配置管理员进行归档操作。

      1. 出包步骤
    1. 项目负责人通知项目组准备出包,同时给出出包时间点,如半小时后出包。
    2. 开发人员收到出包通知后,尽快将完成的代码进行提交到特性分支,并将特性分支代码合并到develop分支。
    3. 提交代码完成后,配置管理员基于develop分支拉release分支,并在构建时根据标签命名标准构造新标签号。如构建失败则通知开发人员在release分支上修改后重新构建。
    4. 通过maven和jenkins进行构建、打包和发布部署。
    5. 构建完成后通知相关人员。

     

    展开全文
  • 软件版本管理

    千次阅读 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. 运维工程师有权拒绝未经审核或者未完全通过审核的发布申请。 

     

    展开全文
  • Git本地版本管理

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

    一些基本概念

    分布式版本控制系统

    Git 是一种分布式版本控制系统 (Distributed Version Control System DVCS) 。这种系统下,客户端不只是简单地拉取某个版本的文件,而是把整个记录文件版本的数据库(即整个代码仓库)都克隆到本地系统上。这样以来,任何一处协同工作用的服务器发生故障,事后都可以用任何一个镜像出来的本地仓库恢复。因为每一次的克隆工作,实际上都是一次对代码仓库的完整备份。

    这里写图片描述

    存储方式

    Git 中所有数据在存储前都会计算校验和,然后以校验和来引用某个版本的文件,该校验和是根据文件的内容或目录结构使用 SHA-1 哈希算法计算出来的,比如:

    24b9da6552252987aa493b52f8696cd6d3b00373

    Git 数据库中保存的信息都是以文件内容的哈希值来索引,而不是文件名。

    三种状态

    Git 最重要的地方是有三个区:

    • Git 仓库:这个就是保存各种文件版本的数据库,可以向这个数据库中拉取各个文件版本或把更新后的文件推入数据库进行记录。这是 Git 用来保存项目的元数据和对象数据库的地方,是 Git 最重要的部分,从其他计算机克隆仓库时,拷贝的就是这里的数据。已经推入到这个数据库中的文件对应的状态是 已提交 (commited)
    • 暂存区域:这个区域用来存储对当前已修改过并且作了版本标记的文件,在同一段时间内位于暂存区尚未提交的所有文件都属于同一个当前的版本,这些标记使得对应文件被包含在下次提交的快照中。这个区域是一个文件,保存了下次将提交的文件列表信息,一般位于 Git 仓库目录中。在这个区域的文件状态是 已暂存 (staged)
    • 工作目录:这个区域就是开发人员写代码的地方,对于已经修改并保存的文件,都会存储在这个区域,等待转移到暂存区并提交。它是对项目的某个版本独立提取出来的内容。那些从 Git 仓库的压缩数据库中提取出来的文件,就是放在这个区域所在的磁盘上供你使用或修改。在这个区域的文件状态是 已修改 (modified)

    这里写图片描述

    Git 工作三部曲

    1. 在工作目录修改文件;
    2. 将修改的文件对应的文件快照上传到暂存区。
    3. 提交更新,找到暂存区域的文件,将快照永久性存储到 Git 仓库目录。

    常用命令

    配置用户名和密码

    $ git config --global user.name "Jack Cheng"
    $ git config --global user.email "767833640@qq.com"

    如果使用了 --global 选项,则该命令只需要提交一次,无论你以后在系统中执行何种操作,Git 都会使用这种配置。如果你想针对某个特定的项目使用不同的用户名称和邮箱,可以在那个项目目录下运行没有 --global 选项的命令来配置。

    检查配置信息

    $ git config --list

    检查具体某一项的配置

    $ git config user.name

    获取帮助

    $ git help config
    $ git help push

    创建仓库

    $ git init

    这个命令将创建一个名为 .git 的子目录,这个字目录含有你初始化的 Git 仓库中所有的必须文件,这些文件是 Git 仓库的骨干。但是这只是做了一个初始化操作,在当地文件夹的项目里的文件还没有被跟踪。使用 git add 命令来跟踪文件,使用 git commit 命令来提交文件到本地的 Git 仓库中。

    检查状态

    $ git status

    可以查看当前仓库哪些文件处于未跟踪状态,哪些文件已经放入暂存区等待提交。

    这里写图片描述

    可以看到 .DS_Store 文件位于 Untracked files 标题下,表示这个文件是新创建的未被跟踪的文件,Git 仓库中不存在这个文件的信息。

    这里写图片描述

    可以看到这个时候 .gitignore 文件位于 Changes to be commited 这个标题下面,说明这个文件已经被移入暂存区了,处于已暂存的状态。

    把已修改或未跟踪的文件放入暂存区

    $ git add 文件名

    git add 不仅可以跟踪新文件并放到暂存区,还能把已修改的文件也放到暂存区,这是一个多功能命令。放到暂存区的这些文件在下次提交时将会一并提交到 Git 仓库中。因此对于 git add 命令的最好翻译是 “添加内容到下一次的提交中”。

    $ git add 文件目录

    此时 git add 命令将递归地跟踪该目录下的所有文件,并把目录下的所有文件都放入暂存区。

    查看已暂存的文件和当前工作目录中文件的差异

    $ git diff

    git diff 命令可以查看当前工作目录中已修改的文件和暂存区的文件的差异(注意只是和暂存区的差异,不是和上次提交以来的差异,因此如果你把所有已经修改的文件都添加到暂存区后,git diff 将不会返回任何东西)

    查看已暂存的文件和上一次提交后的文件的变化

    $ git diff --staged 或者
    $ git diff --cached

    提交处于暂存区的所有文件

    $ git commit -m "说明当前做了什么,以后版本回退时可以轻易找到"

    注意提交的都是放在暂存区的文件,每一次的提交的版本都会在历史记录中记录下来,以后都可以回到这个版本。(只有 commit 以后的版本可以回退)

    回到过去

    $ git log

    使用 git log 命令查看历史提交记录:

    这里写图片描述

    $ git log --pretty=oneline

    为了简化查看,可以使用 git log --pretty=oneline 参数:

    这里写图片描述

    $ git reset --hard commit_id 

    找到要回退的版本的前面的 commit_id,然后使用 git reset --hard commit_id 命令来回退到想要的版本,只需要打出 commit_id 的前几个字母即可,Git 会自动查找对应的 id

    这里写图片描述

    可以看到此时项目的最新版本已经回退到了 3950d 的版本。

    从过去回到现在

    $ git reflog

    回退以后,会发现之前的最新版本 9fd77 已经不在 git log 的目录中了,此时假如我们又想回到之前的最新的版本怎么办?首先使用 git reflog 命令来查找提交 9fd77 时的记录:

    这里写图片描述

    git reset --hard commit_id

    可以看到我们在回退前最新一次提交的 commit_id9fd77b1 ,因此我们再用 git reset --hard 9fd77b1 来进入到回退前的最新版本:

    这里写图片描述

    因此,我们也就从过去回到现在了。

    一些 trick

    忽略文件

    有时候我们会有一些文件不需要纳入 Git 的管理,比如上面的 .DS_Store ,此时就应该编写 .gitignore 文件来列出要 Git 仓库忽略的文件模式。该文件的格式规范如下:

    • # 开头的行为 Git 的注释。

    • 使用 / 放在文件名的开头可以防止递归地忽略所有非当前目录中的该文件。比如

      TODO

      会忽略 Git 仓库中所有目录下的 TODO 文件,但如果只希望 Git 忽略当前目录下的 TODO 文件,而不要忽略其它目录下的 TODO 文件,则应该写成这样:

      /TODO
    • 使用 / 放在文件名的末尾表明这个文件是一个目录,Git 将会忽略这个目录下的所有文件。

    • 如果希望 Git 只记录某一个特定的文件,而忽略除了这个文件以外的所有文件,可以在这个文件名前面使用 ! 取反。但是这种功能一般是用于以下情况:

      
      # 忽略所有的 .a 文件
      
      *.a
      
      
      # 但是所有的 lib.a 文件不能被忽略
      
      !lib.a
    • 指定文件的格式一般要使用正则表达式:

      • * 匹配 0 个或多个任意字符;
      • [abc] 可以匹配任何一个在方框号中的字符(在这个例子中是要么匹配一个a,要么匹配一个b,要么匹配一个c);
      • ? 只匹配一个任意字符;
      • [0-9] 表示匹配在 0 到 9 范围内的所有数字。
      • 使用两个星号 ** 表示匹配任意的中间目录,比如 learn/**/git 可以匹配 learn/gitlearn/no/git 或者 learn/no/python/git

    看一个 .gitignore 文件的例子:

    # 忽略所有以 .a 结尾的文件
    *.a
    
    # 不能忽略所有 lib.a 文件
    !lib.a
    
    # 仅仅忽略当前目录下的 TODO 文件
    /TODO
    
    # 忽略 build 目录下的所有文件
    build/
    
    # 仅仅忽略 doc 一个目录下的所有 .txt 文件
    doc/*.txt
    
    # 忽略 doc 目录下(包括子目录)的所有 .pdf 文件
    doc/**/*.pdf

    移除文件

    最常见的情况是,在 .gitignore 文件中未列出对应的文件,有时为了贪求效率,使用 git add . 把所有文件都放到暂存区域,包括把一些不希望加入 Git 版本管理的日志文件等也放进去了,这个时候我们希望可以从暂存区域中删除这些不希望被管理的文件,但是使这些文件仍然被存放在工作目录上,而不被 Git 继续跟踪。此时可以使用 git rm --cached filename 命令:

    这里写图片描述

    这样就可以把误添加的文件从暂存区中移除,而防止下一次 commit 时加入到 Git 仓库中去。

    还有一种情况就是,我希望删除的文件已经 commit 或者 add 了,即已经被跟踪了,但我希望完全删除这个文件,即把工作目录中的这个文件也删了,这时我们就可以先在本地项目目录中删除这个文件,然后再使用 git rm filename 命令把该文件从已跟踪的文件清单中一并删除:

    这里写图片描述

    这个是文件已经 add 但没有 commit 的情况,使用 git rm 命令就直接清空了,如果文件之前有过 commit ,而你又把想删除的文件从工作目录中删除了:

    这里写图片描述

    可以看到删除文件的操作记录在 Changes not staged for commit 标题下, 意味着你需要把这个删除的操作再提交一遍,使得 Git 仓库知道这个文件已经删除了,不应该再被跟踪了。

    移动文件

    如果要在 Git 中对某些文件进行重命名,可以使用 git mv original_name target_name 命令:

    这里写图片描述

    执行这个命令后,可以看到在工作目录中的 test.cpp 也被重命名为 main.cpp 了,这个时候只要提交这次重命名操作就可以了。

    参考资料

    1. Pro Git
    2. 廖雪峰 git 教程
    展开全文
  • 飞流Flow是基于git的多主干分支模式的版本管理模型(也叫分支模型),区别于传统使用develop分支、release分支和master的gitflow,飞流Flow采用了 feature + n*release + master 的分支形式实现版本管理,而其中,n ...
  • 使用Git连接到GitHub并进行版本管理

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

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

    万次阅读 2019-05-16 17:17:51
    :当我们在开发过程中,也难免一些刚刚入职的同事不小心对代码所造成的伤害难以弥补的时候,这个时候我们也可以通版本管理工具,将当前的代码回退到之前提交的某个版本。 多端共享 :提供进行团队合作使用,总不...
  • maven版本管理(十二)

    千次阅读 2018-02-09 17:11:11
    版本管理 一个健康的项目通常有一个长期的、合理的版本演变过程,如junit有3.7、3.8等版本,而有了版本的定义,那么我们就可以针对版本做控制和管理。 那么,版本管理和版本控制又是什么,版本管理是指项目整体...
  • DevOps企业实践指南(7): 版本管理

    千次阅读 2017-08-10 10:31:38
    在这篇文章中我们将会结合企业实施版本管理中经常会出现的七个场景去理解为什么版本管理是复杂的,在此基础上提出”版本管理的七问”用以对帮助企业对自身版本管理能力进行快速的定位,同时在此基础上进行适合自己的...
  • 小程序 版本管理使用教程

    千次阅读 2019-07-13 10:27:37
    版本管理 1.小程序点击版本管理,进入网页; 2.创建项目,自定义路径,并设置密码; 3.在小程序端 设置-远程 添加路径; 4.在网络和认证中选择使用用户名和密码,输入之前设置的账号密码; 5.点击推送,首次推送...
  • 软件开发版本管理规范

    千次阅读 2018-06-28 10:06:02
    第一 目的 本规范详细规定软件项目版本管理的对象、存储目录、分支、权限、维护等内容,使软件项目版本管理流程化并规范化,确保在系统开发和实施过程中项目的完整性和一致性。第二章 适用范围 所有系统开发及...
  • 软件版本管理规定

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

    千次阅读 2018-09-06 20:43:06
    1. 引入jar依赖 ... <artifactId>api-version ...如果指定版本号(例如1.0.3)的接口没有匹配到,则自动寻找最新版本(1.0.0)的接口,都没有则 404。 5. jar包下载 com.slowlybirld.apiversion
  • 使用多个node版本,nodejs版本管理

    千次阅读 2019-07-15 14:14:56
    NVM (Node Version Manager): Nodejs的版本管理工具 1.卸载已经安装的node(如果已经安装),可以使用node自带的uninstall ,也可以使用其它软件管理工具卸载 2.下载nvm并安装 卸载完后下载nvm安装 (推荐使用nvm-...
  • 代码版本管理工具介绍

    千次阅读 2018-05-06 22:11:06
    笔者有幸接触过以下几种常用的配置管理工具:VSS、SVN、Clearcase,在此做一个小小的总结,并Ctrl+C了以前一些网友的对比评论,不一定准确,只是希望通过这些总结对自己和初学者有所帮助。如果想进一步了解这些工具...
  • 软件版本管理规范

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

    千次阅读 2019-06-20 15:21:18
    Flyway是一款开源的数据库版本管理工具,Flyway可以独立于应用实现管理并跟踪数据库的变更,Flyway根据自己的约定,不需要复杂的配置就可以实现数据的Migrate。Migrations可以写成SQL脚本,也可以写在Java代码中,...
  • Windows10下Node版本管理与随意切换

    万次阅读 2018-09-28 11:02:42
    Windows下Node版本管理与随意切换使用GNVM环境问题一:无权操作文件问题二:文件被占用问题三:node版本不存在`GNVM` 是一个简单的 `Windows` 下 Node.js 多版本管理器,类似的 `nvm` `nvmw` `nodist` 。下载安装...
  • 使用git进行项目版本管理

    万次阅读 多人点赞 2018-01-15 10:47:59
    为了更好地管理目前公司内的源码版本,让大家更好的协同工作,前阵子看了不少关于git版本管理的文章,总结除了一个相对简单的管理规范,并在实践一段时间后,进行了调整。最终版如下: 为规范源代码版本管理,现将...
  • 使用NVM对node进行版本管理

    万次阅读 2018-06-12 20:21:00
    使用NVM对node进行版本管理一、需求node版本持续更新,一些node的新特性只有在node的较高版本中才可以使用。但是如果将node版本切换到较高版本,就会导致对现有项目的一些依赖造成环境不兼容。所以,需要一个工具对...
  • Mac下node多版本管理

    千次阅读 2020-07-16 19:33:41
    node开发中,经常遇到版本不匹配的问题,导致编译失败,卸载该版本重新安装的成本又太高,因此我们需要多版本管理的工具。 工具 n / nvm n相比于nvm更容易安装 node,因此选用 n 作为多node版本的管理工具 安装 ...
  • 使用visualSVN做版本管理

    千次阅读 2018-07-04 09:30:51
    上一篇说到使用TortoiseSVN做项目版本管理:TortoiseSVN的安装与使用,TortoiseSVN作为客户端,虽然也可以创建版本库,但是只能本地使用。在实际开发中,我们可能需要远程提交代码,此时应该使用visualSVN作为服务端...
  • Node之Linux下多版本管理整理总结

    千次阅读 2017-05-29 12:48:17
    开心一笑提出问题Linux下Nod实现多版本管理???解决问题前言公司ember升级,有些项目需要用旧版本的node,有些项目需要新的。在不同项目下进行npm install 时候经常出现错误。举步维艰,身心备煎。多亏同事提醒,...
  • java后端 解决app接口版本管理问题

    千次阅读 2018-12-25 11:04:55
    版本接口不多时,可以通过接口传参然后判断来实现,但是版本接口过多时,在接口中做判断就会效率低下。 但是多个接口暴露出去是同一个访问路径。这样对于app端是察觉不到的。 这里采用拦截器和转发模式,进行...
  • 版本管理工具之ClearCase

    万次阅读 2018-04-18 15:56:52
    Rational ClearCase是软件配置管理SCM工具的一种,它可以用来对代码或者其他软件开发资产进行版本控制。对于超过上百或者上千团队开发者的大型项目据说也有很好的支持,同时对于大的二进制文件,文件个数很多,整体...
  • 代码分支及版本管理规范

    万次阅读 2017-11-18 20:31:52
    为了规范代码库分支管理 和 版本管理,使代码分支及版本结构清晰,方便维护,并避免由于维护造成的错误的版本发布等问题。 Git 分支管理 通常每个应用或者是二方库的代码将包括 master、develop、release、hotfix、...
  • Word 2013版本管理

    千次阅读 2017-07-17 20:38:11
    写文档经常需要多个版本,一般采用复制或另存为的方式,传说在word 2007之前有版本管理,被阉割了?网上搜到的靠版本管理方式采用代码管理的方式,过于复杂。 版本管理自己使用的需求就是很基本,能够看到保存的...
  • Gitlab实现项目版本管理

    千次阅读 2017-05-17 14:58:21
    Gitlab实现项目版本管理简介 GitLab是利用 Ruby on Rails 一个开源的版本管理系统,实现一个自托管的Git项目仓库,可通过Web界面进行访问公开的或者私人项目。它拥有与Github类似的功能,能够浏览源代码,管理缺陷...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 2,043,872
精华内容 817,548
关键字:

版本管理