以Gitlab代码托管平台说明，也是目前应用最为广泛的企业搭建私服的选择。
1. 权限管理
[项目] 访问权限有3种：：Private、Internal、Public
Private：只有组成员才能看到
Internal：只要登录的用户就能看到
Public：所有人都能看到
[项目成员] 有五种权限及其适用对象：Guest、Reporter、Developer、Maintainer、Owner
Guest：可以创建issue、发表评论，不能读写项目 【游客】
Reporter：可以克隆代码，不能提交 【QA,PM】
Developer：开发者可以克隆代码,开发,提交,push 【RD】
Maintainer：管理员可以创建项目,添加tag,保护分支,添加项目成员 【RD组长】
Owner：最高权限,管理组成员,删除项目,迁移项目 【研发负责人】
2. 分支管理
2.1 基础概念：
版本冲突：合并分支时，当Git发现同一个文件中的同一块数据在两边的提交历史中都有变更,它将无法自动对其进行合并,产生冲突，需要人为介入修改，再合并。
# On branch master
一条合并命令：git merge featureA
两种合并方式：当执行merge命令时,git合并算法会根据当前分支(master)的最后一次commit与“特性分支”(featureA)的最后一次commit的情况，来决定合并方式是 “快进式合并” 还是 “递归三路合并”。
快进式合并：代码分支情况如下，默认合并方式为快进式合并，只是将master分支的HEAD指针右移，不会创建新的merge记录。
缺点：若版本直接回滚，只会回退到featureA的上一次commit节点，原master分支上可能仍遗留featureA的代码，回退不干净。
递归三路合并：代码分支情况如下，合并方式为三路合并，此时merge算法会递归向前找到两个分支的共同“祖先”节点，判断各自文件修改点作为合并内容，若无代码冲突均会自动合并完成, 产生新的merge记录。
[所以推荐] 使用参数 “--no -ff”
git merge featureA --no -ff #禁止快进式合并称为普通合并，各种情况下总会创建一个merge记录，方便追溯
若版本直接回退，直接回退到原始master指针节点。
2.2 研发分支过程管理
-
-
主干分支为master，dev-test为开发分支，test为测试分支，pre为预发分支， release为上线分支
-
每个一个需求为一个特性分支,命名为feature-XXX
-
特性分支开发过程中外部联调需要时合并至dev-test
-
特性分支开发完成后合并至test，提交测试
-
测试完成后合并至pre，进行预发测试
-
预发测试完成后合并至上线分支release-{date}, release-{date}由最新master派生
-
如果在测试期间出现BUG需要在feature分支修复，并合并至集成分支(dev-test, test, pre).
-
dev-test期间合并dev-test
-
test期间合并至dev-test, test
-
pre期间合并至dev-test, test, pre
-
release期间合并至dev-test, test, pre, release
-
-
线上出现Bug需要修复时等同一个需求走feature分支开发流程
-
2.3 常见分支问题
-
-
团队中新人可能是对Git不熟悉也可能是合并到集成分支 dev-test, test时冲突比较多想把dev-test,test代码合并到本地来解决，从而把别人开发功能的代码合并到自己的分支，上线时就把别人分支(不是本次上线的功能)上到正式环境了，导致线上事故。
-
git checkout feature-xxx
git merge test
-
-
在开发过程中Bug修复时一般需要在自己的特性分支修改代码，修改完成后再依次合并到dev-test, test, pre让测试验证是否修复完成，但有时图方便或是时间问题就直接合并到pre让测试验证， 这样测试环境上就带有bug。然后就有一种常见的情况，在测试环境回归功能又发现了此Bug，开发就纳闷修复过了为何还有，其实就代码没有合并。
-
git checkout feature-xxx # fix bug .. git checkout pre && git pull git merge feature-xxx # 没有合并至dev-test, test