简述
目前整体项目由多个模块构成，多个开发小组协同开发。在目前的管理流程中，存在一些痛点，在这里对几个比较重要的痛点进行分析并且探讨解决办法。
痛点和解决办法
1、分支众多且管理混乱
问题描述
1、目前分支采用开发、测试、生产分别管理的形式。各小组在自己的开发分支上提交commit，然后分别推到对应的dev、test、main分支。导致三个环境代码可能不一致，存在某些代码在生产环境有，测试环境没有的情况。
2、在同步本地代码的时候，存在将他人不准备发布生产的代码同步在本地，然后误合入生产环境的情况，无法可控地管理线上环境。
3、操作繁琐，每次推新的代码，每个人都需要重复做合并dev、test、main分支的操作，增加开发人员的时间成本。
解决办法 - gitlab flow工作流
gitflow、gitlab flow工作流 : https://cloud.tencent.com/developer/article/1646937
Gitlab flow 是 Git flow 与 Github flow 的综合。它吸取了两者的优点，既有适应不同开发环境的弹性，又有单一主分支的简单和便利。它是 Gitlab.com 推荐的做法。
Gitlab flow 的最大原则叫做”上游优先”（upsteam first），即只存在一个主分支master，它是所有其他分支的”上游”。只有上游分支采纳的代码变化，才能应用到其他分支。
优势
1、对于开发人员以及管理人员来说，只需要管理合入上游分支的每个merge request 的commit是当前版本需要的代码，然后根据整体发布流程选择时间从开发合测试，从测试合入生产环境，操作简单，管控方便，并且各个环境分支代码可控。
2、大量冗余Commit，描述可读性差
问题描述
目前repo里有大量因为merge产生的commit，可读性差，很难找到某个功能对应的commit，对于问题代码的定位和控制合入分支代码有极大的阻碍
解决办法-rebase操作
git中merge 和 rebase 的区别：https://developer.aliyun.com/article/652579
merge 是合并的意思，rebase是复位基底的意思。merge操作会生成一个新的节点，之前提交分开显示，导致上图所见的冗余commit。而rebase操作不会生成新的节点，是将两个分支融合成一个线性的操作，非常明了，能够很快定位到每个功能对应的commti
优势
使用rebase的方式合并，不会产生新的commit。所以每次查看分支代码的时候，能够明确的找到哪些功能的commit合入了分支，方便排查问题。
3、版本代码无法回退
问题描述
目前生产环境的代码直接从main分支拉取，如果有误合入main分支的代码，很难实现版本回退操作，导致线上环境不稳定。
解决办法- git tag & revert操作
Git tag 官网：https://git-scm.com/book/zh/v2/Git-%E5%9F%BA%E7%A1%80-%E6%89%93%E6%A0%87%E7%AD%BE
像其他版本控制系统（VCS）一样，Git 可以给仓库历史中的某一个提交打上标签，以示重要。 比较有代表性的是人们会使用这个功能来标记发布结点。
在每次代码都合入main分支后，通过打 tag的形式打包代码并且生成镜像，再将这个带有tag信息的镜像发布到生产环境。如果误合入代码或者发布的版本有问题，可以直接使用上一个tag的镜像文件，实现版本秒回退，维持线上环境的稳定。
如果单个commit需要回退。可以通过revert的形式生成一个新的commit，将之前修改的代码修改回去，再通过发布流程合入一个个的节点。
优势
版本回退速度快，操作简单，线上环境出问题可以做到秒回退
commit回退操作性强并且简单
4、前端不清楚当前线上版本
问题描述
当前前端没有任何版本信息，不清楚目前前端的代码是否是repo里最新的代码。当出现疑惑之后，只能通过重新发版的问题解决，造成大量的时间消耗。
解决办法-前端页脚添加版本信息
在上述的tag方式下，可以在前端添加当前版本信息。如0104版本或者0103版本。如果当前前端版本与最新tag不一致，可以迅速排查。
