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

› Pro Git

› Atlassian Git Tutorial

› Pro Git 简体中文翻译

› GitX

This topic created in 1101 days ago, the information mentioned may be changed or developed.

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

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

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

dev

代码

release

分支

16 replies • 2023-06-03 20:02:28 +08:00

hamsterbase

Jun 3, 2023

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

ahonn

Jun 3, 2023 via iPhone

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

Hug125

Jun 3, 2023

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

Jun 3, 2023

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

Anarchy

Jun 3, 2023 via Android

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

jaredyam

Jun 3, 2023

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

jaredyam

Jun 3, 2023

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

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

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

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

jaredyam

Jun 3, 2023

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

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

jaredyam

Jun 3, 2023

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

jaredyam

Jun 3, 2023

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

hamsterbase

Jun 3, 2023

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

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

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

ahonn

Jun 3, 2023

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

hauzerlee

Jun 3, 2023

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

jdOY

Jun 3, 2023

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

akira

Jun 3, 2023

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

xuanbg

Jun 3, 2023

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