git 中,关于在主分支修改Bug的问题!

Question

首先我们开发的分支包括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.请问这样对否?还是我理解有什么偏差,谢谢!

Answer 1

Fork a branch from master, you can call the hotfix recommended upstairs, modify it later, and then commit.

Next, instead of directly transferring master merge to dev (because you have different configuration information), use cherrypick to "pick" the commit(s) with only differences to dev.

In your case, cherrypick is more suitable than merge, but you should pay attention to this: you need to not include content that dev does not want in the commit(s) of cherrypick (such as specific configuration information of the master) ), if these contents are also changed, they can be submitted separately, because cherrypick can "skip pick" commit(s).

Finally, I’m curious why things like configuration information are also in the repository. Doesn’t this mean that there is a risk of overwriting the configuration information when dev merges with master? If you can isolate the configuration information, you don't need cherrypick but can directly merge - this is the solution you see online.

Answer 2

I have never actually encountered this kind of scenario. If this happens, I will probably do this
Create a new branch hotfix from the same commit as master in the dev branch
Fix bugs in hotfix
After the repair is completed, master and other staff merge this branch

Answer 3

Operation @Larvata said, configuration file @nightire said, let me add a reference

A successful Git branching model