利用分支進行開發的工作流程
現在我們已經學會了新建分支和合併分支,可以(或應該)用它來做點什麼呢?在本節,我們會介紹一些利用分支進行開發的工作流程。而正是由於分支管理的便捷,才衍生出了這類典型的工作模式,你可以根據專案的實際情況選擇一種用用看。
長期分支
由於 Git 使用簡單的三方合併,所以就算在較長一段時間內,反復多次把某個分支合併到另一分支,也不是什麼難事。也就是說,你可以同時擁有多個開放的分支,每個分支用於完成特定的任務,隨著開發的推進,你可以隨時把某個特性分支的成果並到其他分支中。
許多使用 Git 的開發者都喜歡用這種方式來開展工作,比如僅在 master
分支中保留完全穩定的代碼,即已經發佈或即將發佈的代碼。與此同時,他們還有一個名為 develop
或 next
的平行分支,專門用於後續的開發,或僅用於穩定性測試 — 當然並不是說一定要絕對穩定,不過一旦進入某種穩定狀態,便可以把它合併到 master
裡。這樣,在確保這些已完成的特性分支(短期分支,比如之前的 iss53
分支)能夠通過所有測試,並且不會引入更多錯誤之後,就可以並到主幹分支中,等待下一次的發佈。
本質上我們剛才談論的,是隨著提交物件不斷右移的指標。穩定分支的指標總是在提交歷史中落後一大截,而前沿分支總是比較靠前(見圖 3-18)。
圖 3-18. 穩定分支總是比較老舊。
或者把它們想像成工作流水線,或許更好理解一些,經過測試的提交物件集合被遴選到更穩定的流水線(見圖 3-19)。
圖 3-19. 想像成流水線可能會容易點。
你可以用這招維護不同層次的穩定性。某些大專案還會有個 proposed
(建議)或 pu
(proposed updates,建議更新)分支,它包含著那些可能還沒有成熟到進入 next
或 master
的內容。這麼做的目的是擁有不同層次的穩定性:當這些分支進入到更穩定的水準時,再把它們合併到更高層分支中去。再次說明下,使用多個長期分支的做法並非必需,不過一般來說,對於特大型項目或特複雜的專案,這麼做確實更容易管理。
特性分支
在任何規模的專案中都可以使用特性(Topic)分支。一個特性分支是指一個短期的,用來實現單一特性或與其相關工作的分支。可能你在以前的版本控制系統裡從未做過類似這樣的事情,因為通常創建與合併分支消耗太大。然而在 Git 中,一天之內建立、使用、合併再刪除多個分支是常見的事。
我們在上節的例子裡已經見過這種用法了。我們創建了 iss53
和 hotfix
這兩個特性分支,在提交了若干更新後,把它們合併到主幹分支,然後刪除。該技術允許你迅速且完全的進行語境切換 — 因為你的工作分散在不同的流水線裡,每個分支裡的改變都和它的目標特性相關,流覽代碼之類的事情因而變得更簡單了。你可以把作出的改變保持在特性分支中幾分鐘,幾天甚至幾個月,等它們成熟以後再合併,而不用在乎它們建立的順序或者進度。
現在我們來看一個實際的例子。請看圖 3-20,由下往上,起先我們在 master
工作到 C1,然後開始一個新分支 iss91
嘗試修復 91 號缺陷,提交到 C6 的時候,又冒出一個解決該問題的新辦法,於是從之前 C4 的地方又分出一個分支 iss91v2
,幹到 C8 的時候,又回到主幹 master
中提交了 C9 和 C10,再回到 iss91v2
繼續工作,提交 C11,接著,又冒出個不太確定的想法,從 master
的最新提交 C10 處開了個新的分支 dumbidea
做些試驗。
圖 3-20. 擁有多個特性分支的提交歷史。
現在,假定兩件事情:我們最終決定使用第二個解決方案,即 iss91v2
中的辦法;另外,我們把 dumbidea
分支拿給同事們看了以後,發現它竟然是個天才之作。所以接下來,我們準備拋棄原來的 iss91
分支(實際上會丟棄 C5 和 C6),直接在主幹中併入另外兩個分支。最終的提交歷史將變成圖 3-21 這樣:
圖 3-21. 合併了 dumbidea 和 iss91v2 後的分支歷史。
請務必牢記這些分支全部都是本地分支,這一點很重要。當你在使用分支及合併的時候,一切都是在你自己的 Git 倉庫中進行的 — 完全不涉及與伺服器的交互。