# 分支的工作流程 分支的工作流程要取決于它的使用背景，我們可以將它分為兩個主要的方面。 ##### 注釋 請記住，在這里它只是一個語義層面上的劃分。在技術和實用層面上，一個分支就是一個分支，它們的原理都是一樣的。 ## (A) 短期分支（Short-Lived）/主題分支（Topic Branches） 在本書前面的章節中已經提到了我對建立分支的一些建議，例如：_對應新功能的分支_，_修復錯誤的分支_ 以及 _進行代碼嘗試所建立的分支_。這些分支都有兩個重要共同特征： * 它們只涉及一個**單一主題**，而且它包含的代碼要和它的主題相對應。例如，你不應該建立一個關于購物車功能的分支，并且再在這個分支上去提交一些有關于郵件訂閱功能和錯誤修復的改動。 * 它們都只有非常短暫的生命周期。通常情況下，這個生命周期只維持到這個開發主題的結束之后（例如當錯誤被修復，新功能被完成……），這個分支的改動就會被整合到項目的大環境中去，并且這個分支也會被隨之刪除掉。  ## (B) 長期分支 Long-Running Branches 相對于那些基于一個單一開發主題或是一個錯誤修復的短期分支來說，這類分支被定義在更高的層面上。它們代表了在整個項目生命周期的一種狀態（比如：“產品”，“測試”，“研發”狀態）。它們在項目中保存的時間比較長，甚至可能是整個項目的生命周期。這類分支有如下一些典型特點： * 你不應該直接在這個分支上工作。但是你可以整合其他的分支（例如功能分支或是其他的長期分支）到這類分支中來，盡量不要對它直接進行提交。 * 一般來說，在長期分支之間也存在不同的等級。例如 “master” 分支一般被定義為最高等級。它應該只保存產品代碼（production code）。在它之下應該存在一個 “開發（development）” 分支。它會被用來進行真正的開發和測試工作，然后整合入 “master” 分支…… 我們應該為項目建立哪些長期分支呢？該如何使用它呢？這并不能一概而論。這在很大程度上取決于開發團隊的規模，開發風格和項目的需求，甚至于不同的客戶。這個規則必須被很清楚的定義出來，并且要得到整個開發團隊的認同和遵守。 ## 一個簡單通用的分支策略 我們已經講到了，不同的開發團隊必須定義合適自己的分支策略。然而，還是有一種簡單通用的流程，它應該適用于大多數的開發團隊。 ### 僅僅使用一個長期分支 雖然你可以在你的開發流程中引入多個長期分支，但是這樣也會存在很多不利因素。最為顯著的是會讓你開發流程變得非常復雜！在你的工作流程中僅僅定義和使用一個單一的長期分支可以避免很多不必要工作，并且使項目的開發變得比較簡單。 ##### 概念 在一般的情況下， “master” 分支可以有效地代表你的產品代碼。然而一個重要的前提就是，**所有被合并到 “master” 分支的代碼都必須保證正確！** 你必須保證它們的質量。因此它們必須經過測試，它們的代碼必須被檢驗過和確認過。 這也意味著，開發工作不應該直接在 “master” 分支上進行，這也是一個最基本的準則。因此當你使用了 “git checkout master” 命令切換到 “master” 分支后并提交改動時，你就要問問自己，這樣是否符合流程？這些改動是否能保證正確？ ### 主題分支 每當你開始著手開發一個新的功能的或是修復錯誤時，你都應該對應不同的主題建立一個新的分支。這是一種很通用的做法，并且也要成為你的一種習慣。 如果在你的項目倉庫中只存在一個長期分支，那么所有的主題分支都必須基于這個 “master” 分支。當你所開發的功能完成后，或者是錯誤被修復后，這些所對應的改動就理所當然的要被合并回 “master” 分支。 在你開發你的新功能的同時，團隊的其他開發人員已經把各自完成的改動整合回了 “master” 分支。在這種情況下，你就必須經常性地把那些在 “master” 分支上的改動合并到你的工作分支上來。這就確保了你的工作分支一直處于最新的狀態,并且當你要把已完成的改動整合回 “master” 分支上時，可以減少可能出現的沖突和風險。 請不要忘記這個簡單的黃金法則：只有正確和穩定的代碼才能被整合到 “master” 分支上來！如何確保這些代碼正確性呢？這就依靠你和你的團隊了。例如使用單元測試（unit tests），代碼審查（code reviews）等等。 ### 保持遠程同步 在 Git 中，遠程和本地倉庫可能彼此毫無依賴關系。不管怎樣，本地和遠程的分支必須被一致對待。 但是這樣也并不代表你必須要發布你的 _每一個_ 本地分支，擁有一些完全屬于你的私有分支也是非常必要和有意義的。例如當你單獨的研究一些新功能，或是嘗試調試一些新的技術時。 不管怎樣，當你要發布你的一個本地分支時，你就應該給它對應的遠程分支一個相同的名稱。例如，如果你有一個本地分支被命名為 “login-ui”，當你要發布它時，在遠程倉庫上它也必須擁有 “login-ui” 這個名字。 ### 頻繁推送 保持與遠程分支的同步并不是只停留在結構層面上，經常性地通過 “git push” 命令發布你的改動可以有助于團隊里的其他的開發人員看到和使用你的最新開發成果。附帶的還有一個最大的好處是，它可以作為你的遠程備份。 ## 其他分支策略 上述策略是最適用于小型的開發團隊。而一個較大的開發團隊可能會需要更多的規則和更復雜的結構。 在網絡上搜索其他開發團隊的策略將為你提供更多的選擇。這是其中一個非常流行并且可能是值得嘗試的一種工作流程 “[git-flow](https://www.git-tower.com/learn/git/ebook/cn/command-line/advanced-topics/git-flow)”。 ##### 注釋 我個人認為 git-flow 有些過于強大了： * 它擁有自己的腳本來詮釋 Git 和擁有自己獨有的命令。這使得它很難在一個 GUI 應用程序中被使用。 * 在它竭盡全力地簡化 Git 的同時， 它又需要讓使用者去學習一種幾乎是全新語言定義的命令。 通過正確的學習 Git 的基本知識，并且在開發團隊中確定一個專屬的共同工作流程后，你可能會認為類似 git-flow 所定義的擴展有些過于束縛。