Doc: 补充多包的开发流程

packages/accureleaser/README.md

@@ -93,10 +93,11 @@
 <details><summary>1) 单个包</summary>
 
 - 在仓库中 `bomb` 包的 `3.2.4` 正式版本的基础上进行开发。
+  开发的第一次提交是将版本号改为 `bomb@3.2.4-dev.autoExplode.alpha.0` 。
 
 - 提交了几次，比如添加了爆炸函数。
 
-- 感觉自己可以了，修改版本号——这次提交产生了一个开发版本 `bomb@3.2.4-dev.autoExplode.alpha.0` ，被管理工具自动发布。
+- 感觉自己可以了，修改版本号——这次提交产生了一个开发版本 `bomb@3.2.4-dev.autoExplode.alpha.1` ，被管理工具自动发布。
 
 <details><summary>2) 单分支</summary>
 
@@ -170,6 +171,50 @@
 
 </details><!-- 1) 单个包 -->
 
+<details> <summary>1) 多个包</summary>
+
+- 以仓库中好多个包，比如 `bomb@3.2.4` 和 `detect@5.3.2` ，为基础进行开发。
+
+  开发的第一次提交是将接下来要进行更改的包的版本改为 `-dev.<feature>.alpha.0` ——在此之后，任何一个包在有变更之前都要先改版本号为开发版本。
+  这是为了保证管理工具能够清晰地辨别哪些包被修改了，而哪些没有。
+  同时管理工具也应该具备寻找并修复那些被修改但忘记改版本号的包的能力。
+
+<details><summary>2) 单分支</summary>
+
+- 开发，仓库里各个包的开发版本不断递增。
+  可能递增的速度不一样，这是正常的。
+
+- 当某一个包的正式版更新后，来一次合并。
+
+  这里和单个包没什么区别。
+
+- 当分支的某些包到达足够合并的开发阶段后，可以对 `next` 或 `master` 分支进行一次 PR 。
+
+  管理工具要能找到哪些包可以被合并，而哪些包不能合并。
+  再只将那些可合并的包的代码的更改合并到 `next` 或 `master` 分支。
+
+  根据技术上的实现难度，寻找哪些包可以合并而哪些不能，可以分为两个等级：
+  1. 一刀切：
+
+     看分支依赖链上的分支是否所有包都到达指定阶段：
+     若有任意被依赖的分支并不是所有包都到达指定阶段，则本分支所有包都不合并；
+     否则，再看分支内有没有未到达指定开发阶段的包：
+     若有，则所有包都不合并；
+     若无，则所有包都可以合并。
+  2. 根据包间的依赖关系进行分析：
+
+     建立每个包的依赖树：
+     首先根据 `package.json` 找到这个包在同一分支内所依赖的处于开发状态的包；
+     再根据依赖分支链中上一层分支里这个包是否是开发版本来断定这个包是否依赖于上一层分支的自己。
+     就这么不断往下构建依赖树，直到找不到其他依赖为止就算构建完成。
+     若树上有任意版本未达到开发状态，则这个包不能被合并。
+
+</details><!-- 2) 单分支 -->
+
+-----
+
+</details><!-- 1) 多个包 -->
+
 ## 其他包发布流程
 
 对于其他包，对应的发布流程各有不同。