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

2023-06-03 11:07:04 +08:00
 jaredyam

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

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

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

1900 次点击
所在节点    git
16 条回复
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 。
ahonn
2023-06-03 14:50:13 +08:00
理论上都拉出来 release 分支了,那么这个分支上后续应该只会有 bugfix 没有 feature ,不然这就不算 release 了。bugfix 修完 PR 到 release ,合入后就可以直接 cherry-pick dev 分支,dev 分支是始终包含前一个 release 上的代码的。
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 分支,就不会出现问题。
Oz37sW2w3MIZf56o
2023-06-03 15:46:04 +08:00
我感觉你被分支的名字迷惑了,
第一期代码在 dev 分支上并且在测试,然后你们开发又是在 feature 分支上,那么其实 dev 分支对应测试环境;
第二期代码在 feature 分支开始开发,那么到第一期测试完上线之前为止两个分支就够了,第二期的 feature 分支不要向 dev 合并;
第一期改 bug 可以直接提交到 dev ,然后合并到第二期的 feature 分支;
第一期测试完成,上线时再分出 release 分支。
Anarchy
2023-06-03 16:05:02 +08:00
切 release 之后 release 只会有 bugfix 了,改完 release 并发布新的版本后就把代码合回 dev 。已发版为准就没有感觉操作多余的问题了。
jaredyam
2023-06-03 16:37:21 +08:00
@Anarchy 合回 dev 可以自动化么,相当于每次 PR 到 release 都需要将这次 PR 的内容合回 dev ?
jaredyam
2023-06-03 16:50:49 +08:00
@Hug125 “假设 feature 分支 A 和分支 B 分别用于开发一期和二期需求”

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

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

不过你提到的 featureA 和 featureB 思路好像和我描述的很像又不太一样?
jaredyam
2023-06-03 16:54:09 +08:00
@ahonn “合入后就可以直接 cherry-pick dev 分支”

我们的 dev 只能通过 PR 合入代码,这个还是相当于每次 PR 到 release 的代码还需要 PR 到 dev 是吧?
jaredyam
2023-06-03 16:59:06 +08:00
@hamsterbase 这种情况下更新公共代码怎么处理?先 PR 到其中一个 releaseA ,再把同步 releaseA 作为 PR 合到其它 release ,最后保证 releaseA 先 PR 到 master ?看起来和#3 是一个思路
jaredyam
2023-06-03 17:03:01 +08:00
@chenyduan 你看下是不是我在#7 描述的情况? release -> featureB
hamsterbase
2023-06-03 17:04:22 +08:00
@jaredyam release 不能合并其他的 release 分支。


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

如果公共代码,可以分别 PR 到 release A 和 release B
ahonn
2023-06-03 18:20:19 +08:00
@jaredyam
是,但怎么合不是问题(我之前用过的平台是在 PR 合入后有按钮可以直接 cherry-pick )。
关键是 release 分支上面只能做 bugfix ,release 合完后 bugfix 要同步到 dev 分支。
hauzerlee
2023-06-03 18:47:32 +08:00
@jaredyam #7 我觉得 @Hug125 所说的就是对应你现在两期需求同时开发的情况。dev 合并回 二期分支这个动作不需要每次提交都要做。如果两期需求的代码,最终会合并成同一套代码的话,定期(比如每天,或者修改了重大 bug 时)合并就行了。可以理解为 二期分支在同步跟踪 dev 或一期分支,但又不需要每次都实时跟踪。
jdOY
2023-06-03 18:55:12 +08:00
只能配合规章制度强制管控,不然就是有人偷偷代码下毒
akira
2023-06-03 19:17:41 +08:00
在一期里面属于 功能 feature 的东西,在二期属于 bug ,遇到这种问题你们怎么办
xuanbg
2023-06-03 20:02:28 +08:00
当然是新功能新分枝。唯一要注意的是新功能的依赖不能是任何开发中的功能。

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/945434

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX