GitFlow内部规范

http://Git工作流

主分支：

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

develop分支

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

feature分支

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

realease分支：

• 命名： release-xxx-vxxx
• 意义： 当一个迭代需要完成的功能已经合并到develop， 确定要对这些功能进行发布，从develop中fork出realease分支，中间xxx与master和develop的后缀对应，后面是版本号。
• 维护者：研发团队
• 使用： 内网测试是建立在此分支上的，release分支创建完成后不再接受功能级别的合并，仅支持测试出现的bug修复的合并。当测试完全通过后，与master合并，建立版本tag，准备发布。
• 合并规则： fix分支、feature分支、develop分支

hotfix分支：

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

例子

假设haier项目中增加一个添加菜单功能，版本号为0.1，禅道bug编号为4192.

1、主分支：

• 命名为master-haier：

1. 有bug：见5.1
2. 无bug：发布线上。

2、 develop分支：

• 从master-haier中继承一个分支命名为：develop-haier
• 每次master-haier有更新，都合并到：develop-haier分支。

3、 feature分支：

• 从develop-haier中fork一个分支命名：ft-addMenu。
• 添加菜单功能开发完成后，测试人员对ft-addMenu分支进行测试。

1. 有bug：见5.3
2. 无bug：合并到develop-haier，删除ft-addMenu分支。

4、 realease分支：

• 在ft-addMenu等功能合并到develop-haier后，从develop-haier中fork一个分支，命名为：realease-haier-v0.1。
• 内网测试在此分支上进行。

1. 有bug：见5.2
2. 无bug：合并到master-haier上，删除realease-haier-v0.1分支。

5、 hotfix分支：

• 命名规则：fix-4192。

5.1 线上bug：

• master-haier中fork出realease-haier-v0.1和fix-4192分支，fix-4192修复后合并至realease-haier-v0.1，进行内网测试。内网测试通过后，realease-haier-v0.1合并到master-haier上，发布线上。

5.2 内网测试bug：

• 建立fix-4192分支，修复后合并到realease-haier-v0.1。

5.3 feature bug：

• 在ft-haier上建立分支fix-4192分支，修复后合并至ft-haier分支。

开发记录

项目代码中建立gitbranch.md 文件，用来记录每次人员开发对分支的使用，特别的feature分支，需要经常更新

## master分支：
- master-main ： 云平台软件的主分支## develop分支：
- develop： 云平台软件的主开发分支## feature分支：
- ft-wall-rotateinfo: xxx 墙体旋转信息与ruler冲突

作者：GhostDou
链接：https://www.jianshu.com/p/7a9b2771b04c
来源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

现状

1. 有独立的环境且多人共同使用，开发环境、测试环境、预发环境
2. 线上分支master没有保护起来，分支缺乏严格的管理策略

1. 缺乏有效的CodeReview机制

分支策略：一个环境一个分支

• master：线上环境分支，永久分支，Protected
• prepub：预发分支，和master保持同步，永久分支，Protected，可以删除

• dev-test：开发测试环境分支，可以删除
• feature/*：功能分支，可以删除

• fix/*：修复分支，可以删除

“可以删除”理解为当该环境无人占用，可以删除分支，重新从master或者develop拉取代码新建分支。

流程

优点：

• prepub分支的代码必须是下一个版本发布的代码，代码提交到prepub时必须MR，并且CR。
• 多人并行开发时开发环境和测试环境互不影响

缺点：

• 如果当前prepub的代码临时决定下一个版本不发布，则重新在prepub进行下一个版本功能的MR。

开发环境合并流程

预发环境合并流程

线上环境合并流程 

线上环境合并流程-紧急BUG 

备注：1.2.1由合并MR的人进行操作，测试在bugfix上线回归确认prepub是否合并了bugfix的代码。 

参考流程

流程中有些和上述不太一致的地方，具体根据场景定夺

一、代码分支一览

二、原则

1. 同一时间点,release分支只能有一条,不允许多条release分支并行
2. develop分支只能merge合入代码,不允许直接push代码
3. 当hotfix分支合并入到release分支的时候,release分支必须得再次验证，纵使release上的功能全都验证通过，此刻合入了hotfix（hotfix肯定在生产上已经验证过），也得再验证一次，才能把release合并到master里

三、介绍

① 系统开始之初,代表从master基线版本(v1.0.0)中,拉取一条develop的长期分支,同时也是一条保护分支

② 当有一个或多个迭代版本要预期上线时候,项目经理要从develop分支拉取一个feature分支,取名feature/20181115-1，拉取feature分支的时间点理论上来说是没有限制的，但是项目经理也要结合实际情况，合理判断拉取feature分支的时间点

③ feature/20181115-1分支可以包含此迭代周期里所有功能的合集,开发人员在此分支开发，在release分支没有诞生之前，一直在这条分支修复发现的bug

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

• 第一点，合并诉求都会堆积在项目经理这里，会造成工作量的压力 
• 第二点，如果同一时间点有两条或多条feature分支都在并行，同时有合入develop分支的诉求，那么必须判断出，哪条或者哪些分支是需要延时合入的当release/1.0.1分支拉出来之后，下一次迭代需要上的feature分支，才可以继续正常合入develop分支了
  总的来说,合入develop分支的原则就是：1、多feature分支，认真判断先后合入顺序  2、一旦有feature分支合入develop分支，其他不在本次迭代上线的feature分支都不得合入develop，直到拉出release分支为止
  develop一套分支代码会同时承载两个环境，一个dev环境供开发使用，一个test环境供测试使用，一定意义上能满足开发人员对其他新功能的依赖联调，另一方面，也能让测试人员有一个独立的环境来验证功能问题，再一个，把后续release分支诞生后各种冲突出现的情况，提前暴露在develop分支上。

⑤ 当迭代功能测试通过后，项目经理根据当前迭代分支创建一个新的分支,取名release/1.0.1，创建完成后,删除功能迭代分支feature/20181115

⑥ 由测试人员通过jenkins构建release/1.0.1分支对应的环境,相当于pre环境,测试人员在此环境上进行联调,如果有问题,开发人员直接在此分支上进行修改，再由测试进行回归验证

⑦这一阶段，是项目经理按需判断是否要做的，因为有可能会碰到这样的情况，在release阶段发现并修复的问题，来不及等到要上到生产后再合入develop，但是 此刻需要拉新的一轮feature分支了并需要带着这个问题的修复，所以针对这种情况，所以 release的合入develop，并不是只有最终才可以合入，而是项目经理判断，按需，按时机来合入 ,当然release正式上线后，一定会合入，这里强调的是中间过程，是相对灵活的，是会有场景需要触发合入动作

⑧⑨ 当预生产验证无误后,可以发布到生产上,启动发布生产后,由项目经理开始把release/1.0.1分支的代码合并到master分支和develop分支，当合并到master分支后，等待运维部署，运维部署成功后，测试开始在生产环境上进行冒烟测试，当发现有问题，通知开发人员，开发人员在release/1.0.1分支修改，然后回到⑥的流程上，再重复⑧⑨ 的动作，最终生产环境验证无误后，由项目经理到master分支上打上这次迭代版本的tag：v1.0.1，并删除release/1.0.1,至此,一次完整的发布流程结束

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

⑪⑫ hotfix的目的在于紧急处理线上问题，因此它不具备在另一个环境回归验证的过程，修复完，就要快速上线合并至master分支和develop分支，并且同时要看此刻有无release分支，如果有release分支,则需要额外合并入release分支，这是为了保证线上紧急修复的代码在即将发布的release分支中和develop中都不能疏漏，当到master并且生产验证通过后，项目经理需要到master分支上打上这次hotfix的tag：hf201811071052，最终删除hotfix/201811071052分支