关于gitlab:Gitlab-分支管理规范

Gitlab Flow

我的项目的分支状态为：

• master：主分支，用于寄存对外公布的版本，任何时候在这个分支拿到的，都是稳固的散布版；
• develop：开发分支，用于日常开发，寄存最新的开发版；
• feat-xxx <feature branch>：性能分支，一旦实现开发，它们就会被合并进 develop 或 master，而后被删除；
• hotfix-xxx<hotfix branch>：正式环境补丁分支，一旦实现开发，它们就会被合并进 develop 或 master，而后被删除；
• fix-xxx<fix branch>：开发环境补丁分支，一旦实现开发，它们就会被合并进 develop 或 master，而后被删除；

分支详解

master 主分支

代码库有且仅有一个主分支。提供给用户应用的正式版本，都在这个主分支上公布。每次公布打上 Tag 标签，如：0.1，0.2 或 0.3。

develop 开发分支

开发人员日常开发与功能测试分支。如果想正式对外公布，需在 Master 分支上，对 Develop 分支进行 “ 合并 ”（merge）操作。因为 Gitlab 中默认对 Master 设置了分支爱护(这个设置容许勾销, 如果存在多人开发的我的项目, 不倡议勾销)，所以，当须要合并到 Master 的时候须要在 Gitlab 里提交合并申请由我的项目管理员合并。

feat-xxx

• 性能分支属于临时性分支，个别合并完就会删除。它是为了开发某种特定性能，从 master 分支下面分进去。开发实现后，再并入 Develop 分支。
• 性能分支的名字，能够采纳 feat-xxx 的模式命名。

bug 分支

• 我的项目测试与正式公布之后，难免会呈现 bug。这时就须要创立一个分支，进行 bug 修复。

• bug 呈现环境不一样，可定义不同的 bug 分支。

  • 测试环境：从 develop 上新建分支为 fix-xxx；
  • 正式环境：从 master 上新建分支为 hotfix-xxx；

Gitlab 分支权限治理

权限类型

GitLib 有五种身份权限，别离是：

• Owner 我的项目所有者，领有所有的操作权限
• Master 我的项目的管理者，除更改、删除我的项目元信息外其它操作均可
• Developer 我的项目的开发人员，做一些开发工作，对受爱护内容无权限
• Reporter 我的项目的报告者，只有我的项目的读权限，能够创立代码片断
• Guest 我的项目的游客，只能提交问题和评论内容

分支治理标准

命名标准

提交内容标准

Git 每次提交代码，都要写 Commit message（提交阐明），否则就不容许提交。然而，一般来说，commit message 应该清晰明了，阐明本次提交的目标。提交标准设置为：” type:subject “

type

用于阐明 commit 的类别，只容许应用上面 7 个标识。

• feat：新性能（feature）
• fix：修补 bug
• style：格局（不影响代码运行的变动）
• refactor：重构（即不是新增性能，也不是批改 bug 的代码变动）
• test：减少测试

subject

subject 是 commit 类型的简短形容，不超过 50 个字符。

其余注意事项：结尾不加句号（.）

长处

• 可读性好，清晰，不用深刻看代码即可理解以后 commit 的作用。
• 为 Code Reviewing 做筹备
• 不便跟踪工程历史
• 让其余的开发者在运行 git blame 的时候想跪谢
• 进步我的项目的整体品质，进步集体工程素质

提交分支标准

• 禁止 向主分支间接提交代码，包扩代码仓库在线编辑批改。非凡状况（如版本号变更、CI 变更）除外；
• 禁止 提交测试性代码到任何主分支源码（src）目录，测试代码只能存在于测试（test）目录；
• 禁止 任何工作分支跨主分支提交代码，工作分支从只能合并到与工作分支同源的主分支；
• 禁止 在开发过程批改主分支版本号；
• 必须 在代码提交到主分支前删除未应用的 import 语句和格式化代码。
• 必须 备注每一次提交，代码备注必须简要可读。精确的形容具备可检索性；
• 必须 备注每一次合并申请，对合并申请蕴含的性能点简要形容。精确的形容具备可检索性。

开发流程治理

迭代开发流程标准

1. 总体组每周四制订下一迭代版本上线打算并确定迭代开发主分支版本号告诉到各核心（组）；
2. 各核心（组）责任人认领确认工作（截止周五），合成工作并下发开发人员，开发在新版本分支上开发；
3. 各核心（组）在周四前实现根本工作提交到迭代版本主分支交由测试组集成验证；
4. 测试组在集成测试分支打包测试，bug 提交到禅道治理，相干责任人及时认领并修复，同时告诉测试组回归测试；
5. 上线值日人需在每周四上班前确定最终我的项目版本并归档输入；
6. 各核心（组）责任人提交最终《数据库变更脚本》、《环境变更脚本》告诉到上线值日人；
7. 各核心（组）责任人提交《程序变更阐明》、《上线验证性能列表》到测试组；
8. 上线值日人须要负责生产环境 war 包公布和数据库变更；
9. 测试组根据《上线验证性能列表》验证生产零碎公布正确性；
10. 测试组验证无误根据《程序变更阐明》公布上线变更告诉。测试不通过告诉上线值日人回滚本次公布程序和数据库及环境变更；
11. 总体组确定延期公布打算；
12. 延期上线流程参照本章第五条至第十条执行；
13. 其余工夫未经批准禁止公布程序和变更数据库操作

线上 Bug 修复流程

1. 以线上版本 master 主分支为源创立 hotfix-xxx 的修复分支；
2. 在 hotfix-xxx 的修复分支进行集成环境 bug 修复并向线上版本主分支提交合并申请；
3. 核心（组）责任人负责代码审核，批准或者回绝本次合并申请；
4. 测试组依据最新代码在集成测试环境进行补丁修复验证；
5. 验证无误后将本次合并申请同时 cherry-pick 到集成迭代开发主分支；
6. 公布流程参照【迭代开发流程标准的第五条至第十条执行】；

测试 Bug 修复流程

1. 以集成测试主分支为源创立 fix-xxx 的修复分支；
2. 在 fix-xxx 的修复分支进行集成环境 Bug 修复并向集成测试主分支提交合并申请；
3. 核心（组）责任人负责代码审核，批准或者回绝本次合并申请；
4. 测试组依据最新代码在集成测试环境进行补丁修复验证；
5. 验证无误后将本次合并申请 cherry-pick 到迭代开发主分支；
6. 公布流程参照【迭代开发流程标准的第五条至第十条执行】；