分支命名
origin/master
和线上代码一致，随时可以切出打热修复补丁
origin/develop
开发主干分支
release_功能名(版本名)
功能主干分支
feature/功能名_模块名
功能子分支，开发完成后，发起pr到功能主干分支，通过后删除此分支，因此存活时间为1~2天
hotfix_bug名(版本名)
修复bug分支，一般从master切出，打完热修复立刻合并到master分支。
PR提交规范
目的：通过降低审核者的阅读门槛，提高pr的审核效率，从而保证项目的开发进度。
PR的颗粒尽可能小，基于一个小功能（开发时间4h以内），标题要写明pr目的
-
PR备注必须声明1：修改点 2：影响范围
pr描述 PR除了添加审核人之外，如果多现有代码逻辑上有修改的，则同步@现有代码作者
在提交PR，告知参与人之后，可以继续开发，后续代码推送到新分支。审核者有意见需要返工修改时，再从pr分支切出来统一修改
分支职责
- master分支，能切出来打hotfix
- develop分支，优化、修改的点，和迭代的业务功能没关系（改动可以合并进各个feature）
- feature分支，独立的功能分支，从develop分支切出，不和其他迭代代码污染(不合并release分支)
- release分支，要发布版本的分支，合并了develop分支、各个feature分支
操作步骤
-
主管建分支
主管新建分支 feature、hotfix ，分支任务工作量0.5-1个工作日，每个commit的代码修改目的清晰 -
组员切分支
组员从分支切出，如果该分支就一人负责(分支名已经描述了要做的事儿)，则远程分支添加后缀-review；多人共同开发的，则添加后缀-功能名
-功能名
-
开发完自审
开发完成，自测没问题后准备提交，先依次自己回审Commit Changes里的文件、排查是否有IDE提示
android studio 图形化commit界面 -
发起代码回审
发起后，在im上通知审核人
image.png -
code review
代码回审发现问题，通过评论的方式指出，一波结束后，在im上通知发起人。
TIM截图20180510170256.png 结束代码回审
问题改完后，审核人合并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：其余注释、删除文件之类的
分支生命流程
- develop切出开发若干分支 feature_xxx、feature_xxx等
- 要发版本，从develop分支切出release_版本号（记得更新app版本号） ，依次合并各个feature_xxx
- 根据测试提出问题修改bug，提交到feature_xxx，再向release_发起pr。
- 上线后 发起release到master的的pr，并基于master打出tag
- master依次向develop、各个开发主干分支发起pr，同步代码
release本身不接收任何代码commit，会导致增加剥离feature的难度。
有线上bug，从develop切出hotfix代码，改完推向develop。并发pr到release_
