Git工具代码分支管理和上线发布流程

• ​测试坏境

  • ​1-0. 本地线下开发环境

  • ​1-1. 线上delevop环境: 开发测试使用功能特性分支

  • ​1-2. 线上准生产或预发布环境：用于发布新版本前，测试功能 预发布前测试

  • ​1-3. 线上生产环境

• ​版本号管理

  使用3位数作为版本管理v 0.0.1

  • ​2-1. 当修复一个小bug,则版本号的第三位自增1,如v 0.0.2

  • 2-2. 当新增一个功能特性，则版本号第二位自增1，如 v 0.1.2

  • ​2-3. 当有新的模块或框架大调整时，则版本号第一位自增1，如v 1.1.2

• ​版本更新列表checklist

  • ​3-1 每次发布新版本需列列出所做变更更 Version.txt或者用readme.md里做对应说明，列明时间版本号，如v 0.0.1 2018-9-5

  • ​3-2. 系统首次上线,测试根据version.txt或者readme.md的变更进行release新发版本测试跟踪

• ​版本分支

  it-flow 流程中包含 5 类分⽀支，分别是 master、develop、新功能分⽀支（feature）、

  发布分⽀支（release）和 hotfix。这些分⽀支的作⽤用和⽣生命周期各不不相同

  • 4-1 ​master(主支)

    master 分支中包含的是可以部署到生产环境中的代码，也就是我们经常使用的Master分支，这个分支最近发布到生产环境的代码，最近发布的Release， 这个分支只能从其他分支合并，不能在这个分支直接修改

    
    

    我们修改线上bug的时候要在master上创建一个自己的分支，然后进行线上bug的修改。（紧急bug）

    • ​hotfix

      该分支只在需要时，从 develop 或 master 分支创建。在完成之后合并到 develop或 master 分支。

      合并完成之后该分⽀支被删除。这几类分支的名称应该遵循一定的命名规范，以方便开发人员识别

      • ​命名规范

        hotfix-XXX

      • ​创建自

        master

        hotfix-新加功能或修改的bug名称

      • ​合并到

        develop 和master

      • 说明​

        生产环境中发现的紧急bug 的修复

  • ​4-2 develop(测试分支)

    develop 分支中包含的是下个版本需要发布的内容，从某种意义上来说,develop 是一个进⾏行代码集成的分支。

    当 develop分支集成了足够的新功能和 bug 修复代码之后，通过一个发布流程来完成新版本的发布。

    发布完成之后，develop 分支的代码会被合并到 master 分支中

    这个分支是我们是我们的主开发分支，包含所有要发布到下一个Release的代码，这个主要合并与其他分支

    比如Feature分支，一般在开发阶段都是在dev上创建自己的分支，然后进行新功能的开发或者bug的修改feature-新加功能或修改的bug名称

    • ​feature

      这类分支只在需要时从 develop 或 master 分支创建。在完成之后合并到 develop或 master 分支。合并完成之后该分支被删除。这几类分支的名称应该遵循一定的命名规范，以方便开发⼈员识别

      • ​命名规范

        feature-XXX

      • ​创建自

        develop

      • ​合并到

        develop

      • ​说明

        新功能

    • ​realease

      这类分支只在需要时从 develop 或 master 分支创建。在完成之后合并到 develop或 master 分支。合并完成之后该分支被删除。这几类分支的名称应该遵循⼀一定的命名规范，以方便开发人员识别

      • ​命名规范

        release-XXX

      • 创建自

        develop

      • 合并到​

        develop 和master

      • ​说明

        一次新版本的发布

  • ​4-3 feature(新功能分支)

    这个分支主要是用来开发一个新的功能，一旦开发完成，我们合并回Develop分支进入下一个Release。项⽬目开发分支（feature分支）：此分支特点是周期长、团队协作（一般至少包括一个前端和一个后台）、代码量量大，工作方式是需要创建本地以及远程feature分支，代码基于develop分支代码，经过开发、测试之后，最终合并到develop分支上。当项目上线之后，分支会保留留一段时间（一般一周左右，最长不不超过1个月），直至最终删除

  • ​4-4 release

    当你需要一个发布一个新Release的时候，我们基于Develop分⽀支创建一个Release分支，完成Release后，我们合并到Master和Develop分支

    
    

    release分支其实相当于对develop分支的一个冻结副本，release拉出来的时候就意味着上面的需求都已经冻结，在release上唯一可以继续做的改动只有这些需求的bug修复

    而release一旦拉出后，develop上就可以继续执行行新功能开发，这样新功能开发和版本测试发布可以并行行，所以测试的介入的理理想节点是release版本

    准生产的分支一般每次上线前都会新开一个，当项目开上了准生产，我们这边再增加相关的功能或者修改bug，就在准生产分支上建立自己的分支进行开发

     release-v1.1.0-新加功能或修改的bug名称

  • ​4-5 hotfix

    当我们在Production发现新的Bug时候，我们需要创建一个Hotfix, 完成Hotfix后，我们合并回Master和Develop分支，所以Hotfix的改动会进入下一个Release

• ​各分支功能

  • ​master

    用于线上发布

  • ​feature-xxx

    用于添加功能，添加完删除

  • develop​

    用于合并feature分支

  • ​release

    用于发布前的测试，发布完删除

  • ​bugfix-xxx

    用于修复develop和master分支的bug

• ​注意事项

  • ​1. master主分支要打tag，tag更更新按版本号规则进行

  • ​2. 每次hotfix，合并到主分支master，tag版本第三位⾃自增1，同时hotfix也要merge到develop分支

  • ​3. 从开发develop开分支预发布release时，命名也按版本号进⾏行行，tag版本第二位自增，如release-V0.1.2

  • ​4. 测试发现预分⽀支版本release-V0.1.2有bug时，在该分支上修改bug，release测试通过后，将其merge到develop分支和 master分支，master分支进行行tag V0.1.2

  • ​5. merge使用--no-ff参数。默认情况下，Git执行"快进式合并"（fast-farwardmerge），会直接将Master分支指向Develop分支。使用--no-ff参数后，会执行行正常合并，在Master分支上生成⼀一个新节点。为了保证版本演进的清晰，我们希望采用这种做法

  • ​6. 提交描述的时候，如果是一条正常些，如果是多个地方，分1、2、3写清相关各项

• ​添加新功能

  • ​7-1 发新功能或改进, 从develop检出本地功能分支。比如feature-xxx ,XXX为功能的代码

  • ​7-2 修改代码，添加功能

  • ​7-3 提交到本地库。commit message以 功能的代码（比如XXX）开头。比如“重新设计API接口”

  • ​7-4 本地自测，测试功能。如果有bug，修改代码未通过跳到7-2

  • ​7-5 将develop分支merge到feature分支，解决冲突，push到远程，提交pull请求

  • ​7-6 找人 review代码并merge到develop

• ​一个开发人员典型的提交流程

  一个开发人员典型的提交流程

  
  

  
  

  
  

  //新建分支
  git checkout develop
  git pull origin develop
  git checkout -b myfeature
  //在分支上开发
  git add ***
  git commit -m "*****"
  //在分支开发过程中合并develop分⽀支到本分⽀支（先把自己的工作commit到本
  地）
  git checkout develop
  git pull origin develop
  git checkout myfeature
  git merge develop
  （如果没有冲突，就继续开发，如果有冲突，执⾏行行下⾯面过程）
  ⾸首先在本地解决冲突，再把冲突解决commit
  git add ***
  git commit -m "*****”
  //在分支开发结束，需要将本分支推到远程
  git push
  

• ​紧急修复Bug

  • ​9-1 从master检出本地Bug修复分支。比如 bugfix-XXX

  • ​9-2 修复bug

  • ​9-3 本地测试通过

  • ​9-4 提交到本地库。commit message以 问题的代码 bug-XXX开头。比

    如”BUG-57 修复 版本太多显示不不全

  • ​9-5 push分支到远程

  • ​9-8 找人 review代码并merge到develop、master，master打tag

  • ​9-9 部署到⽣生产

  • ​9-7 提交pull请求

    • ​9-6 部署到线上准⽣生产环境测试通过

• ​发布新版本

  • ​10-1 给develop添加tag：v+版本号+a

  • ​10-2 从develop检出release_latest

  • ​10-3 部署到线上develop开发环境测试 【QA】开发环境多feature集合测试

  • ​10-4 QA测试人员测试，如有bug，按照 修复bug流程 修复，并merge到

    release_latest。重新部署

  • ​10-5 测试通过给release添加tag：v+版本号+b 【QA】准生产环境预发布测试

  • ​10-6 部署到准⽣生产测试环境，线上准生产测试 

  • ​10-7 如有bug，按照 修复bug流程 修复，并merge到release。重新部署

  • ​10-8 给release添加tag：v+版本号

  • ​10-9 发起pull请求，merge到master，master打tag，部署到生产

• ​代码部署

  • ​部署测试

    部署测试的代码，是经过自测且实现功能点代码，部署前需要通知到其他开发人员

  • ​部署正式

    代码经过测试之后，已经是稳定代码，达到了上线标准之后就可以部署代码；遇到严重问题需回滚代码。部署前需通知相关负责人

• 代码回滚

  回滚条件：正式线上遇到重大bug