使用 gitlab 进行代码管理

Posted 2022-04-09 harrychinese

这里使用 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