Git分支 - 利用分支進行開發的工做流程

利用分支進行開發的工做流程

長期分支

因爲 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 倉庫中進行的 — 徹底不涉及與服務器的交互。