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

マスターからブランチをフォークすると、上の階で推奨されているホットフィックスを呼び出し、後で変更してコミットできます。

次に、(設定情報が異なるため) マスター merge を dev に直接転送する代わりに、cherrypick を使用して、dev との相違点のみを含むコミットを「選択」します。

あなたの場合、mergeよりもcherrypickの方が適していますが、これには注意する必要があります: cherrypickのコミットに開発者が望まないコンテンツ(特定の設定など)を含めないでください。マスターの情報) )、これらの内容も変更された場合は、cherrypick がコミットを「スキップ」できるため、個別に送信できます。

最後に、構成情報などもリポジトリにある理由が気になりますが、これは、dev が master とマージするときに構成情報が上書きされるリスクがあることを意味するのではないでしょうか。構成情報を分離できれば、cherrypickは必要なく、直接mergeすることができます - これはオンラインで見られるソリューションです。

Answer 2

実際にこのようなシナリオに遭遇したことはありませんが、もしこれが起こったら、私はおそらくこれを行うでしょう。 dev ブランチのマスターと同じコミットから新しいブランチホットフィックスを作成します
ホットフィックスでバグを修正
修理完了後、マスターと他のスタッフがこのブランチをマージします

Answer 3

オペレーション @Larvata が言いました、設定ファイル @nightire が言いました、参照を追加しましょう

成功した Git ブランチング モデル