Git【企业级开发模型】

一、为什么需要企业级开发模型一个软件从零开始到最终交付大致需要经历规划 → 编码 → 构建 → 测试 → 发布 → 部署 → 维护。在个人项目中你一个人可以完成所有环节。但在企业中角色分工明确开发团队Dev追求快速迭代不断加入新功能。运维团队Ops追求系统稳定不希望频繁变更。这两个团队的目标有时是冲突的。为了弥合这个鸿沟DevOps文化应运而生。它通过自动化工具和标准化流程让开发、测试、部署高效协作。而Git分支模型正是DevOps中代码管理的核心一环。简单来说企业级开发模型要解决以下问题如何让多人并行开发不同功能互不干扰如何保证主分支master的代码始终是稳定可发布的如何让测试人员在独立的环境中进行验证如何紧急修复线上问题同时不影响正在开发的功能二、理解系统开发环境先了解企业中的四大环境。每个环境对应不同的目的和分支。环境名称英文作用对应分支常见开发环境Development开发人员自己调试代码的地方打开全部错误报告feature/* 或 develop测试环境Testing测试人员进行功能测试模拟用户场景release/*预发布环境Staging/Pre-release与生产环境配置一致上线前的最后一道关卡release/*生产环境Production正式对外服务的线上环境master这几个环境也可以说是系统开发的三个重要阶段开发 - 测试 - 上线2.1 开发环境这是你每天编码的地方。你可以随意修改、提交、甚至推翻重来。通常每个功能分支部署到独立的开发环境或者所有开发人员共用一套开发环境部署develop分支。2.2 测试环境当某个功能开发完成后会被合并到一个专门的测试分支如release然后部署到测试环境。测试人员在这里执行测试用例发现bug后反馈给开发人员修复。测试不通过代码不能上线。2.3 预发布环境这是最容易忽视但非常重要的环境。它的硬件配置、数据库、中间件等与生产环境几乎一致。在上线前将代码部署到预发布环境做最后的验证可以避免因环境差异导致的线上问题。预发布环境是你的最后一道防线。2.4 生产环境就是用户真正使用的线上系统。只有经过完整测试和预发布验证的代码才能部署到生产环境。生产环境上的代码必须绝对稳定通常只有master分支会被部署到这里。对于规模较大的公司还会有仿真环境、灰度环境等但万变不离其宗。三、Git分支设计规范基于上述环境业界总结出了一套经典的分支模型——Git Flow。下面介绍五种核心分支。1. master 分支生产环境唯一且只读master分支是代码库的稳定版本任何时候都应该是可发布的。只合并不直接修改不允许直接在master上提交代码。只能从release或hotfix分支合并进来。打标签每次合并到master并上线后都要打一个标签如v1.0.0方便回滚。2. develop 分支开发环境日常开发集散地develop分支是开发的主线包含了所有已经完成并测试通过的功能。只读且唯一通常也不允许直接提交而是通过feature分支合并进来。可部署到开发环境开发人员可以随时将develop部署到开发环境进行联调。3. feature 分支功能开发来源于develop每开发一个新功能就从develop创建一个feature分支命名如feature/user_20231012_order。开发完成后合并回develop功能开发完毕并自测通过后提交Pull Request经过代码评审后合并到develop。临时分支合并后即可删除。4. release 分支预发布/测试来源于develop当develop积累了足够的功能准备发布一个版本时从develop创建一个release分支命名如release/v1.0_20231012。用于测试和预发布release分支会部署到测试环境和预发布环境。测试人员在这里发现bug开发人员直接在release分支上修复。最终合并到master和develop测试通过后将release合并到master并打标签同时也合并回develop确保develop也有bug修复。临时分支发布完成后删除。5. hotfix 分支紧急修复来源于master当线上出现严重bug需要立即修复时从master创建一个hotfix分支命名如hotfix/user_20231012_critical。修复后合并到master和develop修复完成后合并到master打新标签同时也必须合并到develop或当前release分支避免后续版本再次出现该bug。临时分支修复上线后删除。分支名称适用环境master主分支生成环境release预发布分支预发布/测试环境develop开发分支开发环境frature需求开发分支本地hotfix紧急修复分支本地feature从develop拉出合并回develop。release从develop拉出合并到master和develop。hotfix从master拉出合并到master和develop。实际团队中可能还会有一个pre-release分支但原理类似。其实上面说的是企业级常用的一种Git分支设计规范Git Flow模型但是这个模型并不是使用于所有的团队、所有的环境和所有的文化。如果你采用了持续交付你会想要一些能够尽可能的简化交付过程的东西有些人喜欢基于主干的开发模式喜欢使用特性的标志然后从测试的角度来看完全不适用四、企业级项目管理实战基于Gitee企业版用Gitee企业版来模拟一个真实项目的完整生命周期。Gitee企业版免费提供了项目管理和协作功能非常适合中小企业。https://gitee.com/enterprises点击右上角“企业版”选择免费版即可创建企业。填写企业名称随意如“我的测试企业”。在企业工作台点击“项目” - “新建项目”。填写项目名称、描述项目类型选择“普通项目”。项目创建后你就可以在项目中管理多个仓库、任务、文档等。在项目中点击“代码” - “新建仓库”。选择仓库类型为“Git”初始化时可选择Git Flow分支模型自动创建master和develop分支。勾选“生成.gitignore”和“开源许可证”等。点击“创建”。添加成员多人协作需要将团队成员加入企业并赋予权限。添加企业成员在企业管理后台点击“成员” - “添加成员”可以通过链接邀请或直接添加。被邀请者同意后成为企业成员。添加项目成员进入项目点击“成员” - “添加项目成员”选择企业成员并赋予角色如开发者、测试者、管理者。设置仓库权限进入仓库点击“设置” - “仓库成员”可以给指定成员“管理员”、“写”、“读”等权限。注意开发人员至少要有“写”权限才能推送代码。申请后需要负责人审批通过。