针对中小安卓项目团队合作开发的GIT规范

针对中小安卓项目团队合作开发的GIT规范

针对中小型的安卓项目,基于gitflow流做的简化版本

Android分支策略

在开发过程中,多人协作,可能会涉及到同时修复bug,发布,开发等工作,开发的的featrue也并不一定全部要发布,因此,有一个适当的分支策略能够避免很多麻烦。本文参考gitFlow,重新因地制宜我们Android 的分支策略。
因为Android现在人少,任务简单,很多繁琐复杂的操作流程,就省略了,因此和gitFlow流有一定区别。

分支及职责

  • master: 始终保持最新可发布(必须可编译运行)
  • release:始终保持预发布代码(必须可编译运行)
  • develop: 始终保持最新可运行(必须可编译运行)
  • hotfix: 热修复分支(补丁分支)
  • bug/xxx: 解决预发布/发布以后的单一bug
  • feature/xxx: 实现单一可描述的特性( 不是按照人员分工拉的分支)
  • refactor/xxx: 一个可描述特征的重构分支
  • test/xxx:实验性功能,测试代码的分支(可以自由发挥,一般不合并回开发分支)
  • name/xxx:如果是自己要搞事情,写实验功能等,比如:zjie/learn

分支新增及合并流程

  • 版本开发过程

    1. develop切出feature/xxx,作为一个可描述功能特性的开发分支(xxx代表新的特性,下同)
    2. 开发过程中,请时刻保持从develop合并最新的代码到feature/xxx
    3. xxx特性开发完成之后:
      if(确认本次发布会包含本特性){
         合回develop,然后删除feature/xxx分支。
      }else{
        放在feature/xxx等到产品确认需要发布后,合并回develop;
         然后删除feature/xxx分支。
      }
    4. 合并到develop的bug修复:
      if(已经预发布release分支){
        已经预发布,原则上不再修改release分支代码,如果的确需要在本版本中修复,请按照如下流程:

      1. release拉取bug/xxx分支(xxx表示bug编号);
      2. 修复完成以后给测试人员测试(必须说明每一行修改代码受影响的地方);
      3. 测试完成后,合并回develop分支,同时合并回release,删除bug/xxx
        / 原则上这一步的bug不会太多,否则就是预发布时机有问题。 /

        已经预发布,原则上不再修改release分支代码,如果不需要在本版本中修复,请按照如下流程:

      1. release拉取bug/xxx分支(xxx表示bug编号);
      2. 修复完成以后,合并到develop分支;

      }else{
        直接在develop分支修复
      }

  • 版本发布过程
    1. 特性开发完成,测试确认,封包的时候,从develop合并release分支;
    2. 打包release给测试,测试基于此版本测试;
    3. 原则上不在修改代码,如遇到必须在本版本中修复的bug:
      1. release拉取bug/xxx分支(xxx表示bug编号);
      2. 修复完成以后必须给测试人员测试(必须说明每一行修改代码受影响的地方);
      3. 测试完成后,合并回develop分支,同时合并回release,删除bug/xxx
        原则上这一步的bug不会太多,否则就是预发布时机有问题。
    4. 正式发布,把 master分支指向release分支(git checkout master | git pull | git reset --hard release),添加版本tag,再把release合并代码到develop,发布成功以后;
    5. 删除上个版本的所有bug/xxx(因为这些已经合并进入develop,并且没有发布补丁包的需要了)
  • 线上问题修复过程
    1. master切出分支bug/xxx,作为该修复的开发分支(xxx代表问题描述或编号,下同)
    2. 基于此bug/xxx分支进行bug修复和验证;
    3. 修复完成以后,合并回develop分支;
    4. 如果需要发布补丁包,从master拉出hotfix分支,合并需要修复的bug对应的bug/xxxhotfix;
    5. 打包给测试人员测试,测试验证无误后,合并回master,发布,打tag,删除hotfixbug/xxx
  • 重构的开发

    1. develop拉出refactor/xxx分支,在此分支上面开发;
    2. 开发时,时刻保持合并最新的develop,具体的操作方法是:
      1. develop创建新的分支refactor/develop_merge;
      2. refactor/xxx分支合并到refactor/develop_merge
      3. 切换到refactor/xxx分支,然后直接reset refactor/xxx分支到refactor/develop_merge分支(git checkout refactor/xxx | git reset --hard refactor/develop_merge);
      4. 删除refactor/develop_merge分支。
        说明:1、始终保持一个 原则,就是从重构的子分支,往主分支合并;2、合并以后,建议使用reset来回归分支名,不要使用重命名,因为这样会丢失本地分支和远程分支的关联。3、不熟悉流程的时候,可以先从 refactor/xxx创建一个 refactor/xxx_back备份一下代码,避免误操作。
    3. 开发完成,打包给测试人员测试;
    4. 测试人员测试无误后,合并回develop分支,删除refactor/xxx分支。
  • 其他

    1. 已经push的代码,禁止直接使用reset的方式回退,可以使用revert回退某个节点的操作
    2. 禁止使用 git push -f,因为其他人可能已经合并了新版本的代码,最后会把回退的代码合并回来。
    3. 禁止直接往masterrelease提交代码(会导致合并冲突)
    4. 解决冲突需要谨慎,如果冲突的代码是其他人的提交内容,务必切磋清楚
    5. 先保证生成本地commit再fetch、merge或pull
    6. 如果遇到不决的问题及时讨论
    7. 本流程是很简化的流程,随着开发的复杂,人员的增多,产品线的增多,需要随时反馈和完善。

你可能感兴趣的:(android,git)