这是一个旧的 issue，被我从 Hover 项目 issue 中移植过来，留档保存。
2018 年由 cyf 提出
“我们规范化了 Hover 项目中的流程，但是却没有规范化一个一个小项目的流程，现在 Album 等项目的流程并不是很 clean， 我们需要尽快梳理一下流程，来应对这个确实”
以Album为例子，现在的Album 只有master分支，release版本的tag 是打在master branch 上。这个应该是没有问题的。但是我觉得不够用，比如，今天我做了一些代码的重构，我希望这些改动马上进入Album，希望所有分支的代码在重构的基础上推进，这样可以避免重构的代码holding太久后导致无法再合进branch。但是问题来了，master 的4.1.2版本release给 ‘Hover’ 在为 ‘Hover’ 的 2.4.2 release 服务，不能够把重构的代码合进master（合master应该是在feture complete 自己测试没有问题的时候发布给Hover），这样情况就没有办法让所有分支都在重构的代码上推进。所以我觉得 ‘Album’ 中也应该引入 ‘Develop分支’。
然后我设想的分支策略是：
- develop ：公共的开发分支。feature 完成的时候，或者有重构完成的时候都应改进入该分支。所有新的feature也应该在develop上 checkout 出去，develop在 feature 完成的时候需要合并进master，并且只能使用 fast-forward 保证代码统一。
- master ：用来release的分支。在一个完整的feature 完成的时候可以提供给Hover集成的时候用 tag 的方式release 给 ‘Hover’，所有的hotfix直接在master上进行。
- master上的hotfix需要在当天合并回develop分支
我补充下，我们需要划分成越来越多的模块之后，我觉得有哪些东西我们应该尽快规范出来: - 制定出来一个比较好的模块开发的流程
- 分支策略是什么样 ?
- 如何进行 code review ?
- 如何维护和管理版本号 ?
- 每个模块，我们应该如何保证的质量，接口等等;
- 每个模块应该对外提供什么样的基本的文档 ?
- 每个模块应该做哪些基本的测试 ?
- 模块多的情况下，我们怎么简化我们的开发 ?
其他大家都补充哈~
更早的规范化这些流程，能够减少之后的开发工作的负担，减少之后踩坑的概率，我们尽早想清楚比较好。
From：ChenYuanfu
模块化规范
分支策略：
master：稳定的版本最终合并到 master 分支，并用来发布。 develop 分支需要 protected, 需要 code review。
develop:对于协同开发的模块（例如Album）需要使用 develop 分支，如果不需要协同开发，可以不使用develop分支。develop 分支需要 protected, 需要 code review。
关于 Release：
每个模块最终都是需要 release 一个稳定的版本给 ‘Hover’ 项目来使用。
我们的发布流程应该是：
- 将代码合进至 mater 分支（需要 code review）
- 在 master 升级模块的版本号
- master 分支添加与版本号一致的 ‘tag’，并 push mater 分支与 ‘tag’
- 升级私有 repo 库
Hover项目对模块的版本选择：
在 Hover 项目中，我们有 develop，release 分支。
对于 Hover 各个分支对模块版本的引用策略：
- develop：可以使用模块中的公共分支上的上的某个 ‘commit’ 版本（Podfile可使用模块中的公共开发分支上的 commit），在合并至 release 分支之前，必须使用模块中 master master 分支上的版本
- release：只能使用模块中 master 分支上的版本（Podfile中只能使用版本号）
关于Hotfix：
Hover 项目在进入提测阶段的时候，如果发现模块中有bug，需要进行Hotfix。
在各个模块中，hotfix 需要按照：
- 当前版本（Hover 的 release 分支使用的版本)checkout 出 fix 分支
- fix 分支合并进 mater 分支（需要 code review）
- 按照 Release 步骤升级版本
- 在 Hover 的 release 分支上指定 hotfix 完成后的版本
- 如果develop (模块的)也需要某一次具体的 hotfix 需要将 具体的fix cherry-pick 至 develop（模块的）
Code review:
需要review的场景：模块项目中所有向公共开发进行分支合并。
大家需要对 ‘Merge request’ 进行code review。在很多小项目中，之前是没有 code review 的，例如Hover-I18n项目中的修改，是直接在 master 分支修改然后直接推上去，这样其实会有很多的隐患（之前把release 版本中正在使用的多语言删掉了）， code review 可以上减少这种错误的发生。