基于gitlab适用于版本发布的git-flow团队开发协作规范

🌈慢慢的公司内部的项目逐渐增多，并且前期项目的版本发布相对来说比较频繁，为了更好的进行团队开发，定义了一套适用于版本发布的 git-flow协作规范，我大概整理了一下，大家可以借鉴一下。

名词解释

• LTS版本：Long Term Support长期支持版本，简称LTS。

• MR/PR：是Merge Request/Pull Request，我们常说的提PR的意思是开发人员在某个分支功能开发完了，需要发送一个请求，请求将某个源分支代码合并到目标分支，这个过程为了让项目组长/负责人进行code review（代码审查），check没有问题之后允许合并。

分支规范

一共拥有以下几个（种）branch：

分支	描述
master	master上的都是production-ready的stable的代码
develop	作为开发的主分支， 所有的merge操作都应该先合并到develop分支，再定期merge到master 发版
release-xxx	LTS版本需要有独立的branch，以作为后续（万一）hotfix使用，精确到minor version，如release-v1.2，为长期保留的分支。
feature/xxx	所有新的feature（如新功能、性能优化）都应当先checkout到一个新的feature分支开发，原则上必须且只能merge到develop分支
bugfix/xxx	bug的修复分支，原则上必须且只能merge到develop分支
test/xxx	test分支主要做以下三件事：1. 增加unit test；2. 修改仓库级别配置文件（如.gitlab-ci.yml）；3. 用来承载一些一次性的测试（最好不合并入develop）