标签：idt 策略 手工 ast release 分类 合并 issue review
这里使用 gitlab 做服务器, 客户端主要使用 git extensions.
=============================
gitlab 项目成员类型:
=============================
1. guest : 能在 gitlab 网页上创建 issue, 查看 wiki
2. reporter: 权限比guest更大, 能 clone 项目
3. developer: 能commit代码
4. maintainer: 能进行项目成员管理, 能进行分支保护管理
5. owner: 能删除项目, 能删除 issue.
=============================
gitlab 项目可见性
=============================
新建项目首先要选定项目的可见性, 有如下几种分类:
1. private -私有项目, 企业内的项目一般都选这个类型, 只有项目组成员能访问
2. internal- 内部项目, 只要具有登录权限的用户都能看到代码
3. public -公开项目, 不需登录即可 clone 代码.
=============================
分支策略管理
=============================
| 分支名 | 分支类型 | 是否为保护分支? | 分支链路 | 描述 | 作用 |
| master | main类型分支(长久分支) | 保护分支 | release-xxx => master | 这个分支的代码即为当前生产环境的代码 | |
| develop | main类型分支(长久分支) | 如果要加入code review环境, 应该将这个分支设为保护分支,否则为非保护分支 |
初始化时来源于 master, 日常: feature-xxx => develop |
这个分支始终保留着最新的开发代码, 阶段性地合并 feature 系列分支 | |
| feature系列分支 | supporting类型分支(短生命周期) | 非保护分支 | develop=>feature-xxx=>develop |
每个人领feature任务, 为该任务建立一个feature分支. 命名规范应该时候 feature-xxx, 分支开发完毕要合并到develop分支. 开发人员平时应该在feature系列分支上工作, 假设下个大版本中包含5个feature, 只有这5个feature都合并到 develop 之后, 才能合并下下大版的feature. |
|
| release系列分支 | supporting类型分支(短生命周期) | 非保护分支 | develop=>release-xxx => (master和develop) | 当 develop 分支完成了预期feature的合并, 就可以对 develop 做快照, 生成一个 release 分支. develop 分支可以继续演进. release 编译之后要进行QA+UAT测试. QA和UAT中出现的bug,也是也要在这个分支上解决. 所有问题解决后, 就正式发版, 需要及时合并到 master 分支, 并对master分支打 tag. 然后要合并到 develop 分支, 因为develop分支可能已经要修改, 所以需要手工解决代码冲突. | |
| bugfix系列分支 | supporting类型分支(短生命周期) | 非保护分支 | master => bugfix-xxx => (master和develop) | 当线上有bug, 应基于master生成bugfix-xxx 分支, 解决了该bug后, 要merge 会 master, 并为master打tag. 然后在merge 会 develop 分支, 并删除该bugfix分支 |
对于 feature/bugfix/release系列分支, 可以考虑定期将那些结束了很长时间的分支及时删除, 历史分支太多会加大管理负担.
feature 系列分支的命名规范应该为: feature-大版本-功能名
release 系列分支的命名规范应该为: release-大版本
bugfx 系列分支的命名规范应该为: bugfix-bug名
master 分支上的每次变更,都应及时打上 tag
标签：idt 策略 手工 ast release 分类 合并 issue review
原文地址：https://www.cnblogs.com/harrychinese/p/gitlab.html
