我們都知道，在使用Git作為版本管理，開(kāi)發(fā)協(xié)作時(shí)候。master分支基本上代表著即將發(fā)布到生產(chǎn)環(huán)境的代碼，在如此重要的分支中，是需要盡量減少它出錯(cuò)的概率的。
場(chǎng)景描述
這里希望描述的一種場(chǎng)景是，有兩個(gè)并行的需求，需要同時(shí)開(kāi)發(fā)。
- 一是這兩個(gè)需求的上線日期接近
- 二是這兩個(gè)需求修改的文件耦合度很高。
可能出現(xiàn)的問(wèn)題： 如此可以想象到，最終合并分支代碼回到master后，一定會(huì)在master上產(chǎn)生過(guò)多的沖突，而解決過(guò)多的沖突中可能會(huì)無(wú)意的修改到原來(lái)的業(yè)務(wù)邏輯，導(dǎo)致最終部署到生產(chǎn)環(huán)境后出現(xiàn)錯(cuò)誤。
希望： 現(xiàn)在則希望在合并回到master分支后，不產(chǎn)生過(guò)多的沖突，避免master分支合并的簡(jiǎn)易，降低出現(xiàn)錯(cuò)誤的可能性。
如何并行開(kāi)始兩個(gè)需求
當(dāng)確定開(kāi)始并行的兩個(gè)需求時(shí)，一般會(huì)從master分支checkout兩個(gè)分支，一般以需求命名。之后在對(duì)應(yīng)的分支上完成需求的開(kāi)發(fā)，開(kāi)發(fā)完成并測(cè)試后會(huì)合并分支回master。
降低合并回master沖突的數(shù)量
再需求完成后，現(xiàn)在需要合并回master分支。我們先將dev_task_1分支合并回master，該分支合并不會(huì)有沖突，因?yàn)樵摲种膍aster中checkout后沒(méi)有受到其他分支影響。
之后，我們需要將dev_task_2合并回到master分支中，這個(gè)時(shí)候由于和dev_task_1修改的文件耦合度很高，所以，必然會(huì)在master出現(xiàn)大量的沖突。
此時(shí)，我們可以先從已經(jīng)合并了dev_task_1的master中checkout一個(gè)零時(shí)分支temp_branch。之后將dev_task_2合并到分支temp_branch，此時(shí)所有的沖突會(huì)出現(xiàn)在temp_branch中，只需要在這里解決完所有的沖突。并在此測(cè)試通過(guò)后。
就可以將temp_branch合并回master了。此時(shí)就不會(huì)在master出現(xiàn)沖突。
總結(jié)
整個(gè)過(guò)程并沒(méi)有減少?zèng)_突的數(shù)量，只是通過(guò)轉(zhuǎn)換沖突產(chǎn)生的分支，從而在降低了在master上解決沖突帶來(lái)的風(fēng)險(xiǎn)。在此，你可能會(huì)吐槽，但是在多人協(xié)作的項(xiàng)目中，很多時(shí)候，master分支合并的權(quán)限你并沒(méi)有，此時(shí)，需要他人來(lái)合并你開(kāi)發(fā)的代碼。對(duì)你的業(yè)務(wù)邏輯并不是很了解，就很有可能在解決沖突的時(shí)候出現(xiàn)錯(cuò)誤。而且當(dāng)一個(gè)需求開(kāi)發(fā)完，不一定立即就會(huì)合并到master分支，當(dāng)經(jīng)歷了一段時(shí)間后，此時(shí)自己已經(jīng)有一點(diǎn)生疏，此時(shí)再合并回主分支的時(shí)候，也有可能產(chǎn)生錯(cuò)誤。
所以當(dāng)你開(kāi)發(fā)完一個(gè)需求后，并通過(guò)測(cè)試后，就可以依照上訴的方法，通過(guò)生成一個(gè)新的分支，并在該分支解決完所有的沖突。然后等待他人來(lái)合并。
認(rèn)為有用則點(diǎn)贊關(guān)注，無(wú)用飄過(guò)
喜歡請(qǐng)隨意
