master 分支包含未开发完成的功能，线上版本出现严重 bug 需要修复，你们一般在 master 分支还是 prod 分支上创建 hotfix 分支？能详细说下为什么吗

基于 master 创建分支，提交验证，验证通过后，再 cherry-pick 到 prod 分支上，再次验证。两次验证通过后，就可以合并代码了。

两次验证可以保证今天 hotfix 和下次发版都不会有问题

hotfix 的分之一定是从跟 prod 环境一致的分支拉出来的。

master 就不会有未完成的任务,只从 release 合并.hotfix 一般从 release 开始打,不急或者范围小的也可能从 feature 打

master 对 release 上要 hotfix 的部分没有改动的话，hotfix 在基于二者创建都可以，cherry pick 一下就行了。

如果 master 对 release 上要 hotfix 部分已经发生改动了的花，老老实实在 release 上 hotfix 吧，完了还得在 master 上重新 hotfix

线上环境出问题当然从出问题的环境的分支进行修复

master 出现未完成的代码这本身就很不对劲了

你们把 master 当开发分支，另外弄了个 prod 当主干？

@lovelylain 对，我去过的几家公司都这么干

线上版本的 hotfix 肯定是基于线上版本的代码做分支，基于线上版本重现 bug ，基于线上版本验证 hotfix 。不可能基于 master 。

master 当然可以有未完成的功能。其实就相当于 dev 分支。这个由项目自己决定，我不觉得是什么问题。

快跑

直接从 prod 上切一个 hotfix ，弄完再合回去。不过 master 上包含未完成的代码也太野鸡了，真的是乱搞。

看你遵循那哪个规范，hotfix 肯定是从最接近发布的分支来开。 拿 master 当开发/主干是可以的。但如果是开源项目且默认分支是 master ，包含未完成代码可能会对用户造成困扰。

cherry-pick 到 prod

基于 prod 拉 hotfix ，上线后，合并到 master ，重新测试

为啥没上线的功能会在 master 里面。。正常都是线上代码 master 。。看你们线上哪个分支，从那个分支弄个新分支，修复了合上就是了。

大家不要纠结 master 分支包含未完成代码，分支只是一个名，“master”、“dev”当开发分支不过就是名字，各家有各家自己的设定，只不过开源项目约定俗成的是 master/main 分支作为稳定主干。楼主的场景下，应该秉持哪里出问题，哪里拉分支处理。你如果是线上问题，你就该从 prod 分支（假设你们是这个分支作为线上，或者你们至少发布的时候有一个 tag 吧）拉一个 hotfix ，因为这才是和你线上绝对一致的代码环境。hotfix 完成以后，应该将你这个 hotfix 分支在你们的开发/测试/预发（假设有）/生产，这么走一遍，进行验证。hotfix 的首要目的是快速修复。
上面的事情搞定后，你可以把 hotfix 里面的 commit ，再 cherry-pick 到你现在的开发环境等，部署一遍，这个过程就和普通开发流程一致。