目录1. 前言2. 系统开发环境3. Git分支设计规范3.1 master 分支3.2 release 分支3.3 develop 分支3.4 feature 分支3.5 hotfix 分支3.6 总结1. 前言我们知道一个软件从零开始到最终交付大概包括以下几个阶段规划、编码、构建测试、发布、部署和维护。最初程序比较简单工作量不大程序员一个人可以完成所有阶段的工作。但随着软件产业的日益发展壮大软件的规模也在逐渐变得庞大。软件的复杂度不断攀升一个人已经hold不住了就开始出现了精细化分工。如下图所示但在传统的IT组织下开发团队(Dev和运维团队Ops之间诉求不同开发团队尤其是敏捷团队追求变化运维团队追求稳定双方往往存在利益的冲突。比如精益和敏捷的团队把持续交付作为目标而运维团队则为了线上的稳定而强调变更控制。部门墙由此建立起来这当然不利于IT价值的最大化。为了弥合开发和运维之间的鸿沟需要在文化、工具和实践方面的系列变革——DevOps正式登上舞台。DevOps到底是什么意思 - 知乎https://zhuanlan.zhihu.com/p/91371659DevOpsDevelopment和Operations的组合词是一种重视“软件开发人员(Dev)”和“IT运维技术人员Ops》”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。在DevOps的软件开发过程包含计划、编码、构建、测试、预发布、发布、运维、监控由此可见DevOps的强大。讲了这么多这个故事到底和我们课程的主题Git有什么关系呢举一个很简单的例子就能说明这个问题。一个软件的迭代在我们开发人员看来说白了就是对代码进行迭代那么就需要对代码进行管理。如何管理我们的代码呢那不就是Git分布式版本控制系统所以Git对于我们开发人员来说其重要性就不言而喻了。2. 系统开发环境言归正传对于开发人员来说在系统开发过程中最常用的几个环境必须要了解一下开发环境开发环境是程序猿们专门用于日常开发的服务器。为了开发调试方便一般打开全部错误报告和测试工具是最基础的环境。测试环境一个程序在测试环境工作不正常那么肯定不能把它发布到生产机上。该环境是开发环境到生产环境的过渡环境。预发布环境该环境是为避免因测试环境和线上环境的差异等带来的缺陷漏测而设立的一套环境。其配置等基本和生产环境一致目的是能让我们发正式环境时更有把握所以预发布环境是你的产品质量最后一道防线因为下一步你的项目就要上线了。要注意预发布环境服务器不在线上集成服务器范围之内为单独的一些机器。生产环境是指正式提供对外服务的线上环境例如我们目前在移动端或PC端能访问到的APP都是生产环境。这几个环境也可以说是系统开发的三个重要阶段开发-测试上线。一张图总结对于规模稍微大点的公司来说可不止这么几个环境比如项目正式上线前还存在仿真/灰度环境再比如还存在多套测试环境以满足不同版本上线前测试的需要。一个项目的开始从设计开始而一个项目的成功则从测试开始。一套良好的测试体系可以将系统中绝大部分的致命Bug解决在系统上线之前。测试系统的完善和成熟也是衡量一个软件企业整体水平的重要指标之一测试往往被忽视因为它对可以的隐性、对软件开发企业不产生直接的效益但是它却是软件质量的最终保障乃至项目能否成功的重要因素3. Git分支设计规范注以上表格中的分支和环境的搭配仅是常用的一种可视情况而定不同的策略。3.1 master 分支master为主分支该分支为只读且唯一分支。用于部署到正式发布环境一般由合并release分支得到。主分支作为稳定的唯一代码库任何情况下不允许直接在master分支上修改代码。产品的功能全部实现后最终在master分支对外发布另外所有在master分支的推送应该打标签(tag)做记录方便追溯。master分支不可删除。3.2 release 分支release为预发布分支基于本次上线所有的feature分支合并到develop分支之后基于develop分支创建。可以部署到测试或预发布集群。命名以release/开头建议的命名规则:release/version_publishtime。release分支主要用于提交给测试人员进行功能测试。发布提测阶段会以release分支代码为基准进行提测。如果在release分支测试出问题需要回归验证develop分支看否存在此问题。release分支属于临时分支产品上线后可选删除。3.3 develop 分支develop为开发分支基于master分支创建的只读且唯一分支始终保持最新完成以及 bug修复后的代码。可部署到开发环境对应集群。可根据需求大小程度确定是由feature分支合并还是直接在上面开发非常不建议。3.4 feature 分支feature分支通常为新功能或新特性开发分支以develop分支为基础创建feature分支。命名以feature/开头建议的命名规则:feature/user_createtime_feature。新特性或新功能开发完成后开发人员需合到develop分支。一旦该需求发布上线便将其删除。3.5 hotfix 分支hotfix分支为线上bug修复分支或叫补丁分支主要用于对线上的版本进行bug修复。当线上出现紧急问题需要马上修复时需要基于master分支创建hotfix分支。命名以hotfix/开头建议的命名规则:hotfix/user_createtime_hotfix当问题修复完成后需要合并到master分支和develop分支并推送远程。一旦修复上线便将其删除。3.6 总结其实以上跟大家讲解的是企业级常用的一种Git分支设计规范GitFlow模型。但要说的是该模型并不是适用于所有的团队、所有的环境和所有的文化。如果你采用了持续交付你会想要一些能够尽可能简化交付过程的东西。有些人喜欢基于主干的开发模式喜欢使用特性标志。然而从测试的角度来看这些反而会把他吓一跳。关键在于站在你的团队或项目的角度思考这种分支模型可以帮助你们解决哪些问题它会带来哪些问题这种模式为哪种开发提供更好的支持你们想要鼓励这种行为吗你选择的分支模型最终都是为了让人们更容易地进行软件协作开发。因此分支模型需要考虑到使用者的需求而不是盲目听信某些所谓的“成功的分支模型”。所以对于不同公司规范是会有些许差异但万变不离其宗是为了效率与稳定。