仓库代码同时开发当期和下期需求，为保证当期需求代码不包含下期需求代码，如何管理分支更合理？

[jaredyam]

之前只开发一期需求的时候，是采用 dev 分支包含最新代码，在 feature 分支上开发，向 dev 分支提 PR 的模式。

目前一期需求进入测试阶段，不希望包含二期需求已经在开发的代码。如果采用 dev 切出 release 分支保持一期代码纯净，dev 上继续合并二期代码的思路，看起来好像没什么问题？那如果 release 上的代码还需要继续迭代，在这个迭代过程中，可能需要同时修改 dev 和 release 都包含的一些公共代码，这时候就需要先从 release 切出 feature ，在 feature 开发完成后 PR 到 release ，再把 release PR 到 dev ？

这个过程有问题吗？改一次代码提两次 PR 感觉怪怪的，有更合理的管理方案吗？

[hamsterbase]

1. master 为基线，只包含上次发布的代码
2. release/a.b.c 为迭代分支，迭代分支只包含当前代码。
3. 每个迭代可以单独的部署，提测前需要合并最新的 master 基线。
4. 平时开发流程为 创建分支，往迭代合并。 不允许直接合并 master
5. 迭代发布后打 tag, va.b.c 。

[ahonn]

理论上都拉出来 release 分支了，那么这个分支上后续应该只会有 bugfix 没有 feature ，不然这就不算 release 了。bugfix 修完 PR 到 release ，合入后就可以直接 cherry-pick dev 分支，dev 分支是始终包含前一个 release 上的代码的。

[Hug125]

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 分支，就不会出现问题。

[Oz37sW2w3MIZf56o]

我感觉你被分支的名字迷惑了，
第一期代码在 dev 分支上并且在测试，然后你们开发又是在 feature 分支上，那么其实 dev 分支对应测试环境；
第二期代码在 feature 分支开始开发，那么到第一期测试完上线之前为止两个分支就够了，第二期的 feature 分支不要向 dev 合并；
第一期改 bug 可以直接提交到 dev ，然后合并到第二期的 feature 分支；
第一期测试完成，上线时再分出 release 分支。

[Anarchy]

切 release 之后 release 只会有 bugfix 了，改完 release 并发布新的版本后就把代码合回 dev 。已发版为准就没有感觉操作多余的问题了。

[jaredyam]

@Anarchy 合回 dev 可以自动化么，相当于每次 PR 到 release 都需要将这次 PR 的内容合回 dev ？

[jaredyam]

@Hug125 “假设 feature 分支 A 和分支 B 分别用于开发一期和二期需求”

> 我们试过 dev 和 feature 分支 B 分别开发一期和二期需求，dev 部署到测试环境，这样如果 dev 上有公共代码的话就需要 PR 到 dev ，再把 dev 上的新代码 PR 到 release ？一期结束后又需要把 releaseB 合回 dev ？

感觉这里既存在一次代码更新提两次 PR 的问题，也存在分支相互合的问题？

不过你提到的 featureA 和 featureB 思路好像和我描述的很像又不太一样？

[jaredyam]

@ahonn “合入后就可以直接 cherry-pick dev 分支”

我们的 dev 只能通过 PR 合入代码，这个还是相当于每次 PR 到 release 的代码还需要 PR 到 dev 是吧？

[jaredyam]

@hamsterbase 这种情况下更新公共代码怎么处理？先 PR 到其中一个 releaseA ，再把同步 releaseA 作为 PR 合到其它 release ，最后保证 releaseA 先 PR 到 master ？看起来和#3 是一个思路

[jaredyam]

@chenyduan 你看下是不是我在#7 描述的情况？ release -> featureB

[hamsterbase]

@jaredyam release 不能合并其他的 release 分支。


只有 master -初始化-> release 和 release -发布-> master

如果公共代码，可以分别 PR 到 release A 和 release B

[ahonn]

@jaredyam
是，但怎么合不是问题（我之前用过的平台是在 PR 合入后有按钮可以直接 cherry-pick ）。
关键是 release 分支上面只能做 bugfix ，release 合完后 bugfix 要同步到 dev 分支。

[hauzerlee]

@jaredyam #7 我觉得 @Hug125 所说的就是对应你现在两期需求同时开发的情况。dev 合并回 二期分支这个动作不需要每次提交都要做。如果两期需求的代码，最终会合并成同一套代码的话，定期（比如每天，或者修改了重大 bug 时）合并就行了。可以理解为 二期分支在同步跟踪 dev 或一期分支，但又不需要每次都实时跟踪。

[jdOY]

只能配合规章制度强制管控，不然就是有人偷偷代码下毒

[akira]

在一期里面属于 功能 feature 的东西，在二期属于 bug ，遇到这种问题你们怎么办

[xuanbg]

当然是新功能新分枝。唯一要注意的是新功能的依赖不能是任何开发中的功能。