現在已經學會新建、刪除和合並分支等操作,那麼接下來會介紹一些利用分支,進行開發的工作流程。
正是由於Git分支管理的便捷,才衍生出這些典型的工作模式,你可以根據項目實際情況選擇一種用用看。
1、長期分支
因爲 Git 使用簡單的三方合併,所以就算在一段較長的時間內,反覆把一個分支合併入另一個分支,也不是什麼難事。 也就是說,在整個項目開發週期的不同階段,你可以同時擁有多個開放的分支;你可以定期地把某些主題分支合併入其他分支中。
許多使用 Git 的開發者都喜歡使用這種方式來工作,比如只在 master
分支上保留完全穩定的代碼,有可能僅僅是已經發布或即將發佈的代碼。
他們還有一些名爲 develop
或者 next
的平行分支,被用來做後續開發或者測試穩定性,這些分支不必保持絕對穩定,但是一旦達到穩定狀態,它們就可以被合併入 master
分支了。
這樣,在確保這些已完成的主題分支(短期分支,比如之前的 dev
分支)能夠通過所有測試,並且不會引入更多 bug 之後,就可以合併入主幹分支中,等待下一次的發佈。
事實上我們剛纔討論的,是隨着你的提交而不斷右移的指針。 穩定分支的指針總是在提交歷史中落後一大截,而前沿分支的指針往往比較靠前。
如下圖:
通常把他們想象成流水線(work silos)可能更好理解一點,那些經過測試考驗的提交,會被遴選到更加穩定的流水線上去。
如下圖:
你可以用這種方法維護不同層次的穩定性。
一些大型項目還有一個 proposed
(建議) 或 pu: proposed updates
(建議更新)分支,它可能因包含一些不成熟的內容而不能進入 next
或者 master
分支。
這麼做的目的是使你的分支,具有不同級別的穩定性。當它們具有一定程度的穩定性後,再把它們合併入具有更高級別穩定性的分支中。
再次強調一下,使用多個長期分支的方法並非必要,但是這麼做通常很有幫助,尤其是當你在一個非常龐大或者複雜的項目中工作時。
2、主題分支(短期分支)
主題分支對任何規模的項目都適用。 主題分支是一種短期分支,它被用來實現單一特性或其相關工作。
也許你從來沒有在其他的版本控制系統(VCS
)上這麼做過,因爲在那些版本控制系統中,創建和合並分支通常很費勁。 然而,在 Git 中一天之內多次創建、使用、合併、刪除分支都很常見。
你在之前的文章中,創建的 dev
和 hotfix
主題分支中看到過這種用法。在主題分支(dev
和 hotfix
分支)中提交了一些更新,並且在它們合併入主幹分支之後,你又刪除了它們。
這項技術能使你快速並且完整地進行上下文切換(context-switch)。因爲你的工作被分散到不同的流水線中,在不同的流水線中,每個分支都僅與其目標特性相關。因此,在做代碼審查之類工作的時候,就能更加容易地看出你做了哪些改動。
你可以把做出的改動,在主題分支中保留幾分鐘、幾天甚至幾個月,等它們成熟之後再合併,而不用在乎它們建立的順序或工作進度。
考慮這樣一個例子,你在 master
分支上工作到 C1
提交,這時爲了解決一個問題而新建 iss91
分支,在 iss91
分支上工作到 C4
提交,然而對於那個問題你又有了新的想法,於是你再新建一個 iss91v2
分支,試圖用另一種方法解決那個問題,接着你回到 master
分支工作了一會兒,你又冒出了一個不太確定的想法,你便在 C10
提交的時候,新建一個 dumbidea
分支,並在上面做些實驗。
你的提交歷史如下圖:
現在,我們假設兩件事情:
- 你決定使用第二個方案來解決那個問題,即使用在
iss91v2
分支中方案。 - 另外,你將
dumbidea
分支拿給你的同事看過之後,結果發現這是個驚人之舉。
這時你可以拋棄 iss91
分支(即丟棄 C5
和 C6
提交),然後把另外兩個分支合併入主幹分支。
最終你的提交歷史,如下圖:
3、總結
當你做了這麼多操作之後,但其實這些分支全部都存於本地。 當你新建和合並分支的時候,所有這一切都只發生在你本地的 Git 版本庫中,沒有與服務器發生交互。
在以後學習了分佈式 Git
後,會有更多有關分支工作流的細節。
因此,等學習完分佈式 Git
後,你可以再來決定下個項目中,要使用什麼樣的分支策略(branching scheme)。