配置库管理及版本管理规范
版本信息 A代表新增，M代表修改，D代表删除。
|
版本号 |
发布日期 |
提交人 |
A.M.D |
摘要 |
|
V1.0 |
2019/1/8 |
杨彬彬 |
A |
初稿 |
|
|
|
|
|
|
|
|
|
|
|
|
- 规范项目代码管理流程，明确开发人员和项目管理者的职责。
- 规范代码库分支管理和版本管理，使代码分支及版本结构清晰，方便维护。
- 配置库代码管理工具
使用GitLab作为代码管理工具，GitLab 是一个用于仓库管理系统的开源项目，使用Git作为代码管理工具，并在此基础上搭建起来的web服务。
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目录 |
存储指向数据提交对象的指针。 |
|
角色名称 |
职责 |
|
配置管理员 |
|
|
开发负责人 |
|
|
开发人员 |
|
|
测试负责人 |
|
|
测试人员 |
配置管理员负责建立配置仓库，以便管理源代码、相关文件及资料。每个开发人员在本地都有自己的版本库，在服务器上有一个公共的版本库。
根据配置管理的不同角色所分配的不同职责范围，对本地库和版本库进行管理和操作。
本地库由开发人员和开发负责人负责日常的更新和开发工作。
- 克隆远程仓库，搭建开发环境
开发人员根据配置管理提供的git访问地址，将远程仓库克隆到本地，使工作区可以正常运行起来，并根据分支策略在开发分支上创建分支进行开发工作。
- 代码提交
开发人员修改完成后提交代码到暂存区，在暂存区域生成文件快照并提交到本地和远程开发分支，由开发负责人来进行代码的审核和合并。建议开发人员及时同步代码，以避免冲突和丢失修改。同时，开发人员必须保证上传的代码是通过编译的。
在开发过程中，很多时候需要对一个项目进行分支操作，在开发分支上对项目进行开发。这由开发人员负责执行。
新员工入职后，如需配置库权限，可走OA或邮件(抄送部门领导)发送给配置管理员申请权限，待领导同意或OA审批通过后，配置管理员为其创建用户并分配对应权限。用户名生成规则为邮箱前缀。
默认只有配置管理员有权限进行群组的创建与编辑(可建子群组)，如有需要可提OA或邮件(抄送部门领导)发送给配置管理员申请权限，待领导同意或OA审批通过后，配置管理员为其创建群组或调整相应权限。邮件或OA里面需要注明具体信息，如：创建群组的名称，或调整群组的具体权限信息等。
如需配置库权限，可走OA或邮件(抄送部门领导)发送给配置管理员申请权限，待领导同意或OA审批通过后，配置管理员为其创建用户并分配对应权限。邮件或OA里面需要注明申请的具体信息，如：
姓名：xxx
群组名与角色：atp-bos master
项目名与角色：ATP/Common develop
权限截止日期：2019-07-08（永久权限不写此项）
不同角色拥有不同权限，下面列出Gitlab各角色常用权限
- 工程权限
|
行为 |
Guest |
Reporter |
Developer |
Master |
Owner |
|
创建issue |
✓ |
✓ |
✓ |
✓ |
✓ |
|
留言评论 |
✓ |
✓ |
✓ |
✓ |
✓ |
|
更新代码 |
|
✓ |
✓ |
✓ |
✓ |
|
下载工程 |
|
✓ |
✓ |
✓ |
✓ |
|
创建代码片段 |
|
✓ |
✓ |
✓ |
✓ |
|
创建合并请求 |
|
|
✓ |
✓ |
✓ |
|
创建新分支 |
|
|
✓ |
✓ |
✓ |
|
提交代码到非保护分支 |
|
|
✓ |
✓ |
✓ |
|
强制提交到非保护分支 |
|
|
✓ |
✓ |
✓ |
|
移除非保护分支 |
|
|
✓ |
✓ |
✓ |
|
添加tag |
|
|
✓ |
✓ |
✓ |
|
创建wiki |
|
|
✓ |
✓ |
✓ |
|
创建里程碑 |
|
|
|
✓ |
✓ |
|
添加项目成员 |
|
|
|
✓ |
✓ |
|
推送保护分支 |
|
|
|
✓ |
✓ |
|
是否保护分支 |
|
|
|
✓ |
✓ |
|
修改/移除tag |
|
|
|
✓ |
✓ |
|
编辑工程 |
|
|
|
✓ |
✓ |
|
添加deploy keys |
|
|
|
✓ |
✓ |
|
配置hooks |
|
|
|
✓ |
✓ |
|
切换visibility level |
|
|
|
|
✓ |
|
切换工程namespace |
|
|
|
|
✓ |
|
移除工程 |
|
|
|
|
✓ |
|
移除保护分支 |
|
|
|
|
✓ |
- 群组权限
|
行为 |
Guest |
Reporter |
Developer |
Master |
Owner |
|
浏览组 |
✓ |
✓ |
✓ |
✓ |
✓ |
|
编辑组 |
|
|
|
|
✓ |
|
创建项目 |
|
|
|
✓ |
✓ |
|
管理组成员 |
|
|
|
|
✓ |
|
移除组 |
|
|
|
|
✓ |
默认保护master分支，可使用正则表达式保护分支。保护的分支不能进行push -f操作。
项目的可见性不能超出群组的可见性范围，项目或群组有三种可见性：
Private:私有，必须配置权限才可进行访问。
Internal:内部，必须进行帐号密码登录后才可进行访问。
Public:公开，所有人都可进行访问。
定期清理已离职或调出项目的成员权限
<暂无>
<暂无>
本公司采用git flow工作流模式进行分支管理。
图 3-1 git flow工作流程图
- 主分支master
代码库应该有一个、且仅有一个主分支。它是自动建立的，一般默认此分支是被保护的，版本库初始化以后，就是在主分支在进行开发。此分支除第一次进行原子提交推送外，只能接收其它分支合并，任何人不能直接在master分支上进行修改和提交。
- 开发分支develop
用于日常开发，存放最新的开发版的一个主要分支。不管是要做新的feature还是需要做bug fix，都是从这个分支分出来做。在这个分支下主要负责记录开发状态下相对稳定的版本，即完成了某个feature或者修复了某个bug后的开发稳定版本，开发完成需要提交测试的功能都必须要合并到该分支。
- 辅助分支
feature: 开发新功能的分支, 基于 develop, 完成后 merge 回 develop。
release: 准备要发布版本的分支, 用来修复 bug. 基于 develop, 完成后 merge 回 develop 和 master；
hotfix: 修复 master 上的问题, 等不及 release 版本就必须马上上线. 基于 master, 完成后 merge 回 master 和 develop。
1.配置管理员在建立仓库时创建一个master分支和develop分支。
2.开发人员根据开发的功能点从develop分支创建一个feature分支，当功能点开发测试完毕之后，就会合并到develop分支去，可以将feature分支删除。
3.当需要发布一个版本来测试时，开发人员从develop分支创建一个release分支来测试。
4.正式发布后，过程中出现bug,从master分支创建一个hotfix分支，修补结束以后，再合并进master和develop分支。
- 主干分支:master
- 开发分支:develop
- 创建特性分支，名称要以f-开头，加上特性名
- 创建发布分支，名称要以r-开头，加上预发布版本号
- 创建Bug修复分支，名称要以b-开头，加上Bug号
- 创建标签：
- 当软件包发布到UAT环境时要在release分支上打标签，名称要以发布版本号加上RC1，RC2等结尾。
- 当软件包发布到正式环境后要在master分支上创建标签，名称要以发布版本号加上REALESE结尾。
为了规范代码库分支管理和版本管理，使代码分支及版本结构清晰，方便维护，并避免由于维护造成的错误的版本发布等问题。
由对应分支修复的实际开发人员提交或合并到开发分支，开发负责人需要进行判断是否需要合并，并协助解决冲突代码。提交的信息必须按照代码提交模板规定来书写。
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. 同步远程仓库代码，和远程仓库进行代码合并。
2. 将分支工作区修改的代码和提交描述等提交到开发分支。
3. 开发负责人对提交的分支代码进行审核和合并，并解决冲突。
4. 同步到主分支上。
pull同步工作区，找到冲突文件，解决冲突重新提交。
标识、控制和追踪软件开发和实施过程中产生的各种软件产品版本。
<主版本>.<次版本>.<增量版本>-<SNAPSHOT>
主版本：标示项目的重大架构变更。
次版本：表示重大Bug的修复，较大范围的功能增加和变化。
增量版本：一般标示一些小的bug fix，不会有重大的功能变化。
SNAPSHOT：快照版本，只能用于开发阶段对内发布，对外发布时不允许出现SNAPSHOT版本。
eg：1.3.4-SNAPSHOT
【1】代表该版本是第一个重大版本；
【3】表示这是基于重大版本的第三个次要版本；
【4】表示该次要版本的第四个增量版本；
【SNAPSHOT】表示此版本为快照版本；
版本号的修改由开发人员根据以上规则进行更改。
-
- 软件产品包版本管理
预发布环境：V主版本号.子版本号.增量版本号_日期版本号(yyMMdd)_阶段版本号
如：V2.15.0_190108_RC1
正式环境：V主版本号.子版本号.增量版本号_日期版本号(yyMMdd)_RELEASE
如：V2.15.0_190108_RELEASE
主版本号：当功能模块有较大的变动，比如增加多个模块或者整体架构发生变化。此版本号由项目决定是否修改。
子版本号：当功能有一定的增加或变化，比如增加了对权限控制、增加自定义视图等功能。此版本号由项目决定是否修改。
增量版本号：一般是 Bug 修复或是一些小的变动，要经常发布修订版，时间间隔不限，修复一个严重的bug即可发布一个修订版。此版本号由项目经理决定是否修改。
日期版本号:用于记录修改项目的当前日期，每天对项目的修改都需要更改日期版本号。此版本号由开发人员决定是否修改。
阶段版本号:此版本号用于标注当前版本的软件处于哪个开发阶段，当软件进入到另一个阶段时需要修改此版本号。此版本号由项目决定是否修改。
当软件包正式发布客户后需要配置管理员进行归档操作。
-
- 出包步骤
- 项目负责人通知项目组准备出包，同时给出出包时间点，如半小时后出包。
- 开发人员收到出包通知后，尽快将完成的代码进行提交到特性分支，并将特性分支代码合并到develop分支。
- 提交代码完成后，配置管理员基于develop分支拉release分支，并在构建时根据标签命名标准构造新标签号。如构建失败则通知开发人员在release分支上修改后重新构建。
- 通过maven和jenkins进行构建、打包和发布部署。
- 构建完成后通知相关人员。