git版本规范-前端

前言

本文档适用于前端的小伙伴。针对目前前端只有测试环境和生产环境，为更好管理前端代码和适用于自动化部署，编写次文档，有不同意见的小伙伴可以进行讨论。

分支

由于没有目前没有预发环境，简化开发、测试、部署和发布流程，暂时屏弃realease分支，新增develop-jenkins分支用于jenkins自动化部署。

平时开发中，注意先拉取合并代码后再提交！

注意经常性进行提交代码，而不是积累一天或者几天的代码量再一次性提交！

主分支：

• 命名： master-xxx
• 意义： 是发布到线上的代码版本，在主分支上会打上对应的版本号标签
• 维护者： 项目的主程、软件组长、专门维护线上版本人员
• 数量： 理论上只有一个，如果该项目面向多个渠道独立发布的，那就创建多个master

develop分支

• 命名： develop-xxx
• 意义： 团队开发合并和fork主要以此分支为准，开发过程中需要经常对develop进行合并
• 维护者： 如果有代码评审机制，那么在发送develop合并feature分支时，应该做代码评审。 维护者是整个开发团队。
• 数量： 与master分支对应

feature分支

• 命名： ft-xxx
• 意义： 团队成员开发具体需求时，需要从develop fork出一个特性分支，专门用来开发对应功能需求。 如果功能完成，测试人员可以针对该分支进行单独的功能测试，在禅道的任务中需要添加 的开发分支 就是这个特性分支
• 维护者： 当前开发此功能的研发人员

hotfix分支：

• 命名：fix-{bug编号}
• 意义：用于对线上的bug的修复或测试版本的bug修复
• 维护：对应开发人员
• 使用：bug的修复可以在feature分支中进行，如果是迭代周期内的bug推荐使用feature修复，并与develp分支合并。如果是线上的bug，那就从master分支fork出fix分支，使用fix进行修复，测试通过后，直接合并master分支，fix分支可以在之后的时间删除。

develop-jenkins分支（自动化部署分支）

• 命名：develop-jenkins
• 意义：团队开发部署合并主要以此分支为准，开发过程中需要经常对develop-jenkins进行合并
• 维护：对运维人员
• 使用：和develop分支一样都是同master分支拉取，再由develop分支合并

整体分支流程 

自动化部署分支流程抽离 

 

原则

1. 同一时间点,develop、develop-jenkins分支只能有一条,不允许多条分支并行
2. develop、develop-jenkins分支只能merge合入代码,不允许直接push代码
3. 当hotfix分支合并入到mastrer分支之前,hotfix分支必须得再次验证，纵使hotfix上的功能全都验证通过，此刻合入了master（hotfix肯定在生产上已经验证过），也得再验证一次.
4. 开发完成进入测试阶段，禁止直接develop分支直接合并到master分支，需将develop分支合并到develop-jenkins分支触发测试环境自动化部署，待测试环境测试通过后，再将develop分支合并到master分支。

介绍

1.系统开始之初,代表从master基线版本(v1.0.0)中,项目负责人拉取一条develop、develop-jenkins的长期分支,同时也是保护分支和构建部署分支

2. 当有一个或多个迭代版本要预期上线时候,开发人员要从develop分支拉取一个feature分支,取名feature/feature-20230319-1，拉取feature分支的时间点理论上来说是没有限制的

3. feature/feature-20230319-1分支可以包含此迭代周期里所有功能的合集,开发人员在此分支开发，一直在这条分支修复发现的bug

4. 这一步是整个流程中，可能是对项目负责人最多工作量的一个环节，开发人员向项目负责人提起合并到develop分支的诉求，项目负责人判断后，如果可以合入，则将此迭代分支合入到develop分支中，这个地方，对项目负责人考验最多的是两点：

• 第一点，合并诉求都会堆积在项目负责人这里，会造成工作量的压力
• 第二点，如果同一时间点有两条或多条feature分支都在并行，同时有合入develop分支的诉求，那么必须判断出，哪条或者哪些分支是需要延时合入。
  总的来说,合入develop分支的原则就是：1、多feature分支，认真判断先后合入顺序 2、一旦有feature分支合入develop分支，其他不在本次迭代上线的feature分支都不得合入develop
  develop一套分支代码会同时承载两个环境，一个dev环境供开发使用，一个test环境供测试使用，一定意义上能满足开发人员对其他新功能的依赖联调，另一方面，也能让测试人员有一个独立的环境来验证功能问题。

5.项目负责人根据当前迭代分支合并到分支develop-jenkins进行测试环境部署,并删除开发分支feature-20230319-1

6.如果测试环境有问题,从develop拉取hotfix/devBug-20230319分支进行bug修复，再由测试进行回归验证

7.如果测试环境没有问题，则项目负责人将develop合并到master分支，当合并到master分支进行自动化部署，运维部署成功后，测试开始在生产环境上进行冒烟测试，当发现有问题，通知开发人员，开发人员在hotfix/devBug-20230319分支修改，然后回到6的流程上，再重复的动作，最终生产环境验证无误后，由项目经理到master分支上打上这次迭代版本的tag：v1.0.1，并删除hotfix/devBug-20230319至此,一次完整的发布流程结束

8当生产确定无误后，也就不存在hotfix/devBug-20230319分支了，所以任何对生产的紧急修复，只能通过再次hotfix分支拉去来完成，这里强调，不是生产上有任何问题都必须走hotfix分支修复的，致命并且紧急的bug才能走hotfix分支，所以hotfix分支的创建是由项目负责人来创建的,分支名:hotfix/devBug-20230319，常规问题应该还是要走迭代去修复

9 hotfix的目的在于紧急处理线上问题，因此它不具备在另一个环境回归验证的过程，修复完，就要快速上线合并至master分支和develop分支，并且同时要看此刻有无hotfix/devBug-20230319分支，如果有,则需要额外合并入hotfix/devBug-20230319分支，develop-jenkins分支是否需要develop分支重新合并由项目负责人定，这是为了保证线上紧急修复的代码在hotfix/devBug-20230319分支中和develop中都不能疏漏的同时不影响测试环境正在测试的代码，当到master并且生产验证通过后，项目需要到master分支上打上这次hotfix的tag：hf20230319，最终删除hotfix分支。