Git系列--4.Git分支设计规范
目录
一、了解开发环境
1.1概念阐述
1.2系统概括图
二、设计规范之GitFlow模型
2.1具体分支概念
2.1.1master 分⽀
2.1.2release 分⽀
2.1.3develop 分⽀
2.1.4feature 分⽀
2.1.5hotfix 分⽀
2.2宏观表格
三、分支流程图
一、了解开发环境
1.1概念阐述
对于开发人员来说，系统开发一般有以下几个环境：
1. 开发环境：开发环境是程序猿们专⻔⽤于⽇常开发的服务器。为了开发调试⽅便，⼀般打开全部错误报告和测试⼯具，是最基础的环境。
2. 测试环境：⼀个程序在测试环境⼯作不正常，那么肯定不能把它发布到⽣产机上。该环境是开发环境到⽣产环境的过渡环境。
3. 预发布环境：该环境是为避免因测试环境和线上环境的差异等带来的缺陷漏测⽽设⽴的⼀套环境。其配置等基本和⽣产环境⼀致，⽬的是能让我们发正式环境时更有把握！所以预发布环境是你的产品质量最后⼀道防线，因为下⼀步你的项⽬就要上线了。要注意预发布环境服务器不在线上集成服务器范围之内，为单独的⼀些机器。
4. ⽣产环境：是指正式提供对外服务的线上环境，例如我们⽬前在移动端或PC端能访问到的APP都是⽣产环境。
1.2系统概括图
系统开发的三个重要阶段：开发->测试->上线
二、设计规范之GitFlow模型
2.1具体分支概念
2.1.1master 分⽀
master 为主分⽀，该分⽀为只读且唯⼀分⽀。⽤于部署到正式发布环境，⼀般由合并release 分⽀得到。主分⽀作为稳定的唯⼀代码库,任何情况下不允许直接在 master 分⽀上修改代码。产品的功能全部实现后，最终在master分⽀对外发布，另外所有在master分⽀的推送应该打标签（tag）做记录，⽅便追溯。
master 分⽀不可删除。
2.1.2release 分⽀
release 为预发布分⽀，基于本次上线所有的 feature 分⽀合并到 develop 分⽀之后，基于 develop 分⽀创建。可以部署到测试或预发布集群。
命名以 release/ 开头，建议的命名规则: release/version_publishtime 。
release 分⽀主要⽤于提交给测试⼈员进⾏功能测试。发布提测阶段，会以 release 分⽀代码
为基准进⾏提测。如果在 release 分⽀测试出问题，需要回归验证 develop 分⽀看否存在此问题。
release 分⽀属于临时分⽀，产品上线后可选删除。
2.1.3develop 分⽀
develop 为开发分⽀，基于master分⽀创建的只读且唯⼀分⽀，始终保持最新完成以及 bug 修复后的代码。可部署到开发环境对应集群。
可根据需求⼤⼩程度确定是由 feature 分⽀合并，还是直接在上⾯开发（⾮常不建议）。
2.1.4feature 分⽀
feature 分⽀通常为新功能或新特性开发分⽀，以 develop 分⽀为基础创建 feature 分命名⽀。以 feature/ 开头，建议的命名规则： feature/user_createtime_feature 。
新特性或新功能开发完成后，开发⼈员需合到 develop 分⽀。⼀旦该需求发布上线，便将其删除。
2.1.5hotfix 分⽀
hotfix 分⽀为线上 bug 修复分⽀或叫补丁分⽀，主要⽤于对线上的版本进⾏ bug 修复。当线上出现紧急问题需要⻢上修复时，需要基于 master 分⽀创建 hotfix 分⽀。
命名以 hotfix/ 开头，建议的命名规则: hotfix/user_createtime_hotfix
当问题修复完成后，需要合并到 master 分⽀和 develop 分⽀并推送远程。⼀旦修复上线，便将其删除。
2.2宏观表格
三、分支流程图
一般模型，具体情况采用合适的Git分支模型
