背景描述

最近在梳理一些项目，要求将所有版本管理工具统一迁移到GitLab上管理，有些前辈用了很多年SVN了，不太习惯用Git，还有些新来的小朋友刚毕业也没经历过完整项目，所以大致整理了一下Git的使用。

Git和SVN的差别

它们都是版本管理工具，对于现在的我来说，我更喜欢Git。Git和SVN的最大区别在于SVN是集中式管理，也就是所有代码都是存储在服务器，本地只保存服务器的副本在这基础上进行工作，非常依赖于中央存储；Git是分布式存储，中央仓库更多的感觉只是用来开发人员之间互相交互的一个公共区域，每个人本地都可以保留多个代码分支，进行切换工作，并且可以本地维护操作记录，而且Git提供了更多的功能，如暂存区，本地仓库，丰富的分支管理等功能。而且Git的管理工具功能更丰富，如GitLab可以用于日常工作交流，留痕等。

根据我使用的经验，如果是小项目，团队人数也比较少，版本管理要求不高的话，用SVN可以省时间和相应的学习成本，因为它比较好理解，而且安装使用都挺简单。如果项目比较大，或者比较复杂，安全性等方面有要求可以使用Git，它对分支管理功能更加强大，对复杂场景处理起来更加灵活，因为它功能多一些。

我们使用的Gitlab，所以就基于Gitlab总结一下，Gitlab官方文档 docs.gitlab.cn/ （ps：有人觉得不久一个gitlab嘛，还要翻文档，其实gitlab还是有不少好玩的功能的，而且还真是比svn复杂不少，只是平常没用上，看看文档可以长长见识）

规范

账号说明

安装Gitlab后，只有root账号也就是Administrator能够创建用户，分配权限等。

分组规范

操作人：Administrator。

如果是整个公司共用一个中央仓库，我们使用的Gitlab集群，一般会按照产品线或者部门进行分组，组名为产品领域或者产品名称。如：安全网关产线，路径为security_gateway。

然后指定一到多个Maintainer（产线领导），分组范围通常为私有，如果是公用文档库或者SDK可以设置为内部或者公开。

具体项目的管理由Maintainer（产线领导）进行管理，如果项目很多需要再分类需要对其进行建立二级分组进行细化（这个需要高版本的Gilab支持），我演示的Gitlab还不支持这个，新的有。

具体操作

产线通常互相不共享，设置为私有的，跨产线交互需要两边自己协商邀请，对每个一级分组指定一到两个Maintainer，通产为产品线的研发总监和产品总监，说白了就是这产线的头头。然后由Maintainer在分组下继续建立二级分组（这个需要高版本的Gilab支持），或者直接建立项目，具体看项目数量是否需要再进行分类。

仓库规范

操作人：Maintainer或者Administrator。

代码仓库的建立由管理员创建，当然普通用户也能创建，但是一般来说都是由负责人创建。

命名规范：项目名称一般为产品名称、业务名称。

人员权限管理

仓库人员权限：仓库人员统一由Administrator创建，这个看公司管理流程，如果公司信息化建设比较全面的话，应该在人员入职后就会从人力资源将人员信息推送到Administrator的工作待办中，或者直接打电话发邮件（推荐使用邮件这种，方便留痕）给Administrator创建人员。创建成功后Maintainer就可以将人员进行加入项目并设置角色。

角色	名称	说明
Owner	项目所有者	具备项目的一切权限
Maintainer	主程序员（维护者）	可以创建维护分支，但是不能删除项目，一般研发组长负责人设置该角色
Developer	开发人员	可以拉取代码，提交代码，创建分支等，普通开发人员就是这个角色
Reporter	上报者（测试人员）	可以克隆，拉取代码，但是不能提交，一般测试或者产品经理可以设置这个角色用于自动化工具部署版本
Guest	访客	可以创建issue、发表评论、不能读写版本库

具体操作

Administrator根据分组划分人员权限：在Administrator新建好人员后，就自动将其分为到具体组下面并设置相应角色，设置了之后该人员在这个分组下将具备所属角色的权限。

由仓库所有者添加人员到仓库：这种方式设置人员角色是更细粒度的设置，具体到某个仓库，设置成员在该仓库的角色，我们也是采用的这种方式，可以更好的控制仓库的权限外溢，如果一个人要在多个仓库中由具体仓库管理人员将其添加，这样能保证不同产品的人员看不到其它产品代码，保证其一个私有性。

分支版本规范

人员和仓库创建好了以后，接下来就进入了开发阶段，日常工作中最常用的阶段。

首先要对分支进行划分，方便对代码或者文档进行隔离，建立良好的分支规范可以有利于在各个环境保持隔离互不干扰，在需要使用的时候直接调取。

命名

分支的命名，可以按照路径层级命名，通常一级层级为几个核心主要的分支。

master或main【受保护分支】：主分支，稳定版本，生产版本，该分支的代码文件为当前产品正在运行的版本，只在代码发布到了生产环境后将代码合并到该分支。

develop【受保护分支】：开发分支，保存了当前整个项目团队最新的开发代码，该分支可以满足随时发布到测试环境，这里面的代码都是具备完整的功能，新来的开发人员也应该先从这个里面拉去代码。

release/版本号_时间：预发布版本，该分支主要用于在发布到生产环境之前部署到测试环境的版本，有的团队发布到生产要经历测试、预发布，那么该分支就有两个一个是test/版本号_时间代表了测试环境，release/版本号_时间代表了预生产环境，我们上线前只需要一个环境测试，所以这个分支即是测试分支也是预发布分支。

feature/功能点，feature/开发人员：个性化分支，也是平常我们开发人员大多数工作的时候分支，该分支主要用于我们日常开发，有的是按照feature/功能点进行区分，有的是按照开发人员区分。如：feature/order，该分支主要用于订单模块开发，feature/zhagnsan，该分支主要由zhangsan在进行开发。这个区别于项目团队的大小，比如你们人员只有三个人，那么直接每个人一个分支，然后将功能直接分给他就可以了用于所谓的“敏捷开发”就是领导说一个功能你就整，别浪费那么多时间建功能分支合分支啥的了；但是如果项目很大，比如一个订单模块需要十个人开发，那么就应该采用feature/order这种方式创建订单，并且该分支由多个开发人员共同开发。

hotfix/bug号：用于修复线上的bug，这个分支的工作一般都比较紧急了，bug号取决于你们使用什么项目管理工具，比如禅道就有对应的编号，根据编号直接去禅道查询bug详情，然后修改。

bugfix/bug号：修复普通的bug，该分支可以从develop分支或者测试过程中的release分支中创建，修复完成和合并到对应的原始分支即可。

使用

组长（仓库管理人员）

• 基于master创建develop分支，两种方式：本地或网页端。
• 设置develop分支为受保护分支，master默认就是受保护的。
• 处理分支合并到develop和master，偶尔也会发布release分支。

受保护分支

受保护分支指的是，被设置后，该分支只允许指定角色进行推送和合并到该分支，一般角色设置为Maintainer，就是不允许随便修改该分支，但是是可以拉取该分支的代码的。

开发人员

• 基于develop创建 feature开发分支或bugfix分支。
• 基于release创建bugfix分支，基于master创建hotfix分支。
• 发起分支合并请求。

测试产品人员

• 负责基于develop发布release分支，用于测试，我们一般都是由团队开发人员自己就发布了，没有让测试人员发布。
• 通过DevOps部署release分支到测试环境，进行测试。这一步，通常也是由我们开发人员自己就搞了。

代码提交规范

代码提交，需要写清楚本次提交内容，主体分为：类型，标题，内容，备注。

如：

-fix：修复xxx功能，xxbug 【类型：标题】

由于线程池配置错误，导致任务阻塞不能及时处理，现将任务改成异步处理，并增加状态查询。【内容】

1325【备注（bug编号）】

类型： 具体可以按照项目开发过程添加。

名称	命名规则
feat	完成新功能
fix	解决bug
docs	文档变更
refactor	重构代码
perf	性能、页面优化
test	增加测试用例、单元测试
revert	回退版本
build	打包
chore	构建过程或辅助工具的变动

版本号规范

版本号分为主版本号.次版本号.修订版本号。

如：

• 1.0.0：软件的初始版本。
• 1.1.0：向后兼容的新功能添加。
• 1.1.1：针对1.1.0的修复或安全补丁。
• 2.0.0：重大更新或重构，可能引入了新功能，同时也移除或修改了某些旧功能。