feature分支
涉及多人协作或者大功能的开发, 应该从dev分支checkout出独立的feature分支, 避免干扰dev分支
场景:
涉及多人协作: 团队多个成员在同一个项目下负责开发不同的功能...方便跟踪历史记录, 也免于干扰dev分支的迭代和发布
命名规范
feature/name: name是功能名称
feature/GZB_version: 这也是团队常见的模式, 当无法使用一个功能名称来描述时...合并到dev后, feature分支的生命周期就结束了. 后续bug修复和功能优化直接在dev开发
当多个feature分支需要合并对外发布临时版本时. 合并到preview分支 ....一个提交不应该做超过2个功能的变动
问题是什么导致的?
简短说明使用什么方式, 策略, 修复了问题.
提交改变了什么, 让其他reviewer更容易审核代码和忽略无关的改变
为什么进行这次提交?...使用分支模式的缺点有:
解决办法
有些场景确实无法通过代码层面解决, 比如ios应用定制启动图, icon, 应用名称, 外观等等.