背景
一个应用需要在多个区域（地区/城市/国家）单独部署，而且不同区域部署的版本不一样，比如区域A需要部署1.0.0，区域B需要部署1.1.0，区域C需要部署2.0.0。
假设目录结构如下
app/
common/ #应用功能核心代码，公共资源。
area-1/ #区域特定资源，如配置文件，静态数据等。
area-2/
area-3/
...
area-n/
package.json
分支管理
本文的分支管理模型参考A successful Git branching model调整。
- master：开发分支，从master拉的代码永远是最新的。
- prod/*：区域生产分支，每个区域有自己的生产分支，用于区域部署。
- feat：功能分支，合并到master，合并后被删除。
- fix：修复分支，合并到master和相关区域生产分支，合并后被删除。
代码提交
每个commit都加上前缀用于说明commit的代码改动是什么。
feat(scope):：新模块，新功能，新组件等。fix(scope):：功能bug修复。style(scope):：样式改动，纯CSS改动。docs(scope):：文档改动，如README。refactor(scope):：代码重构。注意代码重构指的是不改变任何现有功能的基础上使用更好的算法或逻辑重构现有代码。build(scope):：构建（编译/打包）相关，如修改webpack配置，修改babel配置等。chore(scope):：和前面的类型无关的杂项。如冗余代码清理，增删注释等。
每一个前缀都会有一个(scope)，表示本次commit的改动范围，可以是模块名，组件名，文件名等，如feat(auth): add reset password。有可能会出现无法指定(scope)的情况，这种情况下可以省略该部分，如chore: clean up redundant code。
注意：不要在一个commit里同时做多样事情，养成好习惯，没做完一个东西commit一次。
版本管理
现在前端项目，基本上都离不开npm这个包管理工具，所以我们可以使用npm的版本管理策略和命令来实现版本管理。
版本说明
定义版本号格式为major.minor.patch。
- major：主版本，如调整架构，调整框架，无法向后兼容的改动等。
- minor：副版本，如添加新功能，新特性等。
- patch：补丁版本，如bug修复。
操作命令
npm version [major|minor|patch]
npm version命令每次会做两个操作
- 更新package.json和package-lock.json的version字段。
- 添加一个git tag，tag名字为新的版本号。
欢迎大家提出意见或建议。
