美文网首页
Git使用规范

Git使用规范

作者: 程序员与工匠 | 来源:发表于2019-03-14 18:19 被阅读0次

    [TOC]

    工作流指南

    分支分类

    • 历史分支
      master: 存储了正式发布的历史,为主分支(保护分支),不能直接在master上进行修改代码和提交;
      develop:作为功能的集成分支,开发完成需要提交测试的功能合并到该分支;
    • 功能分支
      feature: 大家根据不同需求创建独立的功能分支,开发完成后合并到develop分支;
    • 发布分支
      release: 发布分支,主要用于测试或修复bug。
    • 维护分支
      hotfix: 为bug修复分支,需要根据实际情况对已发布的版本进行漏洞修复,必须从master拉取;

    流程图解

    image.png

    命名规范

    分支命名

    功能分支: featrue/功能名称
    发布分支:release/版本号-功能名称-发布日期
    维护分支:hotfix/版本号-问题概述或issueid-日期 (最好使用issue建立问题描述?)
    例如: release/转投优化-20181111

    常见问题

    分支管理策略

    1. develop为集成开发分支
     提交规则: 
     自己分支自测完毕;
     review通过再合并;
    
    2. 本地分支管理
    本地分支必须从**线上版本节点**checkout();
    本地分支要做到勤提交,分小功能提交;
    一个功能点一个分支(自己控制),至少保证保留两个分支:  新版本分支、优化分支;
    本地分支merge到develop分支时,必须先merge develop到本地分支,自测通过再提交;
    
    3. 注意事项
    开发者相同版本尽量不要修改相同功能,提前划分或协商清楚;
    如果修改代码涉及多人功能,提交完毕请及时告知相关人员;
    开发者每天更新develop分支内容到本地分支,避免大规模merge; 
    fixbug分支修改测试完,立即合并到develop上! 
    

    提交规范

    Commit

    Commit message一般包括三部分:Header、Body和Footer。
    Header
    type(scope):subject

    • type:用于说明commit的类别,规定为如下几种
      feature:新增功能;
      fix:修复bug;
      docs:修改文档;
      refactor:代码重构,未新增任何功能和修复任何bug;
      build:改变构建流程,新增依赖库、工具等(例如webpack修改);
      style:仅仅修改了空格、缩进等,不改变代码逻辑;
      perf:改善性能和体现的修改;
      chore:非src和test的修改;
      test:测试用例的修改;
      ci:自动化流程配置修改;
      revert:回滚到上一个版本;
    • scope:【可选】用于说明commit的影响范围
    • subject:commit的简要说明,尽量简短

    Body
    对本次commit的详细描述,可分多行

    Footer
    不兼容变动:需要描述相关信息
    关闭指定Issue:输入Issue信息

    Merge

    代码合并、master分支操作,请在gitlab 提交 merge request,负责人进行代码review后,才能同意合并操作。

    Tag(Version)

    采用三段式,v版本.里程碑.序号,如v1.2.1

    • 架构升级或架构重大调整,修改第2位
    • 新功能上线或者模块大的调整,修改第2位
    • bug修复上线,修改第3位

    参考文档:http://www.crom.cn/topics/338

    相关文章

      网友评论

          本文标题:Git使用规范

          本文链接:https://www.haomeiwen.com/subject/dmicmqtx.html