目录

引入

系统开发环境

Git 分支设计规范

master 分支

release 分支

develop 分支

feature 分支

hotfix 分支

开发场景 - 基于git flow模型的实践

DevOps研发平台

修复测试环境 Bug

修改预发布环境 Bug

修改正式环境 Bug

紧急修复正式环境 Bug

拓展实践

---

都说：对于开发者，Git是非常的重要的，但是为什么呢？这就需要从企业级的开发流程来说。

引入

        我们知道，⼀个软件从零开始到最终交付，⼤概包括以下⼏个阶段：规划、编码、构建、测试、发布、部署和维护。

        最初，程序比较简单，工作量不大，程序员⼀个人可以完成所有阶段的工作。但随着软件产业的日益发展壮大，软件的规模也在逐渐变得庞大。软件的复杂度不断攀升，⼀个人已经hold不住了，就开始出现了精细化分工。

• 开发团队：(尤其是敏捷团队)追求变化。
• 运维团队：追求稳定。

        双方往往存在利益的冲突。比如，精益和敏捷的团队把持续交付作为目标，而运维团队则为了线上的稳定而强调变更控制。部门墙由此建立起来，这当然不利于 IT 价值的最大化。

        为了弥合开发和运维之间的鸿沟，需要在文化、工具和实践方面的系列变革 ⸺ DevOps正式登上舞台。

        DevOps（Development和Operations的组合词）是⼀种重视 “软件开发⼈员（Dev）” 和 “IT运维技术⼈员（Ops）” 之间沟通合作的文化、运动或惯例。透过自动化 “软件交付” 和 “架构变更” 的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。在 DevOps 的软件开发过程包含计划、编码、构建、测试、预发布、发布、运维、监控，由此可见 DevOps 的强大。

DevOps到底是什么意思？

        以上跟大家讲解的是企业级常用的⼀种 Git 分支设计规范：Git Flow 模型。 

master 分支

        master 为主分支，该分支为只读且唯一分支。用于部署到正式发布环境，⼀般由合并 release 分支得到。主分支作为稳定的唯⼀代码库，任何情况下不允许直接在 master 分支上修改代码。产品的功能全部实现后，最终在 master 分支对外发布，另外所有在 master 分支的推送应该打标签（tag）做记录，方便追溯。

        master 分支不可删除。

release 分支

        release 为预发布分支，基于本次上线所有的 feature 分支合并到 develop 分支之后，基于 develop 分支创建。可以部署到测试或预发布集群。命名以 release/ 开头，建议的命名规则: release/version_publishtime 。release 分支主要用于提交给测试人员进行功能测试。发布提测阶段，会以 release 分支代码为基准进行提测。如果在 release 分支测试出问题，需要回归验证 develop 分支看否存在此问题。

        release 分支属于临时分支，产品上线后可选删除。

develop 分支

feature 分支

        feature 分支通常为新功能或新特性开发分支，以 develop 分支为基础创建 feature 分支。命名以 feature/ 开头，建议的命名规则： feature/user_createtime_feature 。新特性或新功能开发完成后，开发人员需合到 develop 分支。

        一旦该需求发布上线，便将其删除。

hotfix 分支

        hotfix 分支为线上 bug 修复分支或叫补丁分支，主要用于对线上的版本进行 bug 修复。当线上出现紧急问题需要马上修复时，需要基于 master 分支创建 hotfix 分支。命名以 hotfix/ 开头，建议的命名规则: hotfix/user_createtime_hotfix 。

        当问题修复完成后，需要合并到 master 分支和 develop 分支并推送远程。⼀旦修复上线，便将其删除。

开发场景 - 基于git flow模型的实践

DevOps研发平台

腾讯

阿里云

gitee

修复测试环境 Bug

修改预发布环境 Bug

• 如果存在，修复流程与修复测试环境 Bug 流程⼀致。
• 如果不存在，这种可能性比较少，大部分是数据兼容问题，环境配置问题等。

修改正式环境 Bug