04架构管理之分支管理实践-一种git分支管理最佳实践

        专栏说明:针对于企业的架构管理岗位,分享架构管理岗位的职责,工作内容,指导架构师如何完成架构管理工作,完成架构师到架构管理者的转变。计划以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分支测试后走后续发布流程

具体如下图:

04架构管理之分支管理实践-一种git分支管理最佳实践_第1张图片

 

三、分支管理原则

        主分支保持稳定: 主分支(如 main 或 master)应该保持稳定,只有已上线的代码。禁止直接在主分支上开发。

  • 特性分支:开发人员在对新功能的开发时,创建独立的特性分支。分支名可以描述功能的目标,如 feature/login。
  • 修复分支:对于 bug 修复,创建修复分支,确保修复在主分支上得到合并。分支名可以描述修复的问题,如 hotfix/login-error.
  • 命名规范:根据公司、团的命名习惯,使用统一的命名规范,清晰的命名方式以便团队成员理解分支用途。可以采用统一的前缀,如 feature/、hotfix/。
  • 小而频繁的提交:不要在一次提交中修复两个bug。单次提交的改动越小,更便于其他开发者理解,每次提交关注一个特定的更改,这有助于追踪和回溯变更历史。
  • 定期合并主分支:定期从主分支拉取最新代码,保持特性分支与主分支同步。避免分支过长时间的分离。
  • 代码审查:代码在提交测试前进行代码审查,提高代码质量。
  • 远程分支:及时推送特性分支到远程仓库,便于团队成员协作和代码审查。
  • 删除不必要的分支:一旦特性分支完成开发或修复,及时删除不再需要的分支,保持仓库的整洁。
  • 标签版本:使用标签来标识重要的版本发布,方便追踪和部署特定版本。
  • 培训和文档: 对团队成员进行培训,分享分支管理的最佳实践和流程,编写分支管理指南。

你可能感兴趣的:(架构管理之道,架构,git,idea,github,gitlab)