Git团队开发流程规范

发表于 更新于 阅读次数： 本文字数： 886 阅读时长 ≈ 1 分钟

无规矩不成方圆，良好工具，规范流程，这样才能一定程度的确保开发效率及成果质量,公司正面临SVN到Git的转换中，在参考一些大厂基于Git开发流的规范，进行整合，制定了以下规范。

分支命名规则

  1. 主分支：master【保护分支】
  2. 开发分支：dev【保护分支】
  3. 功能分支：feature/分支名称
  4. bug分支修复：hotfix/issueNumber

操作步骤

  1. 管理员【项目负责人】创建Git仓库，创建dev分支

    1
    2
    3
    $ git clone https://github.com/alanhg/alanhg.github.io.git
    $ git checkout -b dev
    $ git push

  2. 管理员根据功能拆分，基于dev分支，创建对应的issue，指派developer

  3. 各个developer，clone仓库，基于dev创建功能分支,本地进行开发,git add,git commit等，push到远程仓库，创建对应上游分支。

    _注意:_利用fixed #issueNum`语法糖等在提交信息中关联issue,这样MR成功后，issue则会自动关闭，同时方便明确提交CODE关联票

    1
    2
    3
    4
    $ git checkout dev
    $ git pull 
    $ git checkout -b feature/login

  4. 在多次的提交后，确认完成，则提MR到dev分支，

  5. 管理员进行Review，可能会有冲突，不清晰点，沟通分支developer，，确认OK后合并到dev。原功能分支关闭且删除

  6. CI服务拉取dev分支代码进行构建，运行在内网环境，确认OK，且支持上线则合并到master主干

  7. CI服务拉取master主干代码进行构建，部署到生产，同时打tag标记

  8. 如果在生产中遇到了BUG和新的功能需求，则创建对应的issue及创建对应的功能或bug分支，指派开发者。循环上述步骤

    1
    2
    $ git checkout -b hotfix/1 dev

说明

  • 因为分支为各个developer在本地创建，最终push到上游，命名按照上述规则，则不会存在分支命名重复冲突
  • 构建发版，会自动统计整体提交的修改点，所以准确填写commit-message描述信息显得尤为重要