专栏说明:针对于企业的架构管理岗位,分享架构管理岗位的职责,工作内容,指导架构师如何完成架构管理工作,完成架构师到架构管理者的转变。计划以10篇博客阐述清楚架构管理工作,专栏名称:架构管理之道
一句话导读
对于架构管理、研发管理中,分支管理是公司研发过程中必不可少的一个实践。本文主要是根据个人及公司实践,来说明下具体的分支管理方法,这里的分支指的git仓库的代码分支。分支管理方法有很多,大家可以自行定义,只要能够完成研发协作即可。
目录
一句话导读
一、环境管理
1.开发环境
2.测试环境
3.预发布环境
4.生产环境
5.扩展
二、分支管理
1.feature分支
2.develop分支
3.release分支
4.master分支
5.tag
6.hotfix分支
三、分支管理原则
一、环境管理
一般公司研发都会有几个环境,如开发环境、测试环境、预发布环境、生产环境,有些公司甚至还有本地环境、验收环境、演示环境、性能测试环境等等。针对这么多的环境,我们研发中要根据公司、项目的实际情况,进行环境的管理。一般项目应该有开发环境、测试环境和生产环境。有些小项目也可能只有一个研发环境,项目结束后直接将研发环境转为生产环境。所以说研发环境的需求应该是根据实际情况来定的。
1.开发环境
研发人员将完成的代码发布到开发环境中,做初步的集成测试,开发环境由开发人员自行管理,代码极其不稳定,环境机器配置可以比较低。一般用dev标识
2.测试环境
主要提供给测试人员使用,代码经过研发环境自测完成后可以提测,代码由测试管理员管理,环境代码相对比较稳定,环境机器根据测试要求配置即可,不用太高配置。一般用test标识
3.预发布环境
主要提供个测试人员使用,或者做UAT验收使用,代码经过测试环境验证完成后,可以提交到预发布环境中,环境的配置和数据最好和生产一致,目的是在上生产前做最后确认,环境代码和生产保持一致。机器配置最好和生产环境一致。一般用pre标识
4.生产环境
代码最终交付的环境,一般部署经过测试验证、预发布验证的代码,生产环境由专人负责严格管理,一般用prod标识
5.扩展
- 本地环境:研发人员自己本机的环境,开发人员自行管理,部分中间件、数据库等可以自建或者用开发环境中的组件。用户开发过程中的调试等工作。
- 验收环境:一般由测试人员管理,负责将已完成的功能需求代码部署上去,交由最终软件的用户进行测试或需求提出的业务部门进行验收测试,通常测试完成后即可发布生产环境,一般用UAT标识
- 演示环境:演示环境相对于生产环境而定义的,环境是给用户演示而定制的。功能基本和生产一致,用户相对较少,环境要保持相对稳定,尤其是客户需要做演示的时候。一般用demo标识
- 性能测试环境:主要是对软件的性能情况进行测试。环境应该和生产保持一致,但是一般性能测试环境是临时的,测试完成后即可下线。
二、分支管理
分支管理的逻辑最好是和团队规模相匹配。更好的git分支管理,有助于团队的协作效率的提高和代码的管理。我们使用基于主干分支管理策略,将代码分支和环境相对应,提高代码的质量。
1.feature分支
研发分支,研发人员从develop分支拉取,并以feature/开头命名自己的研发分支,开发人员对于新的需求则在该分支上开发,并自行管理,对应本地环境。
2.develop分支
研发测试分支,研发人员可将开发好的代码合并到该分支上,在研发环境进行初步集成自测,该分支由研发人员自行管理。
3.release分支
测试分支,该分支为保护分支,不允许研发人员直接commit代码,研发人员可以发起feature分支合并到release分支的申请,由配置管理员进行合并,发布到测试环境进行集成测试。该分支由配置管理员管理。
4.master分支
生产分支,该分支为保护分支,不允许研发人员直接commit代码,只接受release分支的合并,由配置管理员负责管理,发布生产环境。
5.tag
版本归档标识,当发布的系统稳定后形成tag版本标识,进行归档。
6.hotfix分支
问题修复分支,如果生产版本发布稳定后,出现bug,可从master拉取hotfix分支,修复完成后,合并到release分支测试通过,将hotfix合并到master发布生产,形成新的tag;如果是发布过程中有bug,也可拉取hotfix分支,并提交release分支测试后走后续发布流程
具体如下图:
文章来源:https://www.toymoban.com/news/detail-675179.html
三、分支管理原则
主分支保持稳定: 主分支(如 main 或 master)应该保持稳定,只有已上线的代码。禁止直接在主分支上开发。文章来源地址https://www.toymoban.com/news/detail-675179.html
- 特性分支:开发人员在对新功能的开发时,创建独立的特性分支。分支名可以描述功能的目标,如 feature/login。
- 修复分支:对于 bug 修复,创建修复分支,确保修复在主分支上得到合并。分支名可以描述修复的问题,如 hotfix/login-error.
- 命名规范:根据公司、团的命名习惯,使用统一的命名规范,清晰的命名方式以便团队成员理解分支用途。可以采用统一的前缀,如 feature/、hotfix/。
- 小而频繁的提交:不要在一次提交中修复两个bug。单次提交的改动越小,更便于其他开发者理解,每次提交关注一个特定的更改,这有助于追踪和回溯变更历史。
- 定期合并主分支:定期从主分支拉取最新代码,保持特性分支与主分支同步。避免分支过长时间的分离。
- 代码审查:代码在提交测试前进行代码审查,提高代码质量。
- 远程分支:及时推送特性分支到远程仓库,便于团队成员协作和代码审查。
- 删除不必要的分支:一旦特性分支完成开发或修复,及时删除不再需要的分支,保持仓库的整洁。
- 标签版本:使用标签来标识重要的版本发布,方便追踪和部署特定版本。
- 培训和文档: 对团队成员进行培训,分享分支管理的最佳实践和流程,编写分支管理指南。
到了这里,关于04架构管理之分支管理实践-一种git分支管理最佳实践的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!