android自用规范三：git篇

分支命名

origin/master

和线上代码一致，随时可以切出打热修复补丁

origin/develop

开发主干分支

release_功能名(版本名)

功能主干分支

feature/功能名_模块名

功能子分支，开发完成后，发起pr到功能主干分支，通过后删除此分支，因此存活时间为1~2天

hotfix_bug名(版本名)

修复bug分支，一般从master切出，打完热修复立刻合并到master分支。

PR提交规范

目的：通过降低审核者的阅读门槛，提高pr的审核效率，从而保证项目的开发进度。

1. PR的颗粒尽可能小，基于一个小功能（开发时间4h以内），标题要写明pr目的

2. PR备注必须声明1：修改点 2：影响范围
   

   

   pr描述

3. PR除了添加审核人之外，如果多现有代码逻辑上有修改的，则同步@现有代码作者

4. 在提交PR，告知参与人之后，可以继续开发，后续代码推送到新分支。审核者有意见需要返工修改时，再从pr分支切出来统一修改

分支职责

1. master分支，能切出来打hotfix
2. develop分支，优化、修改的点，和迭代的业务功能没关系（改动可以合并进各个feature）
3. feature分支，独立的功能分支，从develop分支切出，不和其他迭代代码污染(不合并release分支)
4. release分支，要发布版本的分支，合并了develop分支、各个feature分支

操作步骤

1. 主管建分支
   主管新建分支 feature、hotfix ，分支任务工作量0.5-1个工作日，每个commit的代码修改目的清晰
2. 组员切分支
   组员从分支切出，如果该分支就一人负责(分支名已经描述了要做的事儿)，则远程分支添加后缀-review；多人共同开发的，则添加后缀-功能名

-功能名

3. 开发完自审
   开发完成，自测没问题后准备提交，先依次自己回审Commit Changes里的文件、排查是否有IDE提示
   

   

   android studio 图形化commit界面

4. 发起代码回审
   发起后，在im上通知审核人
   

   

   image.png

5. code review
   代码回审发现问题，通过评论的方式指出，一波结束后，在im上通知发起人。
   

   

   TIM截图20180510170256.png

6. 结束代码回审
   问题改完后，审核人合并pr，结束后，发起分支自动被删除，代码合并到目标分支。

举个例子：

单人开发
挑战结果页面修改，工作量评估一人半天完成
组长开分支：feature/challengeResultUiFix
组员从此分支切出，改完后，推到远程分支feature/challengeResultUiFix-review，发起PR
多人开发
智能辅导开发，工作量评估需要多人N天完成
组长开分支:feature/smartCoach
组员A负责答题:feature/smartCoach-answer
组员B负责结果页面:feature/smartCoach-result
开发完成后，从当前分支feature/smartCoach-answer 往 feature/smartCoach，发起PR

commit前缀

feat：功能修改；fix：bug修复、内容+bug地址；style：其余注释、删除文件之类的

分支生命流程

1. develop切出开发若干分支 feature_xxx、feature_xxx等
2. 要发版本，从develop分支切出release_版本号（记得更新app版本号） ，依次合并各个feature_xxx
3. 根据测试提出问题修改bug，提交到feature_xxx，再向release_发起pr。
4. 上线后 发起release到master的的pr，并基于master打出tag
5. master依次向develop、各个开发主干分支发起pr，同步代码

release本身不接收任何代码commit，会导致增加剥离feature的难度。
有线上bug，从develop切出hotfix代码，改完推向develop。并发pr到release_