在工作中,idea git工作流多人協作開發,多環境多分支容易發生錯合,漏合,多合代碼的問題,這裡記錄一些小技巧,分享下.
部落客公司分三個環境,開發環境,又稱測試環境,開發人員或者開發人員之間測試聯調.教育訓練環境,雲平台釋出後測試人員測試環境,生産環境,線上環境.
一般開發環境寫完需求,自測聯調後,上教育訓練,測試人員測試通過後方能上生産.理論一個需求從開發完成到上生産環境後,三個環境代碼應該一緻,但因為曆史原因,開發環境代碼與教育訓練
生産有很大的差異.與此同時,同僚開發的新需求代碼在開發分支,很難一次徹底同化.在此背景下,合代碼變得繁瑣而痛苦.
1 開發新需求時,一般以最新開發分支建立feature分支,在開發過程可能會遇到各種問題,比如教育訓練或者生産有bug,需要切換分支解決,如果每次都送出,次數多了後續合代碼會很麻煩,我有一次寫完一個需求後,合代碼有十幾次的送出,改動的檔案多而雜,很難直接取最後一次送出的,是以這種情況我後來一般是把改動的暫存起來
,解決完問題在切回這個feature分支代碼unstash出來,循環往複,這樣開發完成後,用後一次的代碼送出.
2 合并開發代碼到教育訓練,如果采取了上述的方案,那就很友善,如果沒有的話就可以依次合并代碼,合完再做次送出.當然可以在version control裡面右擊送出選擇cherry pick
,但是需要注意的是如果多次cherry pick後再送出,它也是送出多次,後續合到生産環境還是很麻煩,可以采取暫存,再unstash一并合入.
3 再就是多人同時對多個相同的檔案改動,如果直接全合就可能把别人無需上生産、錯誤代碼、未及時同步的過期代碼也合入，造成不必要的錯誤情況。這種就需要對檔案一一比較,選中送出檔案右擊show diff with local
比較着合,如果與本地檔案差別過大,還可以輕按兩下送出/右擊送出檔案show diff
,檢視本次送出代碼差異,這樣減小合入代碼的錯誤率.
好了,以上就是我的個人總結記錄之,當然還是希望能用上docker之類的開發容器,減少多個具有差異的環境的切換互動是保證代碼正确統一的有效途徑.水準有限,僅記錄經驗而已.