[[355431]]

本文轉(zhuǎn)載自微信公眾號(hào)「虞大膽的嘰嘰喳喳」，作者虞大膽  。轉(zhuǎn)載本文請(qǐng)聯(lián)系虞大膽的嘰嘰喳喳公眾號(hào)。 

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

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

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

SIT分支相當(dāng)于做集成測試了，保證了master的代碼是相對(duì)可靠的。

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

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

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

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

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

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

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

git工作流有多種選擇，主要看整個(gè)團(tuán)隊(duì)對(duì)git的理解程度，并行項(xiàng)目數(shù)量，CI/CD方式等等，沒有絕對(duì)的好壞，只要能說得通，沒有明顯的缺點(diǎn)，那就是好的工作流。