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

版本信息                                       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. 远程仓库管理
  2. 配置管理员:创建远程仓库、人员添加、权限分配、打标签、构建版本等工作。
  3. 开发负责人:导入该项目到远程仓库并完成分支的创建和设置。
    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. 分支职责
  2. 主分支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. 分支命名规范
  2. 主干分支:master
  3. 开发分支: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. 出包步骤
  2. 项目负责人通知项目组准备出包，同时给出出包时间点，如半小时后出包。
  3. 开发人员收到出包通知后，尽快将完成的代码进行提交到特性分支，并将特性分支代码合并到develop分支。
  4. 提交代码完成后，配置管理员基于develop分支拉release分支，并在构建时根据标签命名标准构造新标签号。如构建失败则通知开发人员在release分支上修改后重新构建。
  5. 通过maven和jenkins进行构建、打包和发布部署。
  6. 构建完成后通知相关人员。

配置库管理及版本管理规范相关推荐

  1. 开发流程与版本管理规范

    # 开发流程与版本管理规范## 版本号规则如非特殊说明,所有产品的版本号将遵循 主版本.次版本.BuildNumber 的规则. - 主版本号:发布重大更新时增加 - 次版本号:发布新功能点时增加 - ...

  2. Git学习总结（23）——Git commit message和版本管理规范总结

    一.Git commit message基本规范 对格式的说明如下: type代表某次提交的类型,比如是修复一个bug还是增加一个新的feature.所有的type类型如下: feat: 新增feat ...

  3. 【Python】安装autopep8包，并在PyCharm中进行配置，以PEP8规范排版代码

    安装autopep8包,并在PyCharm中进行配置,以PEP8规范排版代码 ①在Python环境中安装autopep8包 在PyCharm中可以先点击Terminal ->输入命令或者在cmd ...

  4. eslint 配置_前端代码规范配置 （一）

    ESLint ESLint 是一个开源的 Javascript 代码检测工具,通过将 js 代码解析成抽象语法树(AST),分析并给与代码质量(如一些方法的使用方式不对)和代码风格(缩进,引号等等)两 ...

  5. windows + Linux 自定义模板配置 怎么使用自定义规范管理器

    转载: https://www.cnblogs.com/itfat/p/8342938.html win2008以上的系统,在vmware esxi5.5里怎么使用自定义规范管理器?sysprep 经 ...

  6. Webpack 2 视频教程 009 - 配置 ESLint 实现代码规范自动测试 (上)

    原文发表于我的技术博客 这是我免费发布的高质量超清「Webpack 2 视频教程」. Webpack 作为目前前端开发必备的框架,Webpack 发布了 2.0 版本,此视频就是基于 2.0 的版本讲 ...

  7. 进销存仓库管理系统：规范数据、流程与管理

    库存管理是仓储管理的重要组成部分,但营运过程中更多重视货品售出和采购,忽视货品存货对整体营运效果的影响. 传统仓储通过人力经验与感觉对整个仓库库存管理,缺乏科学规范的库存管理方法,库存管理方面存在着整 ...

  8. 使用husky配置git代码提交规范

    1.安装husky yarn add --dev husky 2.配置husky 在 package.json 中的 script 中添加一条prepare命令: "scripts" ...

  9. pycharm配置安装autopep8自动规范代码

    先下载安装autopep8:    1. window键+R快捷键打开命令行窗口,输入cmd回车,输入 pip install autopep8(你的电脑需要联网).或者在pycharm下边点击ter ...

  10. 使用gitblit配置git代码版本管理服务器

    作为前端,以前在公司里的代码版本管理服务器一般都是已经配置好的,而新到了一家公司,这个还没配置,而且没有单独的一台机器代为服务器,只能用自己的电脑了,在网上看了一下,一般代码版本控制用的工具是gitL ...

最新文章

  1. DllImport dll中有些啥函数 及 dll中是否用到了别的dll
  2. INNODB 热备工具试验与总结
  3. android 蓝牙通讯编程 备忘
  4. 【Jboss】热部署
  5. 如何卸载office201032位_Office 2010如何手动卸载？
  6. linux复杂逻辑判断,20.5 shell脚本中的逻辑判断
  7. python编译成class_django为Form生成的label标签添加class方式
  8. mongodb 导出一条数据导出_使用MongoDB命令工具导出、导入数据
  9. 详解各类以太网标准10BASE-T/100BASE-T4/100BASE-FX/1000BASE-X等
  10. 图数据库_ONgDB图数据库与Spark的集成
  11. 啥是佩奇？爷爷，我用Python给你画一个
  12. @程序员，我最多再等你两天！
  13. python中文叫什么-python中文别名
  14. php自定义函数表格,自定义函数table()
  15. BIM族库下载——塔吊等垂直运输设备族库
  16. c语言程序设计实例220,C语言程序设计实例大全(220个例子)
  17. 利用磁共振成像数据估测脑年龄
  18. SketchUp插件|ClothWorks布料模拟 免费下载！（草图大师制作窗帘张拉膜等）
  19. 【转载】学习可能用到的英语单词
  20. HIVE优化的四种方法

热门文章

  1. 0x02 如何安装【XPS 查看器】？超简单哦！
  2. PHP文件运行步骤及数据库的连接
  3. 前端开发使用物联网pass平台应知事项
  4. JAVA架构师之路-视频学习
  5. 记录一下postman汉化踩过的坑
  6. c语言取反运算详细步骤,C语言取反运算~
  7. android远程连接windows,用微软的安卓远程桌面连接电脑没有声音
  8. cad学生版和教育版_针对学生和教育者的3个版权提示
  9. 软件安全测试之应用安全测试
  10. 美通企业日报 | 爱彼迎成为奥林匹克全球合作伙伴；腾讯理财通运营主体迁至腾富公司...