首先我们开发的分支包括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.请问这样对否?还是我理解有什么偏差,谢谢!
![[Web front-end] Permulaan pantas Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
Cabang cawangan daripada master, anda boleh memanggil pembaikan terbaru yang disyorkan di tingkat atas, mengubah suai kemudian, dan kemudian komit.
Seterusnya, bukannya terus cantum daripada master ke dev (kerana anda mempunyai maklumat konfigurasi yang berbeza), gunakan cherrypick untuk melakukan (s dengan hanya perbezaan) ) "pick" ke dev .
Dalam kes anda, cherrypick lebih sesuai daripada merge, tetapi anda harus ambil perhatian bahawa ia perlu berada dalam commit cherrypick kemudian . Jangan sertakan kandungan yang tidak diingini oleh dev (seperti maklumat konfigurasi khusus untuk induk). ). Akhirnya, saya tertanya-tanya mengapa perkara seperti maklumat konfigurasi juga terdapat dalam repositori. Bukankah ini bermakna terdapat risiko menimpa maklumat konfigurasi apabila dev bergabung dengan induk? Jika anda boleh mengasingkan maklumat konfigurasi, anda tidak memerlukan
cherrypicktetapi boleh terus bercantum - ini adalah penyelesaian yang anda lihat dalam talian.
Saya tidak pernah benar-benar menghadapi senario seperti ini Jika ini berlaku, saya mungkin akan melakukan ini
Cipta hotfix cawangan baharu
daripada komit yang sama seperti induk dalam cawangan dev Betulkan pepijat dalam hotfix
Selepas pembaikan selesai, tuan dan kakitangan lain menggabungkan cawangan ini
Operasi @Larvata berkata, fail konfigurasi @nightire berkata, biar saya tambah bahan rujukan
Model percabangan Git yang berjaya