精华内容
下载资源
问答
  • 基于git的代码版本管理规范及流程-简版
    千次阅读
    2017-12-06 22:34:51

    基于git的简单实用的版本管理规范及流程,包括:代码库的分布、人员角色的划分、代码提交合并流程、代码冲突处理、分支管理。

    代码库分类

    根据代码库分布的位置及作用,分为以下几类:

    • 主库:位于服务端,所有开发的代码最终都要合到主库。
    • 个人代码库(服务端):从主库fork出来,位于服务端。每个人自已开发的代码,由本地的git库push到每个人自己的个人代码库(服务端),再由个人代码库(服务端)合入主加。
    • 个人工作库:位于每个开发人员的开发机器,从个人代码库(服务端)clone到本地。每个开发人员开发的代码,先commit到个人工作库,再由个人工作库push到个人代码库(服务端)。

    人员角色分类

    这里说的角色,都是人员在主库上的角色。基于简化的原则,人员分为三类:

    • Owner:拥有主库的所有权限。
    • Committer:具有将开发人员的合并需求(MR)合入主库的权限。基于安全考虑,我们设置为只能通过MR的方式将代码合入主库,而不能直接push到主库。
    • Developer:只能从自己的个人代码库(服务端)提交合并代码的请求(MR),是否能够合入,由Committer进行审核。

    基本流程

    在主库已经存在的情况下,日常操作流程如下:

    1. 开发人员从主库fork出自己的个人代码库。
    2. 开发人员将自己的个人代码库clone到本地,即个人工作库。
    3. 开发人员在开发了新代码后(包括新增和修改),先将代码commit到自己的个人工作库,再由个人工作库push到个人代码库。
    4. 开发人员提交从个人工作库到主库的MR,Committer审核后,决定是否将MR合入主库。
    5. 每个开发人员从主库pull最新代码到个人工作库。

    分支管理

    • 主库缺省的master分支,是用来向生产环境发布的,所有合入的代码,原则上都必须是稳定的。
    • 主库除了master分支外,至少还要有一个活动分支,命名建议为:br_工程名_active,平时日常的开发都基于活动分支开发。即从个人工作库提交MR到主库时,指向的是主库的活动分支。活动分支测试稳定后,将主库的活动分支通过MR的形式,合并到主库的master分支,同时打上tag。
    • 如果软件运行过程中发现必须立即修改的bug,则从主库的master分支中,拉出一个bugfix分支。为修复这个bug的所有开发,都基于bugfix分支。待bugfix分支开发完成,并测试稳定后,将bugfix分支以MR的方合入主库的master分支。然后删除bugfix分支,视情况决定是否打tag。

    常见问题

    此部分内容会根据情况进行相应的增加。

    活动分支合入主分支时发生冲突

    产生原因

    平时基于活动分支开发,如果这个过程中为了修复bug而拉了一个bugfix分支,当bugfix分支开发完成并合入master分支后,如果bugfix分支和活动分支修改了相同的文件,则在活动分支合入master分支时就会产生冲突。

    解决方法

    1. 从个人代码库(服务端)clone一个库到本地,即专门用于合并的个人工作库。(也可以用之前的个人工作库,但初学都容易混淆,建议单独clone一个。)
    2. 从主库的活动分支上pull最新的代码到本地。
    3. 从主库的master分支上pull最新的代码到本地。
    4. 此时会产生冲突,手工修复冲突,然后先commit到本地的个人工作库,再push到个人代码库(服务端)。
    5. 提交从个人工作库(服务端)到主库的MR(此时不会再有冲突),然后由Committer审核后将MR合入主库。
    更多相关内容
  • 代码版本管理规范

    2015-12-18 14:11:30
    为了规范和制度化公司的软件版本管理制度,并保障项目开发资料的完整性和安全性,同时明确开发源代码的控制管理流程,特此制定此规范
  • 为了规范代码库分支管理版本管理,使代码分支及版本结构清晰,方便维护,并避免由于维护造成的错误的版本发布等问题。通常每个应用或者是二方库的代码将包括master、develop、release、hotfix、feature分支,...
  • 程序代码版本管理规范.doc
  • SVN版本管理规范

    2018-01-23 09:51:33
    对svn日常使用、代码管理版本管理、命名规范等做了说明。
  • Git代码管理规范.doc

    2021-09-24 11:14:24
    Git代码管理规范
  • git版本管理规范

    2018-01-16 14:10:45
    git版本管理规范,gitlab开发工具,git版本管理
  • 关于git项目管理分支说明。 2.1. master主干 命名:master 说明:发布分支 master为程序主干目录,开发新需求需从master打新分支,开发完成合并回master发测试包,测试完成需打新的tag包,tag包申请上线发布 2.2. ...
  • 代码版本GIT管理规范

    2019-09-06 14:14:22
    目前team中的代码管理规范,分享一下 一、版本管理工具 git 二、分支说明 2.1 master分支 master属于生产稳定主分支,所有版本迭代上线后,代码变动最终都需要合并至主分支的代码中。主分支上的代码每次被更新...

    目前team中的代码管理规范,分享一下

    一、版本管理工具
    git

    二、分支说明
    2.1 master分支

    master属于生产稳定主分支,所有版本迭代上线后,代码变动最终都需要合并至主分支的代码中。主分支上的代码每次被更新,都应有对应的标签(TAG)。

    2.2 feature分支

    feature属于产品规划的版本分支,是多个dev分支小组的合集,由dev合并生成。是正常产品版本提测时的分支,供测试人员在测试环境测试。

    命名风格:feature+产品版本号
    命名举例:featureV2.1.0

    2.3 dev分支

    dev属于各开发人员的独立分支,从master拉取作为开发的基础版本。

    命名风格:dev+开发人员缩写+开发内容简要
    命名举例:dev_yq_分库分表、dev_whn_银联二三类、dev_wjl_日志优化

    2.4 hotfix分支

    hotfix属于线上BUG紧急修复的补丁版本,从master拉取作为开发的基础版本。是补丁修复版本提测时的分支,供测试人员在测试环境测试。

    命名风格:hotfix+补丁日期
    命名举例:hotfix-Patch20191002

    三、开发上线流程

    3.1 流程图

    在这里插入图片描述
    3.2 流程说明

    1.开发人员根据各自的开发需求,从master拉取分支,独立开发

    2.提测时,根据产品版本内容规划,将相应的dev分支合并,生成版本分支featureV2.1.0

    3.测试人员测试正常版本featureV2.1.0

    4.测试期间,遇到生产环境问题,需要紧急发版,从master拉取分支,修改相应的代码,

    命名hotfix-Patch20191002,以hotfix-patch20191002提测发版

    5.hotfix发版后,将代码合并入master,并在master打标记(TAG),删除hotfix分支

    6.featureV2.1.0回归测试前,再一次将master合并入分支,做回归测试

    7.featureV2.1.0测试完成后,以featureV2.1.0发版,发版完成后,将代码合并入master,并在master打标记(TAG),删除featureV2.1.0分支及涉及的dev分支

    展开全文
  • 代码管理版本管理的作业流程以及规范是怎样的? 代码管理版本管理的作业流程以及规范是怎样的?下面以文档的形式进行详细分析,希望能够给予测试人员一些帮助和指导。 本文目的 本文试图提供一套有效进行代码...

    代码管理和版本管理的作业流程以及规范是怎样的? 

    代码管理和版本管理的作业流程以及规范是怎样的?下面以文档的形式进行详细分析,希望能够给予测试人员一些帮助和指导。

    本文目的

    本文试图提供一套有效进行代码和版本管理风控的标准、约定和指导。本文以安全可靠的软件工程原则为基础,在源代码层面使其易于管理、维护,同时降低核心技术泄密风险,在版本管理层面,保证每个交付前、交付中、交付后的产品版本是一致的,且可快速、准确的对每个版本中的过程情况进行追溯。本文以通过遵循和不断改进项目过程中的实施标准,使各项目产生的代码有更好的管控机制,降低代码泄密风险、降低发版风险并提高软件开发团队的生产效率。

    本文适用于人群

    本文档的预期读者包括项目开发组全体成员:产品人员、技术管理人员、系统设计人员、系统开发人员、系统测试人员、系统维护人员、推广培训人员及其他相关人员。

    使用范围

    本文档适用于所有与代码管理、版本控制相关的项目管控工作。

    一、管理工具

    1、代码管理工具Git

    Git是一款免费、开源的分布式版本控制系统,可以有效、高速的处理从很小到非常大的项目版本管理。它是目前世界上使用最广泛的代码管理工具之一,包括Google、Facebook、Microsoft、Twitter等在内的大型企业都在使用他进行管理。Git在本规范中主要用于代码管理与开发版本控制。

    2、版本管理工具Maven

    Maven是一个软件项目管理及自动构建工具,由Apache软件基金会所提供。Maven在本规范中主要用于版本号管控以及代码部署的自动构建。

    3、发布管理工具Jekins

    Jenkins是一个用Java编写的开源的持续集成工具。它主要用于持续、自动地构建/测试软件项目。Jenkins在本规范中主要用于系统的自动构建与发布以及发布后系统运营的监控管理。

    二、版本管理

    1、版本命名规范

    版本命名包含:主版本号、次版本号、修正版本号、里程碑版本号。例如:2.2.0.Beta2,该版本号代表主板本为2,次版本为2,修正版本无,且为发布的第二个公测版本。

    具体的各版本号的作用如下:

    2、版本管控流程

    在产品立项时,一般由产品经理或项目负责人明确项目版本号,其至少包含主版本号和次版本号。

    开发、测试、发版过程中需严格遵循版本号的约束进行版本管控,主版本号和次版本号一旦制定,就不允许修改,除非重新立项。修正版本号可在开发过程中进行约束,但尽量提前进行约束且尽可能在开发过程中不做调整。

    版本发布时,一般由产品经理或项目负责人指定里程碑版本号。程碑版本号可以跳版本进行发版,也可以无中间版本号。比如,可以直接发布beta(公测版)或者GA(正式版),但尽可能遵循里程碑版本顺序进行发版和版本管控。

    三、代码管理

    1、角色

    代码管理主要分三大角色:系统管理者、项目管理者、部署者、开发者。系统管理者负责创建新项目、权限分配、用户增加删除和代码库备份。项目管理者负责对具体的某一个项目的权限分配,代码管理。部署者负责对测试代码和正式代码进行发版部署。开发者负责从项目分支代码进行代码开发。

    2、权限

    管理Git、Maven、Jenkins的各个角色的权限如下:

    3、代码管控流程

    1)若为新项目,则由系统管理者通过操作Git创建项目工程,并将Git的项目管理权限赋予项目管理者,且交由项目管理者进行项目与代码管控。

    2)项目管理者通过操作Git在主干代码库基础上创建开发代码库,并将分支代码的操作权限赋予部署者和开发者,同时通过Maven约束版本号。

    3)开发者基于开发代码库进行代码的开发与合并,并提交测试部署。

    4)测试期间,部署者通过操作Jenkins将开发代码库的代码发版部署到测试环境,以供测试者进行测试。

    5)测试通过后,由项目管理者通过操作Git将开发代码库代码合并到主干代码库。

    6)发版上线时,由部署者通过操作Jenkins将主干代码库的代码发版部署到正式环境。

    7)系统管理者定期对代码库进行备份。

    代码管控的具体流程如下图:

    展开全文
  • 研发部源代码管理规范 参考互联网资料,制定的简单的源代码管理规范,使用svn,如使用git也可以参考。规范应该是企业自身开发标准。
  • 代码管理规范

    2018-08-06 12:00:30
    代码管理规范代码管理规范代码管理规范代码管理规范
  • git代码版本控制规则

    2018-06-11 10:48:10
    web开发中,git代码版本控制规范,有助于不同开发环境之间代码发布版本控制
  • 资料内容仅供您学习参考如有不X或者佞权请联系改正或者删除 资料内容仅供您学习参考如有不X或者佞权请联系改正或者删除 软件版本管理规范 第一章目的 本规范详细规定软件项目版本管理的对象存储目录分 支权限维护等...
  • 系统代码管理规范.doc

    2020-06-28 12:05:33
    文件编号:UF/QP/2-09/QI/006 修改:闫明辉 审核:SEPG 日期:01/10/25 版号:1.1 页号: PAGE 1/ NUMPAGES 1 系统代码管理规范 在配置管理程序文件中产品/项目的系统代码是作为配置项整体处理的系统代码在开发过程中的...
  • 公司几乎所有的项目都是使用git仓库来管理代码,以前对git只有些肤浅的了解,每次提交代码或者上线的时候总是会提心吊胆,生怕出现一些未知的问题。经过三个月的踩坑和填坑, git操作颇显成熟。仅以此文回忆学习git...
  • 一、版本管理流程 主干分支(main): 研发的分支从主干检出、经过测试(UAT)验收后必须要合并到main分支上,并且需要发布到UAT环境上再次验收,方可发布, 此分支名称固定为main,每个业务线只存在一个。 功能...

    一、版本管理流程

    在这里插入图片描述

    1. 主干分支(main): 研发的分支从主干检出、经过测试(UAT)验收后必须要合并到main分支上,并且需要发布到UAT环境上再次验收,方可发布, 此分支名称固定为main,每个业务线只存在一个。

    2. 功能分支(feature): 需求研发、功能迭代、缺陷修复、处于研发中的分支。此分支名称按版本规范命名, 每个业务线允许多个存在。

    3. 测试分支(uat): 发布到测试环境的分支,任何研发修改,都需合并到此分支进行测试验证。 此分支名称固定为uat,每个业务线只存在一个。

    二、各业务线运作规范

    1. 每个业务线包含自己的main、uat和feature分支, 例如:

      国内业务:
      1) main 分支: main_china
      2) feature分支: internation_1.0.0_SNAPSHOT
      3) uat分支: uat_internation

      国际业务:
      1) main 分支: main_internation
      2) feature分支: internation_1.0.0_SNAPSHOT
      3) uat分支: uat_internation

    2. 如果各业务线有共性需求,处理流程:

      国内业务的 china_1.1.0_SNAPSHOT -> 合并至国际业务的uat_internation -> 验证后合并至国际业务的main_internation (从china_1.1.0_SNAPSHOT 合并)

    三、版本命名规范

    1. 完整版本格式

      主版本号.次版本号.修订号-版本类型 【eg: 1.0.0-SNAPSHOT】

    2. 主版本号: 项目级主导的规划实现。

      对应:项目级需求【eg: 1.0.0-SNAPSHOT,2.0.0-SNAPSHOT … X.0.0-SNAPSHOT】

    3. 次版本号:功能性的新增与修改。

      对应:功能级需求 【eg: 1.0.0-SNAPSHOT,1.1.0-SNAPSHOT … 1.X.0-SNAPSHOT】

    4. 修订号:面向问题的修正处理。

      对应: BUG级缺陷修复【eg: 1.0.1-SNAPSHOT,1.0.2-SNAPSHOT … 1.0.X-SNAPSHOT】

    5. 版本号名称说明:

      1)SNAPSHOT : 快照版本,标识处于研发阶段,该版本可能存在未完成的功能或还需修复的bug,概念上对应dev分支。

      2)HOTFIX:修复版本, 针对临时缺陷或生产问题修复。

      3)BETA:测试版,发布测试的版本,概念上对应uat分支的测试。

    四、版本合并管理规范

    合并原则

    1. 开发分支(feature)都是基于主干分支(main)检出。
    2. 开发分支(feature)可以合并至UAT分支进行测试, 验收成功后可以合并至主干分支(main)回归。
    3. 测试分支(uat)不可以合并至其他任何分支, 验收后的分支,通过开发分支(feature)进行合并。

    合并权限管控

    1. 权限合并至允许负责人操作, 研发人员不能直接操作,负责人通过gitlab管控好权限。
      在这里插入图片描述

    2. 涉及到合并处理的两个环节, 一是提测时的合并, 二是测试通过回归验证的合并, 负责人必须做好审核, 避免代码合并出现的版本错乱与多模块关联性问题。

    展开全文
  • 选择一款版本管理工具,已经被大多数企业作为项目的必要准备工作之一,相信没有一个开发者没有听过Git、SVN这些工具。 今天我们来寻根溯源,扒一扒版本管理的发展史。
  • 1.1.为有效控制管理代码的完整性,确保其不被非授权获取、复制、传播和更改,明确源代码控制管理流程,特制定此管理制度。 .... 2.2.我们研发的产品软件运行所必须的第三方软件、控件和其它支撑库等文件也必须及时...
  • 该文档主要描述了使用firefly版本管理工具进行多个需求并行开发下的版本管理方式的最佳实践,这是一套用于实现生产上使用的版本管理规范文档
  • Git版本管理及工作流规范

    千次阅读 2019-01-28 16:49:19
    2、为规范代码版本管理,现将各分支表述如下: a.master分支  存放的应该是随时可供在生产环境中部署的代码  当开发活动告一段落,产生了一份新的可供部署的代码时,master分支上的代码会被更新。同时,每一次...
  • 代码分支管理规范

    千次阅读 2019-01-09 13:07:15
    代码分支管理规范:(主要基于GIT,但SVN也可借鉴)   核心思想: 控制代码提交权限,保证主分支和tag分支都是经过测试验证的,保证测试分支不被随意更改。 另外支持对提交的代码进行审查。 支持多...
  • 版本管理规范

    2020-10-09 18:18:38
    版本管理规范 分支规范 主要分为4个分支,dev,test,master, release dev用于本地开发 test用于发布测试环境 master 主线代码库 release分支,代表发布的线上版本 分支使用规范 开发人员在dev分支上开发,...
  • 前端版本管理规范

    2021-04-09 14:48:45
    前端版本管理规范 分支管理规范 开发新版本 : 从 master 新建分支,分支命名 develop-版本号 修复bug : 从master新建分支,分支命名规则 fix-问题 代码提交规范 提交内容组成: type:subject+body type:提交的类型 ...
  • 华为内部代码规范.pdf

    2020-03-26 17:44:23
    华为内部代码规范
  • 配置库管理及版本管理规范

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

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 490,260
精华内容 196,104
关键字:

代码版本管理规范

友情链接: ManYou.rar