这是一个创建于 926 天前的主题，其中的信息可能已经有所发展或是发生改变。
之前只开发一期需求的时候，是采用 dev 分支包含最新代码，在 feature 分支上开发，向 dev 分支提 PR 的模式。
目前一期需求进入测试阶段，不希望包含二期需求已经在开发的代码。如果采用 dev 切出 release 分支保持一期代码纯净，dev 上继续合并二期代码的思路，看起来好像没什么问题？那如果 release 上的代码还需要继续迭代，在这个迭代过程中，可能需要同时修改 dev 和 release 都包含的一些公共代码，这时候就需要先从 release 切出 feature ，在 feature 开发完成后 PR 到 release ，再把 release PR 到 dev ？
这个过程有问题吗？改一次代码提两次 PR 感觉怪怪的，有更合理的管理方案吗？
 | 1 hamsterbase 2023-06-03 11:35:09 +08:00 1. master 为基线，只包含上次发布的代码 2. release/a.b.c 为迭代分支，迭代分支只包含当前代码。 3. 每个迭代可以单独的部署，提测前需要合并最新的 master 基线。 4. 平时开发流程为 创建分支，往迭代合并。 不允许直接合并 master 5. 迭代发布后打 tag, va.b.c 。 |
 | 2 ahonn 2023-06-03 14:50:13 +08:00 via iPhone 理论上都拉出来 release 分支了，那么这个分支上后续应该只会有 bugfix 没有 feature ，不然这就不算 release 了。bugfix 修完 PR 到 release ，合入后就可以直接 cherry-pick dev 分支，dev 分支是始终包含前一个 release 上的代码的。 |
 | 3 Hug125 2023-06-03 15:15:15 +08:00 1. master 为基线，只包含上次发布的代码 2. feature A.B.C 为需求分支 3. dev/test 分支 基于 master 分支 不进行任何开发，只将 feature 合并到 dev/test 分支 部署到测试环境 4. 完成 feature 后将 feature 分支 PR 到 master 分支，打 tag 。 5. 以此时的 master 为基线，重复 1-4 假设 feature 分支 A 和分支 B 分别用于开发一期和二期需求， 如果分支 B 需要依赖分支 A 的代码，如果少量 commit 直接从 A 分支 cherry-pick 过来。 如果 B 大量依赖 A 的话，可以暂时将 A 合并到 B 但是一期需求只能提交到 A ，保证 A 分支不包含二期的代码，二期需求提交到 B 分支，保证二期需求正常开发。只要 A 先于 B 合并到 master 分支，就不会出现问题。 |
 | 4 Oz37sW2w3MIZf56o 2023-06-03 15:46:04 +08:00 我感觉你被分支的名字迷惑了， 第一期代码在 dev 分支上并且在测试，然后你们开发又是在 feature 分支上，那么其实 dev 分支对应测试环境； 第二期代码在 feature 分支开始开发，那么到第一期测试完上线之前为止两个分支就够了，第二期的 feature 分支不要向 dev 合并； 第一期改 bug 可以直接提交到 dev ，然后合并到第二期的 feature 分支； 第一期测试完成，上线时再分出 release 分支。 |
 | 5 Anarchy 2023-06-03 16:05:02 +08:00 via Android 切 release 之后 release 只会有 bugfix 了，改完 release 并发布新的版本后就把代码合回 dev 。已发版为准就没有感觉操作多余的问题了。 |
 | 6 jaredyam OP @Anarchy 合回 dev 可以自动化么，相当于每次 PR 到 release 都需要将这次 PR 的内容合回 dev ？ |
| 7 jaredyam OP @Hug125 “假设 feature 分支 A 和分支 B 分别用于开发一期和二期需求” > 我们试过 dev 和 feature 分支 B 分别开发一期和二期需求，dev 部署到测试环境，这样如果 dev 上有公共代码的话就需要 PR 到 dev ，再把 dev 上的新代码 PR 到 release ？一期结束后又需要把 releaseB 合回 dev ？ 感觉这里既存在一次代码更新提两次 PR 的问题，也存在分支相互合的问题？ 不过你提到的 featureA 和 featureB 思路好像和我描述的很像又不太一样？ |
| 8 jaredyam OP |
| 9 jaredyam OP @hamsterbase 这种情况下更新公共代码怎么处理？先 PR 到其中一个 releaseA ，再把同步 releaseA 作为 PR 合到其它 release ，最后保证 releaseA 先 PR 到 master ？看起来和#3 是一个思路 |
| 11 hamsterbase 2023-06-03 17:04:22 +08:00 @jaredyam release 不能合并其他的 release 分支。 只有 master -初始化-> release 和 release -发布-> master 如果公共代码，可以分别 PR 到 release A 和 release B |
| 12 ahonn 2023-06-03 18:20:19 +08:00 @jaredyam 是，但怎么合不是问题（我之前用过的平台是在 PR 合入后有按钮可以直接 cherry-pick ）。 关键是 release 分支上面只能做 bugfix ，release 合完后 bugfix 要同步到 dev 分支。 |
 | 13 hauzerlee 2023-06-03 18:47:32 +08:00 |
 | 14 jdOY 2023-06-03 18:55:12 +08:00 只能配合规章制度强制管控，不然就是有人偷偷代码下毒 |
 | 15 akira 2023-06-03 19:17:41 +08:00 在一期里面属于 功能 feature 的东西，在二期属于 bug ，遇到这种问题你们怎么办 |
 | 16 xuanbg 2023-06-03 20:02:28 +08:00 当然是新功能新分枝。唯一要注意的是新功能的依赖不能是任何开发中的功能。 |
Select Language