代码提交合并流程

分支介绍

  • master

    • 固定分支。主分支，对应生产环境

  • pre

    • 固定分支。预生产分支，对应预生产环境

  • test

    • 固定分支。测试分支，对应测试环境

  • dev

    • 固定分支。开发环境分支，对应dev自测环境

  • feature

    • 功能分支

  • hotfix

    • 热修复分支

  • merge

    • 合并分支

注：固定分支不允许做任何删改操作，只能提交对其的合并请求，其余分支，按照下面的规范视情况进行操作，以下的merge hotfix feature分支统一称为其余分支

规范

分支命名规范

  • 功能分支

    • 命名格式：feature_<username>_<XXX>

    • 除了线上的bug热修复意外，都按照功能分支定义命名，具体的一个分支内开发内容，自己决定，对分批上线有容错就行

    • 分支内容上线稳定之后，及时删除

  • 线上热修复分支

    • 命名格式：hotfix_<username>_<XXX>

    • 只有线上的bug修复使用热修复分支

    • 分支内容上线稳定之后，及时删除

  • 合并分支

    • 命名格式：merge_<username>_<source>_to_<target>

    • 当合并出现冲突，用来解决冲突的第三方合并分支

    • 分支合并到目标分支之后，及时删除

注：<>内部包裹都是变量，除XXX是自定义名称以外，其他的都需要严格遵守规范

 

合并提交规范

合并规范

  1. 目前只有pre和master是同步分支之外，其余的固定分支都不同步，所以除了pre分支可以对master分支进行合并之外，其余的都不允许固定分支之间进行合并，只能是其余分支向固定分支进行合并。

  2. dev>test>pre>master 其余分支向固定分支合并时，需要遵从先合并dev再合并test,以此类推，后者向固定分支合并前，需要先合并前一个固定分支。

  3. 合并pre的时候需要测试环境验收之后，提交合并pre请求,合并title 需要带WIP:前缀（具体的提交请求细节，看下一节提交规范篇），然后将合并请求的diff链接同步至code review钉钉群。

  4. 合并master规则同第3条合并pre一样

  5. 合并master分两种情况需要注意，

    1. 正常版本的迭代合并，是pre向master进行合并请求。

    2. 如果是紧急需求、提前上线、热修复等非正常情况的提前上线，可以直接使 hotfix feature分支对master提交合并请求

 

提交合并请求规范

 

 

 

  1. 首先将本次合并指向自己

  2. 书写好合并内容

    • 格式：

      - addOn 
        - XXXXX
        - XXXXX
      - update
        - XXXXX
        - XXXXX
      - hotfix
        - XXXXX
        - XXXX

  3. 确认来源分支和要合并的目标分支

  4. 确认是否是自己提交的commit以及change下的代码修改

  5. 标题书写提交的功能归属版本，如果是正常合并，可以只写版本，如果是pre和master合并的话，是只提交合并请求，不直接合并，需要发code review群里，进行review的话，就需要点以下蓝色文字添加WIP:或者手动输入

  6. 提交合并请求

  7. 进入合并页面，需要review的合并请求，发送代码合并的diff链接到钉钉群

 

多人协作的流程

 

 

 

代码开发提交规范流程

以上是目前的多人协作的代码管理的流程，以上图为借鉴，来阐述个人在这个多人协作中的代码提交的流程，按照时间线从左到右进行阐述

  1. 版本开始基于主分支master分支创建自己的feature开发分支，一个版本需要自行根据自己负责的内容进行模块拆分，拆分成多个开发分支

  2. 进入开发阶段，同步远程的分支到本地

  3. 代码开发完成之后，提交commit到自己的远程分支

  4. 在gitLab提交合并请求，将自己功能分支的代码合并到固定分支（详细的合并提交规范看上面）

  5. 如果合并存在冲突，看下面解决冲突的流程，没有冲突，可以忽略这一步

  6. 合并之后，就可以在自动构建平台，进行发版构建操作

  7. 按照上面的 合并提交规范 依次提交合并更新

  8. 到要合并pre环境的时候，就需要按照 提交合并请求规范 来执行合并操作了

  9. 到要合并master环境的时候，详看 合并规范 第五步来考虑源分支，并按照 提交合并请求规范 来执行合并操作

 

  • 注：

    • 以上提的所有开发分支，除了master之外，不允许拉取任何固定分支，以此来保证自己的开发分支，只保留了自己的开发代码，不会被别的的代码污染

    • 所有向固定分支合并的前提，一定要满足条件，才能合并

    • 出现冲突不要在gitLab上解决冲突，要使用下面的解决流程解决

    • 根据自己负责的内容进行模块拆分，拆分成多个开发分支，是为了保证，突发情况，有其中一个功能不上线的情况，可以及时作出反应

 

解决代码合并冲突流程（教程）

 

 

如上多人协作流程图所示，多人协作，肯定会出现和他人代码冲突的情况出现，所以，特此输出一套，符合目前多人协作的解决冲突的流程，详看如图所示：

  1. 首先在本地开发，在自己的feature分支进行开发

  2. 开发完之后，将本地的commit推送到远程的分支，然后在gitLab对要更新的环境分支进行合并

  3. 提交合并请求出现代码冲突。关闭合并请求

  4. 基于自己要合并的目标分支创建一个第三方的merge分支（分支命名规范看命名规范篇）

  5. 本地执行git fetch -a或其它方式同步远程分支，然后本地切换到merge分支

  6. 本地的merge分支拉取远程的feature分支

  7. 在本地解决冲突，解决完之后推送到当前merge分支的远程

  8. 在gitLab上提交merge分支和要更新的环境分支进行合并

  9. 合并完成之后，就可以构建发布对应的环境了，然后删除merge分支

  10. 本地就可以继续切换回feature分支继续开发

 

  • 注：

    • 每次合并出现冲突都要执行上面的这个解决冲突的流程，重新创建第三方的merge分支解决

    • 这样虽然很麻烦，但是可以保证自己的feature分支不需要拉dev这种公共分支，导致自己的feature分支污染

    • 所以，就可能会产生，对dev有冲突，执行一遍，创建一个merge_dev分支，对test有冲突又执行一遍，创建一个merge_test分支，这种情况可以接受，（如果有更好的意见和方案，欢迎探讨）

 

合并紧急情况

合并revert

当出现意外，将不该合并的分支，进行了合并操作，可以进行以下操作，做回退操作

 

 

 

如上图所示，找到误操作合并的记录，进入到合并的详情，点击中间的黄色的revert按钮，就出现了上图的弹窗

  1. 下拉框选当时合并进的目标分支，也是这里要会退的分支

  2. 勾选创建一个新的merge请求

  3. 然后点击revert执行合并请求就OK了

注：由于gitLab的特性原因，revert操作会导致一些副作用，例如：回退的commit不会再出现在合并请求中。所以，revert操作需要谨慎使用，最好不要使用。

 

Cherry-pick

该操作可以用来挽救开发分支被污染之后，通过git帮忙找回历史的提交代码的

 

 

 

 

如上图所示，是一个简单的流程图，详细讲解如下：

  1. 首先我们的开发分支只允许对固定分支执行merge操作，不允许拉取固定分支的，也不允许和其他分支进行混合

  2. 所以，如果真的因为误操作导致了自己的开发分支被别的分支污染了，可以采取以上流程解决，但是请谨慎操作

  3. 分支被污染之后，首先需要基于master重新创建一个新的功能分支，这个时候这个新功能分支是没有任何代码修改的

  4. 然后去自己旧的功能分支里面找到自己之前提交的功能的commit

  5. 然后依次在gitLab上对commit执行cherry-pick操作

  6. 选取目标分支是新开发分 
  7. 然后执行合并请求就好了

  8. 最后，当多个commit都合并完成之后，就可以删除旧的开发分支了

posted @ 2023-03-02 17:09  鹿lu  阅读(372)  评论(0)  编辑  收藏  举报