针对中小安卓项目团队合作开发的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/xxx到hotfix;
5. 打包给测试人员测试，测试验证无误后，合并回master，发布，打tag，删除hotfix和bug/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. 禁止直接往master，release提交代码(会导致合并冲突)
4. 解决冲突需要谨慎，如果冲突的代码是其他人的提交内容，务必切磋清楚
5. 先保证生成本地commit再fetch、merge或pull
6. 如果遇到不决的问题及时讨论
7. 本流程是很简化的流程，随着开发的复杂，人员的增多，产品线的增多，需要随时反馈和完善。

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

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

Android分支策略

分支及职责

分支新增及合并流程

更多相关文章

随机推荐