git 中,关于在主分支修改Bug的问题!
椒桥头_671 发布于 2022-10-25 04:25首先我们开发的分支包括master和dev
master是主分支
dev为开发分支
我们每次提交的模式是,大家都有各自的本地分支,a,b,c,他们都向dev进行提交,提交并测试通过的提交到master分支.
以上是开发流程
下面描述问题:
由于现在master生产环境配置了大量生产信息,并且这些修改仅在master上.我们现在需要修改该一个Bug,这个Bug是dev和master同时存在的(bug很紧急).理论上,应该在提交到dev上然后测试通过修复bug再提交到master上.但是现在dev上有大家提交的未测试的功能,故不能仅仅在dev上修改后立即提交到master上,也不能仅仅只在master上提交,然后master merge 回dev就会将大量配置信息引入dev环境.所以我们的处理办法是dev上修改一遍master上修复一遍.
理论上当下次提交的时候会出现diff,这个diff也仅仅是真对于这个Bug的,这是我们能想到的办法了,但我觉得一定有比这个更好的办法,请问大家有没有好的解决方法和意见!
看到网上,有这样的解决办法,是在我们的master分支切一个分支出来,然后更改bug后,分别merge 到master 和dev,但是我还是不理解,这样还是会将master的配置信息带入dev.请问这样对否?还是我理解有什么偏差,谢谢!
-
操作 @Larvata 说了，配置文件 @nightire 说了，我补充一份参考资料吧
一个成功的Git分支模型
2022-10-26 14:15 回答
笑不评j -
没实际遇到过这种场景 如果这种情况 我大概会这样操作
从dev分支中和master相同的那个commit 创建一个新分支hotfix
在hotfix中修bug
修完后 master和其他人员合并这个分支2022-10-26 14:15 回答 -
从 master 分出一个分支，可以叫楼上推荐的 hotfix，之后修改，再 commit。
接下来，不是直接把 master merge 到 dev 去（因为你有不一样的配置信息），而是用 cherrypick 把只带有差异的 commit(s) “摘”到 dev 去。
在你的案例中，cherrypick 比 merge 更合适，不过你要注意的是：需要在后面 cherrypick 的 commit(s) 里不要包含 dev 不想要的内容（比如 master 的特定配置信息），如果这些内容也有更改，可以分别提交，因为 cherrypick 是可以“跳着摘” commit(s) 的。
最后，我很奇怪为什么配置信息这样的东西也会在版本库里，如此一来岂不是 dev 往 master 合并的时候也有覆盖配置信息的风险？如果你们可以把配置信息隔离出来，也就用不着 cherrypick 而是可以直接 merge 了——这才是你在网上看到的解决方案。
2022-10-26 14:16 回答
马黛茶总部
京公网安备 11010802041100号