工作流总结
研发流程
分支策略比较
| 模式 | 并发收益 | 并发维护成本 | 验收集成效率 | 分支合入成本消耗 |
|---|---|---|---|---|
| 单常驻分支 (e.g. master开发上线) |
1 | 紧急发布要隐藏代码 | 通常验证1次 | 合并次数=1，功能合入主干 |
| 双常驻分支 (e.g. dev开发 master上线) |
2 | 中等，hotfix不需要隐藏代码 | 验证2次 | 合并次数=3，功能合入双主干+双主干间集成 |
| 三个以上常驻分支 (e.g. 每种环境对应分支) |
3 | 较少，多环境不需要隐藏代码 | 需要验证多次 | 合并次数=5，功能合入三主干+三主干间传递 |
| 总结 | 并发效率可以认为是线性增长的n | 主干越多对代码侵入越小 | 当测试自动化测试和环境自动化测试够强后，该项成本平稳 | 合并工作和出错出冲突修复的概率线性增长 2*n-1 |
分支规范最佳实践
使用特性分支开发
每个需求一个独立分支，使用需求的ID号作为分支名称，用于隔离并行开发造成的干扰。
好处：是一种工程实践， 使用它的人直到他所开发的特性“完成”后才合并回主干。
持续集成主干
所有需求在一个分支做每日集成，并辅助一些自动化测试手段，及时发现集成问题。
好处：是一种工程实践，用于确保你的软件一直是可以工作的，并且在几分钟内你就能够得到关于 “你的修改是否破坏了系统”的反馈。
专门拉取发布分支进行发布工作
在发布时，将集成好的主干拉出或同步到用于发布的分支上，屏蔽发布中的修改，支持做一些hotfix或临时patch合入。
分支策略解析
轻量模块采用“单常驻分支模式”
可用于新项目早期或者1-3人协作的项目开发适用，以master作为主分支（常驻分支），基于master拉出feature分支，开发完成后合并回master，基于master发布。
优劣：合入成本低，revert成本高，需要配合严格的准入流程。所有紧急正常的修改全在主干上，开发了一半的东西如果要上线的话，要巧妙的藏起来。对程序的结构提出了高要求，分分合合要方便，用好的话，需要功能开关配置。
重要模块采用“双常驻分支模式“
master分支：作为发布分支，紧急hotfix除外，不允许开发直接合并到master分支，发布完成后打tag，特定的版本的hotfix必须以tag为基线拉分支修复，完成后合并到master，hotfix确认完成增加hotfix版本tag。打tag时记得写release note。
dev分支：日常开发基线分支，迭代中开发从dev分支拉出开发分支，完成并通过强制的code review后合并回dev分支，开发者有责任保持私有分支与dev分支同步并解决可能的合并冲突；特定版本的hotfix的开发者负责发布后将hotfix合并到dev分支，并解决合并的潜在冲突；dev分支到master分支的mr由团队内release engineer角色的人负责，合并时不需要进行code review直接合入，编译发布后打对应版本tag。
基于主干的开发 trunk based development （TBD）
主干用于CI持续集成，按照实际场景可以使用固定的master或dev分支，或者团队成员约定一个动态变化的dev_2019作为主干，所有人从主干拉出开发分支，从主干合入。
发布分支可以有一个或多个，用于周期性发布，如固定的release分支或者动态分支如release1.0，非必要不允许hotfix直接合入。
多分支模式
客户端可能常见
日常开发流程
创建任务工单
从dev分支拉一个feature分支出来
git checkout -b WEBARCHBIZ-123456-DO-SOME-THING写代码，写单测
确认代码格式规范，推荐使用ide的format调整功能
提交代码
git push origin WEBARCHBIZ-123456-DO-SOME-THING发起merge request，在description中写清楚本次提交的内容，尽量保证每个mr只做一件事情，提交后提醒peer及时review
code review通过后，合入dev分支，会自动发布到沙盒，可以在沙盒环境测试和验证你的修改。
如果有重要的功能变更，在沙盒集成测试中补充相应的testcase
上线流程
- 发起从dev分支到master分支的merge request，approve后方可合入master（日常迭代上线时间是周二和周四）。
- 合入master后，pipeline会自动发起，流程中会有一个人工checkbpoint的lark卡片通知，需要人工确认。
- 上线完成后在线上进行验证测试，确认功能无异常。
- 对用户有感的变更，在产品文档上填写release note。
