使用 gitlab 进行代码管理

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

=============================

分支策略管理

=============================

这里采用了 gitflow 的分支管理策略,  很多git客户端都提供 gitflow 插件, 我倒不推荐使用这些插件, 采用标准的新建分支/合并/创建tag命令即可.

分支名	分支类型	是否为保护分支?	分支链路	描述
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

=============================

tag管理

=============================

git extensions 创建tag的方法是, 在 commit history 区上选中任一个 commit后, 在右键菜单中都可以使用create tag 打tag了, 默认情况下, git push并不会上传 tag 到服务器上, 需要在push时打开上传 tag 选项

git extensions 左侧导航树默认仅仅显示local和remote的分支, 不显示tag, 可以打开那个显示tag的开关

=============================

code review 流程

=============================

基于 gitflow 管理, 最好的code review应该是在merge feature代码到 develop 的时候. 为了防治代码未经code review就被合并, 最好是将 develop 分支设置为保护分支. code review 的流程是:

1. 开发人员在 feature-xxx 分支开发完成后, push 代码到gitlab 服务器上

2. 开发人员在 gitlab 网页发起 merge request 请求, 可以指定 code reviewer , 也可以在描述区使用 @ 的方式抄送给其他人.

3. code reviewer登录 gitlab, 审核代码

=============================

参考

=============================

Git 在团队中的最佳实践--如何正确使用Git Flow

关于GITLAB若干权限问题