[[355431]]

本文轉載自微信公眾號「虞大膽的嘰嘰喳喳」，作者虞大膽  。轉載本文請聯系虞大膽的嘰嘰喳喳公眾號。 

在基于git的工作流中，master一般是做持續集成的，開發人員在特性分支開發，經過測試后，就會merge到master做集成測試，測試通過就表示master可部署了。

可現實情況下，特性分支自測沒問題，不代表就真的沒問題，測試人員還沒測試呢，所以此時的master分支其實是沒準備好的(從master特定commit id到生成分支其實是有一定難度的)

我們目前的做法，在master分支之前還有一個SIT系統集成分支，也就是說這個分支是專門給QA人員測試的，測試沒問題后，將特性分支的代碼合并到pre分支，仿真環境如果沒問題，再將特性分支合并到master分支，然后進行發布。

SIT分支相當于做集成測試了，保證了master的代碼是相對可靠的。

那什么代碼合并到SIT分支呢?不管幾個項目，也不管這些項目具體的上線時間，特性分支都可以合并到SIT分支，然后統一給QA人員測試(相當于提前測試多個項目了)，正因為這樣，上線的時候無法從SIT分支merge到master分支。

這種工作流多了一個步驟，必然會有副作用，首先merge到SIT分支的時候，如果有沖突，SIT分支不應該解決沖突，因為SIT分支只是為了測試，不會上線的，所以不應該解決沖突;其次很多人說為了避免有沖突，那么我就經常性的將SIT分支上的代碼merge(也就是pull)到特性分支，這也非常不好，因為這個特性分支就不隔離了。所以正確的做法，如果merge到SIT分支產生沖突，應該自己去解決沖突，可如何找到和那個分支沖突呢?

還有SIT分支和master分支因為時間點和作用不一樣，沒有必要保持代碼是同步，可pre分支和master分支理論上應該保持同步，上線的時候沒有選擇merge SIT分支到master分支的原因是cherry-pick還是有一定復雜度的，merge特定commit id也是有復雜度的，所以我們選擇從特性分支合并到master，那必然要思考一個問題，pre分支測試通過代表master分支測試通過嗎?如果pre到master是一個fast forward，理論上不用再重復測試。

還有一種做法和我們的做法類似，就是有一個隱形的SIT分支，特性分支一旦提交到遠端，就自動merge到SIT分支，查看是否有沖突，如果有沖突，就提醒開發者去解決，從而保障能夠持續集成。

最后說說特性分支，我們還喜歡根據迭代周期去弄一個大分支，實際上這個大分支包含了很多子功能，也就是說可以拆分為多個子分支，那這兩種方式有什么優缺點呢?

如果在一個大分支，能夠減少一些沖突，但做不到隔離了，如果頻繁的pull，是選擇merge還是rebase呢?應該選擇merge，推送到遠端的分支不建議做rebase，會產生很多問題。其實既然選擇了一個大分支，那git歷史記錄必然會很難看的，基本沒有追朔性。如果實在要使用一個大分支，建議不要太頻繁的提交到遠端，盡量做好自測再提交。SIT部署的環境(QA)是為了測試人員測試的，應該保障一定的穩定性，它們不是給開發人員調試用的。

建議還是子分支，一方面說不定有一天就上線部分功能，子分支就合適了;另外子分支也能做到隔離;當然可能會遇到很多merge沖突的問題，這時候就需要自己甄別與那個分支發生沖突了(目前沒有想到辦法)。

git工作流有多種選擇，主要看整個團隊對git的理解程度，并行項目數量，CI/CD方式等等，沒有絕對的好壞，只要能說得通，沒有明顯的缺點，那就是好的工作流。