点击查看【bilibili】
    一个企业当中项目，一般来说，是几个人同时进行开发的，那么如何对git分支进行管理就成了一个重点问题。

    那么这里，我们就需要介绍一下我们的git flow工作流程了。
    我们先从代码的运行环境来说起。代码运⾏的环境 ⼀般来说，公司团队都会有⾄少这⼏个环境：
    image.png

    • 本地开发环境： 开发⼈员⾃测的，可以是⾃⼰本地部署的静态服务器，当然也可类似是运⾏ npm server类似的环境，本地环境运⾏ 的代码可以是任何分⽀的
    • dev开发环境： 这个环境是⽤开发分⽀dev产出的代码来部署的，唯⼀的公⽤的
    • 测试&预发布环境： 这个环境是⽤开发分⽀release产出的代码来部署的，唯⼀的公⽤的
    • 线上⽣产环境： 这个环境是⽤开发分⽀master产出的代码来部署的，唯⼀的公⽤的

    对应的git分支模型是这样的
    image.png
    对应的分支策略是这样的
    image.png

    • master ：保护分⽀，对应的就是⽣产环境的分⽀
    • release：保护分⽀，所有开发完成的分⽀会申请合并到release分⽀，提供给测试⼈员测试
    • feature-*：功能分⽀，具体功能开发
    • dev/test-*：开发分⽀&脏分⽀，对应的是⼤家共⽤的开发环境，上⾯的代码会部署到⼀个公共的开发环境，供开发⼈ 员做⾃测，应付⼀些⽇常、⾮⽇常的调试
    • hotfix-*：bug紧急修复分⽀，可以直接合并到master，（假如release合并了⼏个feature分⽀，正在测试的情况 下，发现需要紧急修复的buf，紧急修复测试完毕后，可以直接合并到master，如果合并到release，在由 release合并到master，那些正在测试的功能或者还不准备上线的功能就会跟着直接上线了）

    工作流程介绍
    image.png

    1. 接到需求⽂档，做评审后分配个每个⼈或⼩组的功能开发，相关⼈员从master 检出功能分⽀
    2. 开发的时候除了会在本地测试，有需要还会合并到dev分⽀，在公共的开发环境去⾃⼰做测试
    3. 因为在开发功能的期间，可能有hotfix完成合并到master，合并代码的时候习惯merge⼀下master，防⽌冲突 等
    4. ⾃测完成之后，申请合并到release，合并成功后部署到测试环境后通知测试⼈员做测试
    5. 测试通过后，release申请合并到master，准备上线
    6. 如果测试不通过，在功能分⽀修改后重新merge
    7. 上线成功稳定后删除对应的功能分⽀，dev 合并最新的master分⽀