Gitlab分支策略建议指南

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

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

环境说明

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

分支说明

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