这里使用 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, 审核代码
=============================
参考
=============================