本文分支策略为总结各中小型企业常见做法(仅代表个人观点),在下才疏学浅,文章如有缺漏或不当之处,望各位帮忙指正。写此文也十分希望能起抛砖引玉之效。
据我所知,目前大部分无论是按瀑布/敏捷开发模型,就算服务器资源十分有限的情况下,一套相对标准的研发流程也都应该至少具有开发(DEV)/测试(TEST)/生产(PROD)三个环境(集群)。
Push
) 代码到此分支时,会触发固定流水线(pipeline
),部署应用到开发环境。Push
) 代码到此分支时,会触发固定流水线(pipeline
),部署应用到测试环境。Push
)操作,需要合并应当发起Pull Request
(PR),由负责生产环境的同事对此PR进行合并,此分支代码对应生产环境。main
分支创建出来的新分支,在此分支上紧急修改代码后,合并到测试环境,测试验证通过后,直接发起Pull Request
(PR)提交到main
;此分支一般在紧急修复线上问题之后,可将其合并(merge
)到dev
,再将此分支删除。feature
)上开发(包括修复bug),在功能分支开发自测,单元测试无误后并需要进行接口联调时,合并(merge
)到dev
(开发分支),触发开发环境持续集成过程。dev
(开发分支) 合并(merge
)到test
(测试分支)上,触发测试环境持续集成过程。feature
上面进行修复,然后统一按批次和时间
进行重新推送(push
)开发分支(dev
)和合并(merge
)测试(test
)过程Pull Request
(PR)test -> main
提交到,并编写上线清单(包含上线数据脚本,外部依赖服务,上线配置细节等等),通知负责生产环境的同事合并,按照上线约定时间和上线清单进行上线。main
分支创建出hotfix
分支,在此分支上修改代码后,合并到测试环境,经过测试验证通过后由研发负责人发起Pull Request
(PR)hotfix -> main
,进行紧急修复上线流程。说明: 此分支策略下,feature
分支可以看作为开发人员熟悉的local
分支,feature
,dev
,test
均允许互相合并(merge
)
feature-xx
)上开发(包括修复bug),在功能分支开发自测,单元测试无误后并需要进行接口联调时,合并(merge
)到dev
(开发分支),触发开发环境持续集成过程;多功能分支可并行开发。feature-xx
(功能分支) 合并(merge
)到test
(测试分支)上,触发测试环境持续集成过程。feature-xx
上面进行修复,然后严格统一按批次和时间
合并(merge
)开发和合并(merge
)测试(test
)过程,以避免频繁发布造成测试环境不稳定。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
)