Git 利用分支進(jìn)行開(kāi)發(fā)的工作流程

現(xiàn)在我們已經(jīng)學(xué)會(huì)了新建分支和合并分支，可以（或應(yīng)該）用它來(lái)做點(diǎn)什么呢？在本節(jié)，我們會(huì)介紹一些利用分支進(jìn)行開(kāi)發(fā)的工作流程。而正是由于分支管理的便捷，才衍生出了這類典型的工作模式，你可以根據(jù)項(xiàng)目的實(shí)際情況選擇一種用用看。

長(zhǎng)期分支

由于 Git 使用簡(jiǎn)單的三方合并，所以就算在較長(zhǎng)一段時(shí)間內(nèi)，反復(fù)多次把某個(gè)分支合并到另一分支，也不是什么難事。也就是說(shuō)，你可以同時(shí)擁有多個(gè)開(kāi)放的分支，每個(gè)分支用于完成特定的任務(wù)，隨著開(kāi)發(fā)的推進(jìn)，你可以隨時(shí)把某個(gè)特性分支的成果并到其他分支中。

許多使用 Git 的開(kāi)發(fā)者都喜歡用這種方式來(lái)開(kāi)展工作，比如僅在 master 分支中保留完全穩(wěn)定的代碼，即已經(jīng)發(fā)布或即將發(fā)布的代碼。與此同時(shí)，他們還有一個(gè)名為 develop 或 next 的平行分支，專門用于后續(xù)的開(kāi)發(fā)，或僅用于穩(wěn)定性測(cè)試 — 當(dāng)然并不是說(shuō)一定要絕對(duì)穩(wěn)定，不過(guò)一旦進(jìn)入某種穩(wěn)定狀態(tài)，便可以把它合并到 master 里。這樣，在確保這些已完成的特性分支（短期分支，比如之前的 iss53 分支）能夠通過(guò)所有測(cè)試，并且不會(huì)引入更多錯(cuò)誤之后，就可以并到主干分支中，等待下一次的發(fā)布。

本質(zhì)上我們剛才談?wù)摰模请S著提交對(duì)象不斷右移的指針。穩(wěn)定分支的指針總是在提交歷史中落后一大截，而前沿分支總是比較靠前（見(jiàn)圖 3-18）。

圖 3-18. 穩(wěn)定分支總是比較老舊。

或者把它們想象成工作流水線，或許更好理解一些，經(jīng)過(guò)測(cè)試的提交對(duì)象集合被遴選到更穩(wěn)定的流水線（見(jiàn)圖 3-19）。

圖 3-19. 想象成流水線可能會(huì)容易點(diǎn)。

你可以用這招維護(hù)不同層次的穩(wěn)定性。某些大項(xiàng)目還會(huì)有個(gè) proposed（建議）或 pu（proposed updates，建議更新）分支，它包含著那些可能還沒(méi)有成熟到進(jìn)入 next 或 master 的內(nèi)容。這么做的目的是擁有不同層次的穩(wěn)定性：當(dāng)這些分支進(jìn)入到更穩(wěn)定的水平時(shí)，再把它們合并到更高層分支中去。再次說(shuō)明下，使用多個(gè)長(zhǎng)期分支的做法并非必需，不過(guò)一般來(lái)說(shuō)，對(duì)于特大型項(xiàng)目或特復(fù)雜的項(xiàng)目，這么做確實(shí)更容易管理。

特性分支

在任何規(guī)模的項(xiàng)目中都可以使用特性（Topic）分支。一個(gè)特性分支是指一個(gè)短期的，用來(lái)實(shí)現(xiàn)單一特性或與其相關(guān)工作的分支?？赡苣阍谝郧暗陌姹究刂葡到y(tǒng)里從未做過(guò)類似這樣的事情，因?yàn)橥ǔ?chuàng)建與合并分支消耗太大。然而在 Git 中，一天之內(nèi)建立、使用、合并再刪除多個(gè)分支是常見(jiàn)的事。

我們?cè)谏瞎?jié)的例子里已經(jīng)見(jiàn)過(guò)這種用法了。我們創(chuàng)建了 iss53 和 hotfix 這兩個(gè)特性分支，在提交了若干更新后，把它們合并到主干分支，然后刪除。該技術(shù)允許你迅速且完全的進(jìn)行語(yǔ)境切換 — 因?yàn)槟愕墓ぷ鞣稚⒃诓煌牧魉€里，每個(gè)分支里的改變都和它的目標(biāo)特性相關(guān)，瀏覽代碼之類的事情因而變得更簡(jiǎn)單了。你可以把作出的改變保持在特性分支中幾分鐘，幾天甚至幾個(gè)月，等它們成熟以后再合并，而不用在乎它們建立的順序或者進(jìn)度。

現(xiàn)在我們來(lái)看一個(gè)實(shí)際的例子。請(qǐng)看圖 3-20，由下往上，起先我們?cè)?master 工作到 C1，然后開(kāi)始一個(gè)新分支 iss91 嘗試修復(fù) 91 號(hào)缺陷，提交到 C6 的時(shí)候，又冒出一個(gè)解決該問(wèn)題的新辦法，于是從之前 C4 的地方又分出一個(gè)分支 iss91v2，干到 C8 的時(shí)候，又回到主干 master 中提交了 C9 和 C10，再回到 iss91v2 繼續(xù)工作，提交 C11，接著，又冒出個(gè)不太確定的想法，從 master 的最新提交 C10 處開(kāi)了個(gè)新的分支 dumbidea 做些試驗(yàn)。

圖 3-20. 擁有多個(gè)特性分支的提交歷史。

現(xiàn)在，假定兩件事情：我們最終決定使用第二個(gè)解決方案，即 iss91v2 中的辦法；另外，我們把 dumbidea 分支拿給同事們看了以后，發(fā)現(xiàn)它竟然是個(gè)天才之作。所以接下來(lái)，我們準(zhǔn)備拋棄原來(lái)的 iss91 分支（實(shí)際上會(huì)丟棄 C5 和 C6），直接在主干中并入另外兩個(gè)分支。最終的提交歷史將變成圖 3-21 這樣：

圖 3-21. 合并了 dumbidea 和 iss91v2 后的分支歷史。

請(qǐng)務(wù)必牢記這些分支全部都是本地分支，這一點(diǎn)很重要。當(dāng)你在使用分支及合并的時(shí)候，一切都是在你自己的 Git 倉(cāng)庫(kù)中進(jìn)行的 — 完全不涉及與服務(wù)器的交互。