[[355431]]

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

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

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

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

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

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

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

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

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

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

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

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

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