这里使用 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命令即可.

对于 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若干权限问题