Gitlab分支策略建议指南

本文分支策略为总结各中小型企业常见做法(仅代表个人观点)，在下才疏学浅，文章如有缺漏或不当之处，望各位帮忙指正。写此文也十分希望能起抛砖引玉之效。

据我所知，目前大部分无论是按瀑布/敏捷开发模型，就算服务器资源十分有限的情况下，一套相对标准的研发流程也都应该至少具有开发(DEV)/测试(TEST)/生产(PROD)三个环境(集群)。

环境说明

• 开发环境(DEV): 此服务环境一般为开发人员进行代码开发，单元自测，以及实验的稳定环境。
• 测试环境(TEST): 开发人员提交测试后，将相关代码，服务环境部署到此环境，由测试人员对此环境的服务进行专业性的二次测试，例如基准测试，安全测试，业务逻辑验证等等。
• 生产环境(PROD): 当测试环境得到充分的验证之后并满足发布生产条件，会将相关代码，服务环境部署到此环境，提供正式服务。

分支说明

• feature(-xx)： 功能分支，每个功能分支应该代表着每个固定的迭代或开发功能集版本。
• dev: 开发分支(保护分支)，每次推送(Push) 代码到此分支时，会触发固定流水线(pipeline)，部署应用到开发环境。
• test: 测试分支(保护分支)，每次推送(Push) 代码到此分支时，会触发固定流水线(pipeline)，部署应用到测试环境。
• main(master): 主分支(保护分支)，不允许直接进行推送(Push)操作，需要合并应当发起Pull Request(PR)，由负责生产环境的同事对此PR进行合并，此分支代码对应生产环境。
• hotfix: 紧急修复分支，俗称救火分支，当生产环境发生问题需要紧急修改代码时，由开发人员从main分支创建出来的新分支，在此分支上紧急修改代码后，合并到测试环境，测试验证通过后，直接发起Pull Request(PR)提交到main；此分支一般在紧急修复线上问题之后，可将其合并(merge)到dev，再将此分支删除。

单一功能迭代型分支策略

适用场景: 统一开发迭代版本，统一提测流程，统一上线流程

不适用场景: 多功能并行开发，多功能分别提测

适用人数：3-5人

流程图说明

• 开发 : 所有开发人员均在统一迭代分支(feature)上开发(包括修复bug)，在功能分支开发自测，单元测试无误后并需要进行接口联调时，合并(merge)到dev(开发分支)，触发开发环境持续集成过程。
• 联调 : 提交到开发环境进行前后端联调，当联调通过之后，按照约定时间进行前后提测(前后端可分别提测)，提测时，由开发人员将dev(开发分支) 合并(merge)到test(测试分支)上，触发测试环境持续集成过程。
• 提测 : 提交测试后，测试人员对测试环境进行验证，测试中产生的bug，开发人员应该在feature上面进行修复，然后统一按批次和时间进行重新推送(push)开发分支(dev)和合并(merge)测试(test)过程
• 上线 : 当测试环境代码已满足本次迭代所有功能，并且所有测试中产生的bug全部修复得到验证时，此时由研发负责人发起Pull Request (PR)test -> main提交到，并编写上线清单(包含上线数据脚本，外部依赖服务，上线配置细节等等)，通知负责生产环境的同事合并，按照上线约定时间和上线清单进行上线。
• 修复 : 当线上遇到需紧急修复的问题时，由开发人员从main分支创建出hotfix分支，在此分支上修改代码后，合并到测试环境，经过测试验证通过后由研发负责人发起Pull Request(PR)hotfix -> main，进行紧急修复上线流程。

说明: 此分支策略下，feature分支可以看作为开发人员熟悉的local分支，feature,dev,test均允许互相合并(merge)

多功能并行迭代型分支策略

适用场景: 多迭代版本并行开发，分别提测流程，分别上线流程，差异化上线

不适用场景: 多并行开发版本中有交叉内容。

适用人数：3-5人和20人以上

流程图说明

• 功能开发 : 开发人员按组在不同的对应迭代分支(feature-xx)上开发(包括修复bug)，在功能分支开发自测，单元测试无误后并需要进行接口联调时，合并(merge)到dev(开发分支)，触发开发环境持续集成过程；多功能分支可并行开发。
• 并行联调 : 提交到开发环境进行前后端联调，当联调通过之后，按照约定时间进行前后提测(前后端可分别提测)，提测时，由开发人员将feature-xx(功能分支) 合并(merge)到test(测试分支)上，触发测试环境持续集成过程。
• 并行提测 : 提交测试后，测试人员对测试环境进行验证，测试中产生的bug，开发人员应该在feature-xx上面进行修复，然后严格统一按批次和时间合并(merge)开发和合并(merge)测试(test)过程，以避免频繁发布造成测试环境不稳定。
• 功能上线 : 当测试已满足本次迭代所有功能，并且所有测试中产生的bug全部修复得到验证时，此时由研发负责人发起Pull Request(PR)feature-xx -> main，并编写上线清单(包含上线数据脚本，外部依赖服务，上线配置细节等等)，通知负责生产环境的同事合并，按照上线约定时间和上线清单进行上线。
• 修复 : 当线上遇到需紧急修复的问题时，由开发人员从main分支创建出hotfix分支，在此分支上修改代码后，合并到测试环境，经过测试验证通过后由研发负责人发起Pull Request(PR)hotfix -> main，进行紧急修复上线流程。

使用注意

• 此分支策略下，dev作为开发环境公共验证分支，test作为公共提测分支，feature-xx分支作为主要并行开发使用分支 ，最终会直接PR到main(主分支)， 开发人员务必最大程度保证此分支代码的稳定。
• 务必禁止开发人员对dev和test进行相互合并(merge)；禁止任何从feature-xx -> main和hotfix -> main以外内容发起的Pull Request (PR)
• 所有feature-xx分支不可进行相互合并(merge)
• 所有feature-xx分支在整个开发测试上线期间应该观察main分支上的变化,及时将main的最新变化合并过来

个人建议的Git提交规范

Gitlab 提交(commit)遵守 title:message 格式规范

例如 :

optimize:重构EbayClient,清除代码中存在的大量warns

chore:修改根据sku查询采购信息feign

fix:修复禅道上的BUG#1906

major:引入JSR303验证标准库;统一出参规范,新增全局异常Advice,新增错误码RespCode

test:新增EbaySellInventoryClient单元测试类

upgrade:easyexcel的version从2.2.7升级至3.1.1

提交title说明

title	说明
chore	日常杂活,开发工作内容，通常是CRUD等等
major	主要/重要提交,和项目整体有关,例如底层架构代码,核心功能,重要公共类等等
optimize	优化,重构代码
fix	日常修复开发/测试环境的bug,issue等问题
hotfix	紧急修复生产环境的BUG，,issue等问题
upgrade	项目升级,版本依赖升级等等
update	仅仅是不重要的更新
test	仅仅是修改的单元测试内容
feat	一次完整的特性/功能提交
CI/CD	持续集成流程