首先我們開發的分支包括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.請問這樣對否?還是我理解有什麼偏差,謝謝!
曾经蜡笔没有小新2017-04-28 09:06:29
從 master 分出一個分支，可以叫樓上推薦的 hotfix，之後修改，再 commit。
接下來，不是直接把 master merge 到 dev 去（因為你有不一樣的配置資訊），而是用 cherrypick 把只帶有差異的 commit(s) 「摘」到 dev 去。
在你的案例中，cherrypick 比merge 更合適，不過你要注意的是：需要在後面cherrypick 的commit(s) 裡不要包含dev 不想要的內容（例如master 的特定配置資訊），如果這些內容也有更改，可以分別提交，因為cherrypick 是可以「跳著摘」 commit(s) 的。
最後，我很奇怪為什麼配置資訊這樣的東西也會在版本庫裡，如此一來豈不是 dev 往 master 合併的時候也有覆蓋配置資訊的風險？如果你們可以把設定資訊隔離出來，也就用不著 cherrypick 而是可以直接 merge 了——這才是你在網路上看到的解決方案。
我想大声告诉你2017-04-28 09:06:29
沒實際遇過這種場景 如果這種情況 我大概會這樣操作
從dev分支中和master相同的那個commit 建立一個新分支hotfix
在hotfix修bug
修完後 master和其他人員合併此分支
