Git分支模型（参考AONE FLOW）

亦凉 2022-11-20 11:58 233阅读 0赞

### Git分支模型（参考AONE FLOW） ###

#### 分支定义 ####

1.  master
    
    1.  长期分支，存在与整个项目开发过程。
    2.  由项目主要技术负责人管理该分支。
2.  release/xxx
    
    1.  release/test 和 release/prod
    2.  既可以为长期分支也可以为短期分支，可能存在于一个或者多个版本之间
    3.  由测试负责人负责人管理该分支
3.  feature/fixbug/hotfix
    
    1.  临时分支
    2.  用于开发的具体功能特性和修复bug的分支，功能完成后删除
    3.  格式为：feature\_KaTeX parse error: Expected group after '\_' at position 5: date\_̲name\_KaTeX parse error: Expected group after '\_' at position 26: …n fixbug\_̲date\_KaTeX parse error: Expected group after '\_' at position 5: name\_̲description  
        hotfix\_KaTeX parse error: Expected group after '\_' at position 5: date\_̲name\_$description
    
    #### 分支策略 ####
    
    1.  规则一
        
        开始工作前，从主干创建特性分支
        
         *  每当开始一件新的工作项（比如新的功能或是bug）的时候，从最新已发布版本的主干Master上创建一个以feature(bugfix)/前缀命名的特性分支，然后在这个分支上提交代码修改。
         *  每个工作项（可以是一个人完成，或是多个人协作完成）对应一个特性分支，所有的修改都不允许直接提交到主干。
    2.  规则二
        
        通过合并特性分支，形成发布分支
        
         *  从主干上拉出一条新分支，将所有本次要集成或发布的特性分支依次合并过去，从而得到发布分支。发布分支通常以release/前缀命名。
         *  每条发布分支与具体的环境相对应，比如release/test分支对应部署测试环境，release/prod分支对应线上正式环境等等，并与流水线工具相结合，串联各个环境上的代码质量扫描和自动化测试关卡，将产出的部署包直接发布到相应环境上。
         *  release/prod从master上拉取的时候master可能已经有其他更新上线了，此时从master拉取拉取的release/prod合并相关feature分支后需要进行回归测试。
    3.  规则三
        
        发布到线上正式环境后，合并相应的发布分支到主干，在主干添加标签，同时删除该发布分支关联的特性分支
        
         *  完成了线上正式环境的部署，就意味着相应的功能真正地发布了，此时应该将这条发布分支合并到主干。
         *  为了避免在代码仓库里堆积大量历史上的特性分支，还应该清理掉已经上线部分特性分支。
         *  主干分支上的最新版本始终与线上版本一致，如果要回溯历史版本，只需在主干分支上找到相应的版本标签即可。
    4.  其他
        
         *  对于hotfix，可以创建一条新的发布分支对应线上环境（相当于hotfix分支），同时为这个分支创建临时流水线，以保障必要的发布前检查和冒烟测试能够自动执行。
         *  如果非得修一个历史版本的Bug，在主干分支找到版本标签位置，然后从那个位置创建hotfix分支，这种情况比较少见
    
    #### 开发流程 ####
    
    1.  新功能开发时，开发人员从Master拉取代码生成特性分支。
    2.  单元测试完成后等待测试负责人拉取release/test分支，然后提交Pull Request
    3.  开发负责人或者其他开发人员对Pull Request进行代码Review
    4.  代码Review完成后，测试负责人合并Pull Request到release/test，如果遇到合并冲突，则让相应的开发人员把feature/bug/hotfix分支重新以master为基准进行提交以及让相应的开发人员协助解决。
    5.  测试人员使用流水线工具进行代码质量扫描和自动化测试
    6.  测试人员进行测试
    7.  完成测试后，查看Master是否比拉取release/test时有更新，如果没有直接使用release/test上线，否则从最新Master拉取分支release/prod分支合并相关PR并进行回归测试
    8.  提交上线申请上线
    
    #### 例子 ####
    
    1.  开发人员A从Master拉取代码生成feature\_20190818\_A\_get\_users
    2.  开发人员B从Master拉取代码生成feature\_20190819\_B\_login
    3.  测试负责人Y从Master拉取release/test
    4.  开发人员A提交Pull Request PR1
    5.  发人员B提交Pull Request PR2
    6.  开发负责人F和开发人员C评审PR1 PR2，评审通过
    7.  测试负责人Y合并代码到release/test
    8.  测试人员X进行测试，完成后发现Master和拉取release/test时一样，直接使用release/test进行构建申请发布