1
fov6363 89 天前
基于 master 创建分支,提交验证,验证通过后,再 cherry-pick 到 prod 分支上,再次验证。两次验证通过后,就可以合并代码了。
两次验证可以保证今天 hotfix 和下次发版都不会有问题 |
2
yuanmomo 89 天前 via iPhone
hotfix 的分之一定是从跟 prod 环境一致的分支拉出来的。
|
![]() |
3
xmumiffy 89 天前
master 就不会有未完成的任务,只从 release 合并.hotfix 一般从 release 开始打,不急或者范围小的也可能从 feature 打
|
4
9c04C5dO01Sw5DNL 89 天前
master 对 release 上要 hotfix 的部分没有改动的话,hotfix 在基于二者创建都可以,cherry pick 一下就行了。
如果 master 对 release 上要 hotfix 部分已经发生改动了的花,老老实实在 release 上 hotfix 吧,完了还得在 master 上重新 hotfix |
5
renmu 89 天前 via Android
线上环境出问题当然从出问题的环境的分支进行修复
|
![]() |
6
totoro52 89 天前
master 出现未完成的代码这本身就很不对劲了
|
7
lovelylain 89 天前 via Android
你们把 master 当开发分支,另外弄了个 prod 当主干?
|
8
drymonfidelia OP @lovelylain 对,我去过的几家公司都这么干
|
9
kneo 89 天前 via Android
线上版本的 hotfix 肯定是基于线上版本的代码做分支,基于线上版本重现 bug ,基于线上版本验证 hotfix 。不可能基于 master 。
master 当然可以有未完成的功能。其实就相当于 dev 分支。这个由项目自己决定,我不觉得是什么问题。 |
![]() |
10
yogogo 89 天前
快跑
|
![]() |
11
7gugu 89 天前
直接从 prod 上切一个 hotfix ,弄完再合回去。不过 master 上包含未完成的代码也太野鸡了,真的是乱搞。
|
![]() |
12
panlatent 89 天前 via Android ![]() 看你遵循那哪个规范,hotfix 肯定是从最接近发布的分支来开。 拿 master 当开发/主干是可以的。但如果是开源项目且默认分支是 master ,包含未完成代码可能会对用户造成困扰。
|
13
crackidz 89 天前
cherry-pick 到 prod
|
14
han3sui 88 天前
基于 prod 拉 hotfix ,上线后,合并到 master ,重新测试
|
15
yc8332 88 天前
为啥没上线的功能会在 master 里面。。正常都是线上代码 master 。。看你们线上哪个分支,从那个分支弄个新分支,修复了合上就是了。
|
![]() |
16
w4ngzhen 88 天前 ![]() 大家不要纠结 master 分支包含未完成代码,分支只是一个名,“master”、“dev”当开发分支不过就是名字,各家有各家自己的设定,只不过开源项目约定俗成的是 master/main 分支作为稳定主干。楼主的场景下,应该秉持哪里出问题,哪里拉分支处理。你如果是线上问题,你就该从 prod 分支(假设你们是这个分支作为线上,或者你们至少发布的时候有一个 tag 吧)拉一个 hotfix ,因为这才是和你线上绝对一致的代码环境。hotfix 完成以后,应该将你这个 hotfix 分支在你们的开发/测试/预发(假设有)/生产,这么走一遍,进行验证。hotfix 的首要目的是快速修复。
上面的事情搞定后,你可以把 hotfix 里面的 commit ,再 cherry-pick 到你现在的开发环境等,部署一遍,这个过程就和普通开发流程一致。 |