GitLab分支管理在日常工作中的落地

1.前言

  本文是笔者依据当前工作条件编写，目前阶段看具有普适性。但随着项目规模增长以及技术的迭代更新，往后看本文具有一定的时代局限性。所以各位读者按需取用，可在本文的基础上对其中内容加以改进，以便更好的去适应于自身所在公司项目分支管理。

2.基本概念介绍

2.1 开发环境（DEV）

  开发环境是程序员们在开发过程中进行对代码进行测试的服务器，为了自身测试方便，配置简洁、变更频繁。

2.2 测试环境（TEST）

  测试环境是测试人员对代码进行测试的服务器，配置较为正式，主要是用来对代码做白盒测试。

2.3 验收环境（UAT）

  UAT(User Acceptance Test)，用户接受度测试（即验收测试），是用来作为客户体验的服务器，配置与生产环境相同，但不连接生产数据库。

2.4 生产环境（PRO）

  生产环境是指正式提供对外服务的服务器，一般会关掉错误报告，打开错误日志。可以理解为包含所有的功能的环境，任何项目所使用的环境都以这个为基础，然后根据客户的个性化需求来做调整或者修改。

3.简介

  Git是一个开源的分布式版本控制系统，可以方便相关管理员对项目材料进行版本管理。

4.基本命令

命令	语义	示例
git pull [项目集合] [分支]	拉取指定代码集中指定分支的代码	git pull origin develop
git add xxx(文件名)	向工作缓存区添加待提交文件	git add *
git commit -m ‘本次提交内容注释’	将工作缓存区的内容提交至本地代码仓库	git commit -m ‘Issue:3359 修复后台界面查询效率过慢问题’
git push -u [项目集合] [分支]	将本地仓库代码提交至远端仓库	git push -u origin develop
git stash save ‘message’	暂存本地分支修改	git stash save -u ‘限制两个用户同时修改数据问题’
git merge 分支名称	将指定分支的代码合并到当前分支	git merage feature_20200407_IssueNum
git stash list	查看当前有哪些暂存内容
git stash pop stash@{$num}	将指定暂存内容应用到当前分支，并删除该暂存内容	git stash pop stash@{0}

注：在使用命令提交代码至远端仓库时，禁止使用git push -f origin develop强制提交。

5.常用分支介绍

  按分支存在周期划分为两种：长期分支 、短期分支。

5.1 长期分支

5.1.1 主分支（master branch）

• 该分支只有一个，用于存储正式发布的历史代码，向用户交付正式使用版本。
• 该分支是所有开发活动的核心分支，所有的开发活动产生的输出物最终都会反映到主分支的代码中。
• 该分支始终和生产环境保持一致。
• 该分支在每次commit之后需要打上Tag。
• 命名规则：
  • master（无需修改）

除分支管理人员外，禁止任何人擅自将代码提交至master或将分支合并至master
除分支管理人员外，禁止任何人擅自将代码提交至master或将分支合并至master
除分支管理人员外，禁止任何人擅自将代码提交至master或将分支合并至master

5.1.2 验收分支（uat branch）

• 该分支只有一个，用于项目第二轮集成测试（用户验收测试）
• 该分支始终和UAT环境保持一致
• 当该分支通过用户验收测试后，将代码合并到master branch，准备进行发版
• 命名规则：
  • uat（无需修改）

5.1.3 开发分支（develop branch）

• 该分支只存在一个，用于项目第一轮集成测试（测试人员测试）
• 该分支始终和开发环境保持一致
• 该分支不允许直接合并至master分支，仅做功能分支（feature branch）代码合并及自动构建测试包使用。
• 命名规则：
  • develop（无需修改）

5.2 短期分支

5.2.1 功能分支（feature branch）

• 该分支在每个迭代中可能并行存在多个，诞生于develop branch或uat branch。
• 该分支用于独立开发功能点，保证各功能点互不影响。
• 该分支在合并代码后删除。
• 命名规则：
  • feature-开发功能名称
  • ex：feature-用户登陆

5.2.2 补丁分支（hotfix branch）

• 该分支是最不希望出现的分支，用于线上问题紧急修复。
• 该分支诞生于master branch。
• 在问题修复后，该分支合并至master branch、uat branch、develop branch后删除。
• 命名规则：
  • hotfix–bug描述
  • ex：hotfix–双用户并发操作异常

6.分支使用规范

6.1 代码合并问题

• 合并代码至公共分支时，请使用merge，勿使用rebase。
• 将公共分支代码合并至个人开发分支时，使用rebase、merge均可，但推荐使用rebase，这样可以将自己的修改放在主线修改的头上。

6.2 冲突解决

• 当merge或rebase过程中产生冲突，请优先使用他人版本覆盖，请勿强制提交本地修改至分支，导致他人功能异常。

6.3 项目分支图解（重要）

1. 当需要进行新功能或新需求开发时，依据develop branch创建feature branch。如图：
   

2. 当feature branch完成开发并自测后，将代码merge至develop branch，然后删除feature branch(用完即删)，develop branch将会自动打包部署至开发环境供测试人员进行测试。如图：
   

3. 当测试人员在develop branch完成测试后，分支管理员将develop branch代码合并至uat branch，进行用户验收测试（uat 测试）。如图：
   

4. 用户验收测试通过后，将代码合并至master branch进行构建发布并打上Tag标签。如图：
   

  以上为项目在集成测试、验收测试中均一次性通过的流程图解。但在日常开发中，必然会因思考不周全或对需求理解不透彻而出现bug或返工，那么这个时候，要怎么去管理分支呢？接下来我们对项目分支异常流进行一个图解。

1. 在集成测试时出现bug。
   • 这个时候需要以当前develop branch为基准，创建新的feature branch进行bug修复。
   • 完成修复并自测通过，将代码集成至develop branch。
   • 测试人员测试通过，将代码集成至uat branch。
   • 用户验收测试通过，将代码集成至master branch打包发布，并打上Tag标签。
   • 整个过程如图所示：
     
2. 在用户验收测试时出现bug。
   • 这个时候需要以当前uat branch为基准，创建新的feature branch进行bug修复。
   • 完成修复并自测通过，将代码集成至uat branch。
   • 交由测试人员进行测试。
   • 测试人员通过，进行用户验收测试。
   • 用户验收测试通过，将代码分别集成至develop branch、master branch，并在master branch打包发布，并打上Tag标签。
   • 整个过程如图所示：
     
3. 在线上运行时，突然爆出一个bug。
   • 以master branch为基准，拉出一个hotfix branch，对bug进行修复。
   • 完成自测并通过测试人员测试，将代码分别集成至develop branch、uat branch、master branch后删除hotfix branch，并对master branch打Tag，打包发布。
   • 如图：
     

6.4 多人协作问题

  由于之前并未对多人协作以及分支管理作出明确规范，故现存在多人协作修改同一模块的不同bug时分支混乱的情况，所以现需要对分支在多人协作情况下的使用作出明确规范，以提高资源利用率，避免在此类无意义的问题上浪费时间。

6.4.1 多人协作修改同一个模块的不同bug（非线上bug）

1. 分支创建及使用

• 以develop branch为基准，由当前该问题负责人拉取一个feature branch（请注意命名规范）
• 相关人员使用同一分支进行修复

2. 分支代码提交

• 若修改功能耦合度较高，那么提交前请在群中知会相关同事，错时提交。
• 若提交时产生冲突，请勿强行提交覆盖分支代码，优先使用他人代码覆盖自己代码。
• 所有人提交完成后，当前问题负责人通知在该分支开发的所有人，进行自测，确认自己所负责代码块是否正常运行，需检查以下几点：
  • 代码是否可以正常编译
  • 代码是否可以正常启动
  • 流程是否可以跑通
  • 数据是否正确落库
  • 落库数据是否正确

3. 自测完成后，当前问题负责人将代码合并至develop branch，并删除feature branch

4. 提测

   流程如图所示：
   

6.4.2 多人协作修改同一个模块的不同bug（线上bug）

1. 分支创建及使用

• 以master branch为基准，由当前该问题负责人拉取一个feature branch（请注意命名规范）
• 相关人员使用同一分支进行修复

2. 分支代码提交

• 若修改功能耦合度较高，那么提交前请在群中知会相关同事，错时提交。
• 若提交时产生冲突，请勿强行提交覆盖分支代码，优先使用他人代码覆盖自己代码。
• 所有人提交完成后，当前问题负责人通知在该分支开发的所有人，进行自测，确认自己所负责代码块是否正常运行，需检查以下几点：
  • 代码是否可以正常编译
  • 代码是否可以正常启动
  • 流程是否可以跑通
  • 数据是否正确落库
  • 落库数据是否正确

3. 自测完成后，将当前分支打包部署交由测试人员测试
4. 测试人员测试通过后，由当前问题负责人分别合并至develop branch、uat branch、master branch，并在master branch打上Tag，由master branch打包发布。

过程如图所示：

6.4.3 多人协作修改同一流程不同模块的业务

  这种情况下开发人员拉取分支独立开发，在开发完成后与流程上下方进行一个联调，以确保上下游数据产生以及处理通畅无误。具体流程请参考6.3 项目分支图解。

PS：若大家有什么想法或建议，可在评论区向我留言，我会积极向各位大佬学习并改进！！！感谢！！！