企业级GIT分支管控方案_gitee保护分支

作者：Cpp五条 | 2024-05-26 06:33:06

踩

gitee保护分支

GIT如今被广泛应用于企业开发项目托管，随着我们项目规模的扩大，开发人员的数量也逐渐扩增，呈现出不同的开发等级，而不同的等级，也需要不同的权限管控。

如果没有做好代码分支的管控，就会导致发布新功能时，将还未测试好的功能也一起发布的，导致严重的线上问题。而分支管控的概念就在于，同时开发新功能时，不同功能的代码存放到不同的地方，形成代码隔离，发布时从指定地方的代码发布，还没有经过测试的代码就不会错发，因为两个功能的代码根本不在一个地方。当另一个功能发布时，再将其和之前已经测试好的功能代码合并，这样既保证不会错发未经测试的代码，也保证后发布的代码包含了已经测试的功能

所以今天，我们来聊一聊，企业git的管控

1. 权限等级

首先我们需要明确项目开发中需要涉及的权限等级：

权限等级	描述	赋权角色
项目创建者	项目创建者拥有项目的最高权限，包括删除项目、管理成员、设置权限，一般由开发组leader来创建项目	开发组leader
项目管理员	项目管理管理员除了删除项目和清空项目外，拥有其他的全部权限	团队leader、运维管理人员
项目主开发者	项目主开发者可以添加tag，管控分支、添加项目成员，核心开发人员可以赋予该权限，一般拥有master分支的管控权限	核心开发人员
项目开发者	项目开发者拥有项目代码拉取、开发、提交等权限，一般将权限赋予研发人员，但需要注意的是要针对分支做好把控，这点我们后面详细讲解	研发人员
项目观察者	项目观察者可以克隆代码，但是不能提交	品质保证（OA）、产品经理（PM）
项目报告者	项目报告者只能创建issue、评论，不能读写代码，但在企业内部开发中很少用到该权限，因为一般有问题都会提在禅道等管理平台上	访客、测试

2. 分支管理

企业内部开发中，我们一般分成以下几种分支：

master分支

1、主分支，创建项目时即创建的分支，用于部署生产环境的分支，是所有分支的主干，与当前线上代码保持统一
2、由主开发人员、研发组leader管控、不允许其他开发在该分支上直接开发

tag标签

每次从master发布生产环境后，需要用tag标记一个版本，再master分支上的每个tag都对应历史的一个线上版本。方便后续追溯及复查代码

develop分支

1、开发分支，开发者各类开发功能的合并分支，即当前最新功能的分支。
2、开发人员会将自己开发的功能分支提交到dev分支上，由主开发人员来进行审核，通过后合并到dev分支上，一般测试环境就是从develop分支拉取代码
3、不允许开发者在该分支上直接开发

feature分支

1、功能开发分支，需要开发新功能时，每个开发者以develop分支为基础，从dev或master分支拉取代码，并创建新的feature分支，比如开发者ben，那么就拉取并创建新的分支feature-ben。
这里存在一点分歧，有的推崇从master拉取feature，有的推崇从dev拉取feature，两者各有优劣：从master拉取，这样能保证与生产环境一致，确保拉取的代码是‘干净’的。但存在的问题的dev如果有测试中的功能，并且与将要开发的功能有重叠的话，可能会导致代码冲突；所以衍生第二种方式：从dev拉取，好处是上述所说减少代码冲突，保证代码最新。开发完成后再合并到dev分支。如果测试周期较短，从master获取也没问题
2、功能开发完成后，就提交到develop分支上，由主开发者审核合并，功能开发完成后需要删除feature分支，下次开发时再冲突拉取创建
3、但需要注意的是，有的功能开发周期可能比较长，或者与其他功能的冲突率比较高，那么就需要定期拉取代码，避免长时间不更新代码，再次提交时出现较多的代码冲突。即使出现冲突，也能少处理一些。

release分支

1、发布分支，feature分支合并到dev分支后，准备发布新版本时，再创建一个新的release分支，分支名可以以功能名命名，比如release-user，允许存在多个release分支。
2、预生产环境从release分支拉取代码发布，如果出现bug就从release分支拉取bugfix分支进行修复，测试成功后，release分支合并到dev分支和master分支，并且删除release分支
3、release分支很多没有预生产环境的公司会选择忽略该分支，直接提交到master分支进行发布，这里也由大家根据公司情况进行选择
4、不允许开发者在该分支上开发